Enrichment Budget

Overview

Enrichment Budget gives enrichment the same discipline the send layer has: a spend cap. Enrichment costs credits, so you set a credit cap for the period, and a scheduled re-enrichment run refreshes your stalest contacts first, never spending past the cap. It is the credit-side parity to the per-day send budget on the dispatch queue.

What it is for, on the page. Under the headline, this page says what it produces, what makes it run, and where the output lands. Every Work page reads that line from one registry, so the three answers cannot drift from the page.

Your cap

Set a credit cap for the period. It counts every enrichment credit your account spends, on your own provider keys and on ours. An account that has never set one starts with a default ceiling. The panel shows your cap, the credits spent so far, and how many remain, and flags when the budget is exhausted. You can raise it, clear it, or reset the period's spend when a new budget window opens. Any enrichment run, on-demand or scheduled, is gated on the remaining budget.

The platform allowance

If you have not connected your own key for a provider (Apollo or Hunter, say), enrichment for that provider runs on ours, and the credits it buys are ours. Those credits have a second limit: a monthly allowance that comes with your plan. The panel shows it under your cap, with how much is used, how much is left, the date it resets, and which providers run on our keys for you today.

You can read the allowance and cannot change it. Raising or clearing your own cap does not raise it; only the admin of this deployment can. A paid plan starts with 2,000 credits a month on our keys, and an account with nothing purchased starts with none.

Whose allowance it is. The allowance belongs to whoever pays. If you bought your plan yourself, it is yours. If you hold a seat on a team seat pack, the pack has one allowance, 2,000 credits a month for each seat it bought, shared by everyone seated on it; moving a seat to someone else does not start the count again. If a founder handed you a role, you share the allowance of the subscription that pays for it. The panel says when yours is shared.

The deployment limit. On top of each allowance, the whole deployment has a monthly total for our keys that the admin sets. If it is reached, lookups on our keys stop for everyone until the first of next month, with the same message, and your own keys carry on. The admin is alerted once when the month's total reaches 80% of that limit and once more at 100%, and the admin page shows the running total against it.

When it runs out. Lookups on our keys stop until the first of next month: the provider is not called and nothing is charged, and the enrichment panel says so on that provider's row. Anything on your own keys carries on, limited only by your cap. Connecting your own key on Connections is the way to keep going before the reset. If the allowance cannot be read at all, lookups on our keys stop the same way until it can; we do not guess.

Each lookup on our keys reserves its credit before the call, in the same database statement that checks the limit, so two runs at once cannot both squeeze past the last credit. A lookup the vendor does not bill (an Apollo miss, say) gives its credit back. A call that fails mid-way keeps it, because the vendor may have billed for an answer we never received.

Scheduled re-enrichment

A weekly pass finds the contacts whose enrichment has gone stale, older than 90 days, or never enriched, and re-enriches as many as the remaining budget allows, oldest-stale first. The preview on the panel shows exactly what a run would refresh and how many credits it would spend, and honestly reports the contacts it would skip for budget.

The pass is bounded per tenant and per run, so a large book is refreshed across several weeks rather than in one burst. What does not fit is not dropped; it is simply next in line, still oldest-stale first.

Only what a provider actually reported is charged. A contact we could not fill anything for is not marked enriched and stays in the stale set, so a provider whose live path is not verified yet can never quietly look like a completed refresh. Credits are never reserved ahead of the work.

Deterministic and honest

The selection and the budget math are deterministic: the same contacts and budget always pick the same work. Nothing is spent beyond the cap, and a contact enriched recently is left alone, so the budget goes to the data that actually needs refreshing.

Spend only ever reflects work that happened. Both the scheduled pass and the Enrich button on Contact Enrichment charge your cap after the fact, at what the providers reported. The platform allowance is the one exception to after the fact, for the reason above.