The Apollo.io API: Rate Limits, Credit Burn, and What to Cache

The Apollo API has two independent limit systems and most integrations only discover the second one in production. Rate limits govern how fast you can call. Credits govern what the calls cost. They are enforced separately, they scale differently by plan, and a job can sail through the rate limiter while quietly spending several thousand credits on pagination nobody budgeted for.

Both are documented well. This is a working guide to what the documentation says, what it implies for how you should structure a job, and which responses are worth caching so you never pay for the same record twice.

Rate limits, by plan

Apollo applies different limits to enrichment endpoints than to everything else. Enrichment means people enrichment, bulk people enrichment, organization enrichment and bulk organization enrichment. Everything else means search, record management, engagement, analytics and usage endpoints.

API enrichment endpoints:

All other endpoints:

The asymmetry is the design insight. On any paid plan, enrichment has a high per-minute ceiling and no hourly or daily cap at all, while search and record operations are capped daily at 2,000 on Basic and Organization. Apollo is inviting you to enrich aggressively and search sparingly, and an integration built the other way around will hit a wall that more money does not immediately fix.

Limits use fixed windows rather than a rolling average. If your plan allows 200 requests per minute, you can spend all 200 at any point inside the active 60-second window, and the counter resets when the next window opens. Exceeding a limit returns 429 Too Many Requests.

Two caveats Apollo states directly. Legacy plans may carry different limits entirely, and Professional plans may have custom ones. The view API usage stats and rate limits endpoint returns the limits actually assigned to your team, and Apollo names it as the source of truth for exactly this reason. Read your limits from the API rather than from any table, including this one.

Credits, by endpoint

Credit consumption is documented per endpoint, and the shape is consistent: retrieving data costs, managing records does not.

Costs nothing0 credits

• Create, update, list or manage records
• Account, contact and deal operations
• Conversations without AI insights
• Most of the CRM-shaped surface area

Charged per record1 to 9 credits

• People enrichment: 1 credit for demographics or email
• People enrichment: plus 8 credits if a mobile number returns
• Organization enrichment: 1 credit each
• Get complete person info: 1 credit
• Charged only when qualifying data is returned

Charged per page1 credit per page

• Organization search: up to 100 results per page
• Organization job postings: up to 10,000 results per page
• News articles search: up to 25 results per page
• Pagination multiplies this directly

The per-page pricing is the one that rewards attention. Organization search bills 1 credit for a page of up to 100 results, so a query that returns 100 useful companies costs the same as one that returns 3. Requesting maximum page size is close to free money. Conversely, job postings bill 1 credit per page of up to 10,000 results, which is one of the better data-per-credit ratios in the whole table.

The mobile phone surcharge deserves its own note. A person enrichment that returns only demographics or an email costs 1 credit. The same call costs 9 if a mobile number comes back. If you do not need phone numbers, not requesting them is an 89% saving on every matched record.

Waterfall enrichment, and why it needs a budget of its own

Waterfall enrichment runs your configured third-party data sources when Apollo's own data does not have the answer, and it is the only part of the API where cost is genuinely hard to predict in advance.

Apollo's published ranges: email waterfall typically uses 1 to 4 credits, but some vendor configurations or successful higher-cost matches can exceed 20. Phone waterfall typically uses 8 to 25 and some configurations exceed 45.

The line that matters most is this one, which Apollo states plainly: some vendors consume credits per lookup even when no data is found. A waterfall over a poorly targeted list can therefore return almost nothing and still bill you for every attempt. That is normal behaviour for waterfall providers generally, and it means match rate is a cost variable rather than only a quality one.

Mechanically, waterfall is asynchronous. You set run_waterfall_email=true or run_waterfall_phone=true on a people enrichment call and supply a webhook_url. Apollo returns a synchronous response immediately with demographic data, a request ID and a status, then delivers the final email or phone results to your webhook when the vendors finish. Single requests return accepted or failed; bulk requests can also return partial_accepted.

Match rates improve when you supply at least one strong identifier: first and last name together, a LinkedIn URL, or an email address. Apollo warns that requests with insufficient identifiers may be accepted and simply return nothing, which is the expensive failure mode given the per-lookup billing above.

What to cache

Caching is the highest-leverage thing you can do against this API, because the credit meter has no memory and will happily charge you twice for the same record.

1. Step 1Check your own store first

   Never call enrichment for a record you already hold. Key on the identifier you enriched by, not on the returned data.

2. Step 2Deduplicate the input batch

   The same person arriving twice in one job is two charges. Dedupe on email and LinkedIn URL before the first call.

3. Step 3Request maximum page size on searches

   Search bills per page, so a 100-result page costs the same as a 10-result page.

4. Step 4Enrich in bulk, then persist everything

   Bulk people enrichment takes up to 10 people per request. Store the full response, including negative results.

Cache negative results too. A person Apollo could not enrich today is a person it probably cannot enrich tomorrow, and re-running them next month is a repeat charge for the same absence. Store the miss with a timestamp and set a re-check interval measured in months.

Cache firmographics harder than contact data. Company headcount, industry and domain move slowly. Job titles and email addresses decay fast. A single expiry policy across both either wastes credits on stable data or serves stale contact records.

Store the identifier you queried with. Apollo's credit accounting is per matched record, so your cache key needs to match your query shape, otherwise a lookup by LinkedIn URL will miss a cached record you originally fetched by email and you will pay again.

Batching and error handling

Bulk people enrichment accepts up to 10 people per request, which is the unit your batching logic should be built around. Ten per call against a 1,000-requests-per-minute enrichment ceiling is a theoretical 10,000 people a minute on a paid plan, so throughput is rarely the binding constraint. Credits are.

That ratio has a design implication worth stating. Because enrichment has no hourly or daily cap on paid plans while search is capped at 2,000 requests a day on the mid tiers, a job that searches to discover records and then enriches them will exhaust its search budget long before its enrichment budget. If you are running a recurring pipeline, cache the search results and re-enrich from your own store rather than re-discovering the same accounts every cycle.

On errors, the two responses to handle deliberately are the rate-limit rejection and the empty match.

A 429 Too Many Requests means you crossed a fixed window. Back off exponentially rather than retrying immediately, because the window has not reset and an instant retry simply consumes another rejection. Apollo publishes a status-codes reference covering the rest of the error surface.

An empty match is not an error and will not present as one. Apollo accepts requests with weak identifiers and returns no match, so your integration needs to distinguish "the call failed" from "the call succeeded and found nobody". Those need different handling and different retry policies: the first is worth repeating, the second is worth caching as a known miss so you never pay to rediscover the same absence.

Before you run a large job

Apollo's own recommended sequence is worth following: confirm whether the endpoint consumes credits, check the charging unit, run a small test request, review the credit usage in the Apollo settings, then scale. That test run is the entire safeguard, and it costs a handful of credits to avoid a four-figure surprise.

Two more habits from operating metered APIs generally. Meter the job by its own consumption rather than by the account-wide counter, because a shared account inherits every other job's usage and a budget check reading the account total will halt a run that has spent nothing. And treat a 429 as a signal to back off with exponential delay rather than to retry immediately, since fixed windows mean an immediate retry lands in the same exhausted window.

If you are evaluating whether the plan tier supports your intended volume at all, the pricing and credit breakdown covers the plan-level limits, and the review covers where the product fits. For the enrichment quality question the API cannot answer, how the email finder works covers verification.

We build and run this kind of pipeline for clients on a pay-per-qualified-meeting basis, so the credit modelling and the integration work sit with us. You can see what a campaign would look like for your market.

Rate limits are per Apollo's developer documentation last updated 28 July 2026, and credit consumption per Apollo's API pricing documentation last updated 18 July 2026, both fetched 11 August 2026. Legacy plans may differ; query the usage-stats endpoint for your team's actual limits. Verify current terms with Apollo before building against them.

Sources: Apollo API rate limits, Apollo API pricing and credits, Waterfall enrichment