429 even with hourly and daily headroom left.
Limits are grouped. Each endpoint belongs to exactly one group with its own independent counters, so hammering search never eats into your feed throughput.
Only search and feed budgets scale with your plan — those are what a subscription sells. Every other group has a fixed ceiling that does not change with your tier. Your plan is read from your subscription on every request, so an upgrade or downgrade moves your throughput immediately.
Rate limits are checked before credits are deducted, so a rate-limited request never costs you anything. See Billing.
Search and feed: scales with your plan
JobFeed sits lower per minute because a single feed request can deliver up to 1,000 jobs.
Everything else: fixed
These budgets are the same on every plan. Buying a larger Job Search tier does not raise them — they cover separate products and are not what a subscription sells.
Auto Apply intake also carries its own transactional quota, independent of these request budgets.
Which group an endpoint belongs to
Each group keeps its own independent counters. The group that applied to a request is echoed back on every response as
X-RateLimit-Group, so you never have to guess.
An Unlimited plan drops per-job charges on Feed and managed Feed; a Job Search plan
draws Feed jobs from its included jobs before the pay-as-you-go rate. Those affect
what you are billed, not how many requests you may make — the
JobFeed budgets
above still apply.GET /api/companies/{id} requires no API key and is not rate limited at the key level — it is served from CDN cache. Every other endpoint requires a key and is counted.Reading the headers
Every authenticated response carries your current position in the window. See Response headers for the full inventory.When you exceed a limit
You get429 with Retry-After and a body naming the group and window. The envelope is documented in full under Errors.
Retry-After seconds. Never hardcode a delay — see the retry strategy for a working implementation.
Staying under the limits
1
Throttle on X-RateLimit-Remaining, not on 429
Treat
429 as a bug in your pacing rather than a signal to react to. When X-RateLimit-Remaining drops below roughly 10–20% of X-RateLimit-Limit, slow down — you avoid the round trips you would otherwise waste.2
Use the feed for bulk, not paginated search
Walking search results to export the corpus burns
JobSearch requests and is unstable on a moving dataset. POST /api/jobs/feed bills the same way per delivered job, returns up to 1,000 jobs per request, and has a cursor plus a separate request budget. See Sync a database.3
Cache geocode results
A location string always resolves to the same output, so results are indefinitely cacheable. Most integrations can eliminate nearly all repeat
Geocode traffic.4
Request only the fields you need
include_fields shrinks responses substantially — description alone dominates payload size. This does not change your request count but makes each one much faster.5
Paginate the feed serially
One in-flight request per cursor. Parallel fan-out on a cursor is both unsupported and the fastest way to hit the per-minute wall. See Pagination.
Repeated authentication failures
Separately from the per-key limits above, an IP address that produces a large number of failed-authentication401s in a short window is temporarily blocked with 429 for a few minutes. This protects against key-guessing and only affects requests that were already failing — a correctly configured integration never encounters it.