# Your monthly request quota
> What counts against your quota, why it's shared across every key, when it resets, and what to do when you hit it.
Source: https://hyperjobs.io/help/quotas
Your plan includes a fixed number of API requests per calendar month. That's your
quota. It's separate from the per-minute rate limit, and the two fail in
different ways — [rate limits](/docs/rate-limits) covers the technical behaviour
of both.
| Plan | Requests / month |
| --- | --- |
| Free | 500 |
| Starter | 50,000 |
| Growth | 500,000 |
| Scale | 5,000,000 |
## The quota is per account
This is the single most common surprise, so it's worth being blunt about:
Quota is enforced per **account**, not per key. Ten keys on a Growth plan share
one 500,000-request pool. Creating another key gives you another credential to
revoke independently — it does not give you another 500,000 requests.
The per-minute rate limit works the same way. Four workers on Growth's 300/min
get 75/min each, not 300 each.
Keys exist to separate environments and to be revoked independently. If you're
creating keys to get more volume, the thing you want is a bigger
[plan](/help/plans).
## What counts
Every authenticated request that reaches the API, including ones that return zero
results. A request that matches nothing still cost us the query, so it still
counts.
[`/v1/health`](/docs/api-reference/health) is the exception: it's
unauthenticated, isn't rate-limited, and doesn't touch your quota. Use it for
liveness probes rather than a `limit=1` job query — that's what it's for.
Response *size* is irrelevant. One request returning 200 jobs with full
descriptions costs exactly the same as one returning a single title.
## When it resets
At the start of each **calendar month**, in UTC. Not on your billing date, and
not on a rolling 30-day window. A quota exhausted on 28 January is full again on
1 February at 00:00 UTC.
Buying a plan mid-month doesn't leave you with a stub of a month, though — a
[plan change](/help/changing-plan) starts a new period and refreshes the quota
immediately.
## Reading your usage
The [dashboard](/dashboard) shows month-to-date consumption against your quota,
plus a 30-day daily breakdown per key. The per-key view is how you find out which
worker is eating the budget — the total tells you that you have a problem; the
breakdown tells you where it is.
`last_used_at` per key is on the same page. A key with unexplained volume is
worth [investigating](/help/key-security).
## When you hit the limit
Requests are rejected until the quota resets or you upgrade. Nothing is queued,
nothing is throttled to a trickle, and there's no soft landing — the quota is a
wall, not a slope.
Two ways out:
- **Upgrade.** A [plan change](/help/changing-plan) refreshes your quota with the
new plan's allocation immediately, so this unblocks you in a minute. It also
starts a new billing period and isn't prorated — read that page first.
- **Wait** for the calendar month to turn over.
We don't bill overage. You can't accidentally spend $4,000 because a retry loop
went feral — you just stop getting data. That's deliberate, and it's why the wall
is abrupt.
## Making the quota last
The cheapest fix, by a wide margin, is **bigger pages**. `limit` goes to 200 on
`/v1/jobs` and 1,000 on [`/v1/jobs/feed`](/docs/api-reference/jobs-feed), and every
page costs one request regardless of size:
```
50 pages × limit=20 = 50 requests
5 pages × limit=200 = 5 requests ← same data, 10× cheaper
```
The second cheapest is **not re-crawling to find changes**. Walking `/v1/jobs` to
spot what's new is the most expensive possible way to stay current, and on Free
or Starter it will exhaust the month before it finishes. Use the feed — one
request returns everything since your cutoff. See
[syncing the feed](/docs/guides/feed-sync).
Then: don't retry `401`s and `404`s. They'll never succeed, and each attempt is
billed. See [errors](/docs/errors).
## Custom limits
If your volume doesn't fit the plans, or you'd rather have the data as files than
as HTTP responses, write to . Custom quotas and flat-file
delivery both exist; neither is self-serve.
## Next
The technical reference, with a token-bucket example.
What each tier includes.