Skip to main content
Rate limits are counted per account, not per key. Every key on your account, revoked keys included, draws on the same budget. Extra keys add no throughput, and a new key starts from your account’s current usage.
  • Each group has a rolling per-minute, per-hour, and per-day budget. The tightest wins: an exhausted per-minute window returns 429 even with hourly and daily headroom left.
  • Each endpoint belongs to exactly one group with its own counters, so heavy search traffic never uses your feed budget.
  • Only JobSearch and JobFeed scale with your plan. An upgrade or downgrade changes them within about a minute.
  • Limits are checked before your wallet is charged, so a rate-limited request costs nothing.

​
Search and feed: scale with your plan

JobFeed is lower per minute because one feed request can deliver up to 1,000 jobs. The Unlimited plan and included jobs change what Feed costs (Billing), not how many JobFeed requests you can make.

​
Everything else: fixed

These budgets are the same on every plan. A larger Job Search plan does not raise them. Auto Apply also limits how many applications can be active at once (409 concurrency_limit_reached). That limit is separate from these request budgets.

​
Which group an endpoint belongs to

Every response names the group that applied in X-RateLimit-Group. GET /api/companies/{id} needs no API key and is not rate limited, because it is served from CDN cache. Every other endpoint requires a key and is counted.

​
Reading the headers

Every response that passes through the rate limiter reports your position in the window. Response headers lists every header. On a successful response, Limit, Used, and Remaining describe the per-minute window. On a 429, they describe the window you exhausted.
On the Job Search — Scale plan, the output looks like this:

​
When you exceed a limit

You get 429 with Retry-After and a body that names the window, the group, and the limit. Errors documents the full envelope.
Wait at least Retry-After seconds, and never hardcode a delay. The retry strategy has a working implementation.

​
Staying under the limits

1

Throttle on X-RateLimit-Remaining, not on 429

Slow down when X-RateLimit-Remaining drops below about 15% of X-RateLimit-Limit. A 429 means your pacing is wrong, and every one is a wasted round trip.
2

Use the feed for bulk, not paginated search

Paging through search to export the corpus burns JobSearch requests and skips or repeats jobs as data changes. POST /api/jobs/feed bills the same per delivered job, returns up to 1,000 jobs per request, and has its own budget. See Sync a database.
3

Cache geocode results

The same input normally resolves to the same result, so caching removes nearly all repeat Geocode traffic. See Resolve locations.
4

Paginate the feed serially

Keep one request in flight per cursor. Parallel fan-out on a cursor is unsupported and the fastest way to hit the per-minute limit. See Pagination.

​
Repeated authentication failures

Separately from your account limits, an IP address that produces 60 failed-authentication 401s within 5 minutes is blocked for 5 minutes. While blocked, every keyed request from that IP gets 429 with Retry-After: 300, even with a valid key. The body has no code:
A misconfigured service can therefore block healthy services that share its outbound IP, such as workers behind one NAT gateway. Fix the failing key rather than retrying it.