Concepts
Credits and billing
Delivered work spends your organization's shared credits. Estimate paid work before you run it, and top up in the console when the balance gets low.
How credits work
Credits are pooled at the organization, so every key in it draws on one balance. Amounts on the wire are microunits: one credit is 1,000 microunits.
How pricing works
Pricing is consumption-based: you only pay for data you get back. What each kind of work costs is shown to signed-in accounts. A self-serve account sees its current credit rates and credit packs under Pricing in the console, and a key can read the same catalog from GET /v1/pricing. An organization with a SeekOut agreement gets its rates from its SeekOut account team.
How a contact is charged
Contact retrieval is charged per delivered channel. A request for both channels may use a bundle rate when both are newly delivered; a partial delivery is charged according to the channel that arrives. The current rate and exact conditions are in Pricing, for signed-in accounts.
- Channels that are not found or fail do not add a charge.
- A delivered channel may be reused during its seven-day organization lease; a reuse does not create a new charge.
- Batch jobs price each channel separately and do not use the combined contact bundle rate.
- Duplicated rows in a batch are dropped before anything is priced.
POST /v1/contact-retrieval-jobs with quote_only: true prices the work and holds nothing. See contact jobs.What never costs anything
GET /v1/whoamiand preview search (include: preview).- Every Jobs API read and the cancel:
GET /v1/jobs,GET /v1/jobs/{job_id},GET /v1/job-results/{job_id}, andPOST /v1/jobs/{job_id}/cancel. The items were charged by the operation that produced them; reading them again never charges. - A
quote_onlyestimate. - Every webhook route — registering a destination, rotating its secret, reading deliveries, and replaying a dead-lettered one. Managing a destination is configuration, not consumption, and a delivery only carries facts a settled operation already paid for.
Read wallet balances with GET /v1/billing/balances and credit context with GET /v1/credits/context, using their documented scopes. A data API key does not authorize a purchase by itself. A workspace key with the explicit purchase-intent scope can create a frozen quote, read its status, and submit one payment attempt after a separate fresh owner/admin approval. The API key cannot approve the quote. Use the same Idempotency-Key and identical payment body when retrying an ambiguous response; a status GET does not reconcile a pending provider attempt. These purchase-control calls are deliberately excluded from usage request history; request telemetry is operational metadata, while Billing intent/payment records are the transaction evidence. Console checkout remains available in Billing.
When you run out
402 means the work cannot be funded. It is raised before any provider work, so nothing was charged, no lease was created, and nothing changed. Job creation funds inline, so a batch you cannot afford is a synchronous 402 and no job exists. Add credits in Billing.
429 and operational capacity.