Why Apollo Credits Vanish on Exports and Enrichment
Apollo only charges for verified emails, yet balances collapse at export time. Here is where the credits actually go and how to stretch them across the cycle.
A few weeks ago I wrote about Apollo's email verification tiers and how to keep sequence bounce rates under 3 percent. The follow-up question kept arriving in the same shape: if Apollo only charges for verified emails, why does the credit balance fall off a cliff the moment you export a list? The short answer is that the export is the spend event, not the search, and almost everything around it costs more than one credit per row.
Apollo's credit model is simple on the surface. Email reveals cost a maximum of 1 credit per contact, and you are only charged for addresses Apollo can verify. Phone numbers cost more, company-data exports can cost credits too, and unused credits expire at the end of each billing cycle. None of this is hidden - it is all on the About Apollo Credits page - but the interaction between those four rules is what empties balances mid-quarter. As of 2026 the model covers email reveals, phone reveals, exports, enrichment, AI research runs, and dialer minutes out of related pools, with per-user consumption views in Settings and no rollover anywhere.
Your credits expire at the end of each billing cycle. Credits do not roll over into the following billing cycle or upon renewal.
That sentence, from Apollo's own credits page, is the one I would print out. Everything else in this post is commentary on it. (To be fair, Apollo states the rule plainly where buyers can find it before they pay - the surprise is rarely the rule itself, it is the arithmetic it produces at export time.)
Where credits actually go on an export
The mental model most buyers arrive with is that searching Apollo is free and exporting costs a little. The reality is closer to the reverse: browsing, filtering, and saving records inside Apollo cost nothing, and the meter starts the moment data leaves the platform or gets revealed. Every CSV download, CRM sync, and API enrichment that pushes contact data to a system outside Apollo consumes export credits, which Apollo documents on its pricing page with Outreach and Salesloft named as examples. Saving 10,000 leads to a list is free; pushing those 10,000 rows anywhere useful is 10,000 spend decisions.
This is why the balance looks healthy all through list-building week and then collapses on Friday. A rep who reveals emails for 2,000 contacts has spent roughly 2,000 credits and feels fine, then exports the same list with phone numbers attached and discovers the second charge. I believe most "my credits vanished" reports are this exact sequence: two spend events mistaken for one. The export step also re-charges for records your team already paid to reveal if the workflow re-enriches instead of reusing saved contacts, which the Apollo API pricing docs warn about when the same people are enriched twice.
The fix at this layer is unglamorous: dedupe before you reveal, reveal before you export, and never re-export a list you already paid for without checking whether the records are saved contacts. Apollo only charges the email credit when verification succeeds, so unverified rows are not the leak - duplicates and re-exports are. Check the bounce logs habit too, since every bounced address in the export was a credit spent on a row that never had a chance.
Why enrichment costs more than one credit per row
Email reveals are the cheapest action in the system, and that anchors expectations everywhere else. Phone numbers break the anchor immediately: a single mobile reveal can cost 8 credits, which means the monthly mobile allowance on a Basic plan - 75 credits, per JustPricing's May 2026 breakdown - covers exactly 9 phone numbers. A rep planning to call 100 new prospects needs 800 mobile credits, more than ten times that allowance. Nothing about this is a bug; it is the price list working as designed on a workflow the plan was never sized for.
Waterfall enrichment widens the gap further. Apollo's API docs (updated August 2026) put standard people enrichment at 1 to 9 credits per person - 1 for demographics or email, plus 8 if a mobile number comes back - and email waterfall runs at 1 to 4 credits while phone waterfall typically lands at 8 to 25 credits, with some vendor configurations reaching past 45. The especially painful variant is the vendor that charges per lookup even when no data is found, so a failed enrichment can burn credits and return nothing. Readers who felt deja vu there should see the sibling problem in Clay, where we measured the same shape in credits burned on failed waterfall lookups - failed lookups returning nothing account for a fifth to nearly a third of spend, and the only defense is ordering cheap high-recall steps before expensive ones (!).
My read: enrichment pricing punishes the "enrich everything, filter later" workflow and rewards "filter first, enrich the survivors." Every row you enrich and then discard for bad fit is the most expensive row in the batch. Tighten the ICP filter inside Apollo before revealing anything, and the same credit pool covers roughly twice the qualified output. That is not a trick, it is just sequencing.
How to audit usage before a bulk export
Apollo ships the tool for this and buries it one menu deeper than it should be. Go to Settings, then Credits and activity, then Credit usage: the Overview tab shows balances per credit type, Usage details breaks consumption by feature and action, and per-user views let a manager see which seat is burning the pool. Surface-level attribution data only goes back to February 2026, so anything older shows as uncategorized - expected behavior, not missing credits, per Apollo's own What Are Credits guide.
Run this audit the day before any bulk export, not the day after. Check remaining export credits against the row count you plan to push, check the mobile pool separately if phones are attached, and confirm whether your team sits on a unified credit plan - where the shared pool already nets out mobiles, exports, dialer minutes, and power-up enrichment - or on separate per-type allowances. The unified-pool math surprises people in the other direction: adding the individual balances together double-counts, and the leftover figure is already the answer. One pre-export glance at that screen would have prevented most of the mid-Friday incidents described in the Reddit thread asking how "unlimited" Apollo email credits really are.
Credit burn sits exactly at the seam between discovery and enrichment that Leadex is built to close: in our runs the research plan lists its sources and enrichment steps for approval before anything billable happens, and company enrichment batches typically complete in under 60 seconds, so the spend decision is visible up front instead of discovered in a settings screen afterward.
How to stretch credits across the billing cycle
Start with the calendar. Credits renew on the first day of each billing cycle, annual plans release the full year upfront, and quarterly or semi-annual billing releases credits on its own schedule - but in every case the unspent balance expires, so hoarding is pure loss and splurging early is self-imposed scarcity. The teams that do well treat the cycle like a budget: reveal steadily, export in planned batches, and buy top-ups from the plan subscription page when a burst quarter demands it rather than letting a big export ambush the balance. Apollo notes top-ups can take time to appear and asks buyers to allow up to 24 hours before contacting support.
Then work the unit economics. Prefer email-first prospecting on lower tiers and reserve phone reveals for worked accounts, since one mobile number costs what eight verified emails cost. Keep AI research runs and power-up enrichments pointed at shortlists, not raw imports. And put a verification pass ahead of every reveal - Apollo's verified-only email charging already protects you from paying for junk, but a third-party check on catch-all domains before the reveal decides whether the credit buys a deliverable address or a technicality. Emmett Miller, guide author at Miniloop, puts the stakes plainly: most teams end up spending two to three times the sticker price once overages are included, "so map out your credit usage before you commit," which is the entire post in one sentence (I firmly approve).
None of this requires a spreadsheet religion. A monthly ten-minute review of the credit usage screen, a dedupe pass before reveals, and a rule against re-exporting paid records will carry a small team through a full cycle without a top-up. The credits are not vanishing; they are being spent exactly where the price list says, at a pace the workflow sets.
FAQ
Do Apollo credits roll over to the next cycle?
No. Apollo states that credits expire at the end of each billing cycle and do not roll over into the next cycle or upon renewal, with no exceptions for slow months.
When do Apollo credits renew?
Credits renew on the first day of each billing cycle. Annual plans release the full year's credits at the start of the cycle, while quarterly or semi-annual billing releases them on its own schedule.
How do I buy more Apollo credits mid-cycle?
Add them from the plan subscription page inside the app. Apollo notes the balance can take time to update, so allow up to 24 hours before raising a support ticket.
Why did my credits disappear after a CSV export?
Because the export is a separate spend event from the reveal: CSV downloads, CRM syncs, and API enrichments that move contact data outside Apollo each consume export credits on top of whatever the email and phone reveals cost.