Playbooks · Playbook
Issue a named API key per client, revoke any one of them without touching the others, and read usage attributed per key with a CSV export. What does not exist: per-client credit budgets, billed sub-accounts, and per-key spend caps. All credits come from one team balance, so a runaway job on one client's key spends the whole agency's credits. Budget enforcement lives in your scheduler, not in ours.
Last updated September 22, 2026
Pattern: one named key per client → client work runs under that key → per-key usage export → your own budget check before each run
Credit math: Attribution, not isolation. 12 clients on 12 named keys drawing from one team balance of 200,000 credits: the export tells you client 7 consumed 46,000 of them, which is what you need for invoicing and for arguing about scope. It does not stop client 7 consuming 190,000. Endpoint rates are per call or per result depending on the endpoint — see each endpoint page and current per-endpoint credit rates.
ROI math: The win is billing accuracy and blast radius. Per-key attribution turns a monthly reconciliation argument into a CSV, and revoking one compromised or departing client's key takes nothing else down. Convert credits at your tier rate on /pricing.
Owned internally by: Agency ops or the technical lead who owns the API key
Best for: Lead-gen and outbound agencies, consultancies, and anyone running enrichment on behalf of several clients out of one account
# One key per client. Same endpoints, different key, separate usage line.
curl -X POST https://api.richapi.ai/api/v1/email_finder \
-H "x-api-key: $RICHAPI_KEY_CLIENT_ACME" \
-H "Content-Type: application/json" \
-d '{"first_name": "Jane", "last_name": "Doe", "company_domain": "acme.com"}'
# Your runner enforces the budget, because the API does not.
# spent = usage_for_key_this_month("client_acme")
# if spent + estimated_cost > CLIENT_BUDGETS["client_acme"]: abort()
I run enrichment for eight clients out of one RichAPI account. Explain what a
separate API key per client actually isolates, and what it does not. Be
specific about whether one client can spend another client's credits.
Sign up at app.richapi.ai and copy your key.
25 free credits, no card.
Create one named key per client in the dashboard.
Name it after the client, not after the person who created it — the name is what you will read in the usage export a year from now.
Store keys per client in your secrets manager and have every job load the key for the client it is running for. One shared key across all clients destroys the only attribution you have.
Write the budget check into your own runner: read this month's usage for the key, compare it to the number in your contract, and refuse to start the job if it would go over. This control does not exist on our side.
Export usage as CSV on your billing cycle and reconcile per key against what you invoice.
Revoke a key the day a client offboards or a contractor leaves.
Revocation is per key and affects nothing else.
A team account can hold several named API keys. Every key authenticates identically against every endpoint, and four things follow from having more than one: - **Naming.** A key called `client-acme` is a key you can reason about. A key called `prod-2` is a key nobody dares revoke. - **Independent revocation.** Kill one key and every other key keeps working. A client offboards, a contractor leaves, a key ends up in a Slack thread. One revocation, no coordinated rollover, no other client's pipeline down for an afternoon. - **Per-key usage attribution.** Consumption is broken out by key, so you can see which client's work consumed what. - **CSV export.** The usage data comes out as a file you can reconcile against invoices. That is a genuinely good fit for agency billing, and it is the whole of what exists. **[Get 25 free credits — no card](https://app.richapi.ai)**
There are **no per-client credit budgets. No billed sub-accounts. No per-key spend caps.** Every key draws from one team credit balance. There is no mechanism on our side that stops a key at a number, and no mechanism that bills a client directly. A misconfigured loop on one client's key — a paging bug, a retry storm, an intern running the backfill twice — spends the agency's credits, and the other eleven clients find out when the balance hits zero. If you are evaluating us against a platform that offers real sub-accounts with isolated balances, that platform has something we do not. We would rather you read that sentence here than discover it in month two.
The control you want is a check in the job that issues the calls, and it is not complicated: 1. Keep the per-client monthly allowance in your own config, next to the contract that set it. 2. Before a run starts, read this month's usage for that client's key and estimate what the run will cost. On per-result endpoints that estimate needs a result count, or it is not an estimate. 3. If the run would cross the allowance, abort and alert a human. Alert, not silently skip. 4. Reconcile against the CSV export on your billing cycle, so config drift shows up monthly rather than annually. This is twenty lines in whatever already schedules the work, and it gives you something the API cannot: a stop that happens before the credits are spent rather than after.
**Endpoint allowlisting** exists as a data-governance control, and **custom rate limits** can be set, both at the team level. They are not per-key dials, so you cannot allow the Maps scrapers for one client and forbid them for another using keys alone. If a client's contract restricts which data sources may be used on their work, enforce that in your runner too. We publish no throughput, concurrency or latency numbers anywhere, including here. Bulk work goes through the async queue, and a specific commitment is a capacity conversation rather than a figure on a marketing page.
**One shared key across all clients.** Then usage attribution is a single undifferentiated line and your invoicing is back to guesswork. This is the default state most agencies arrive in, and the fix is an afternoon. **Treating a named key as an isolation boundary.** It is an attribution and revocation boundary. Any key can call any endpoint the team allows, and spend from the same pot. Naming it after a client does not fence it. **Telling a client they have their own budget.** They do not. If your contract promises a monthly cap, that cap is a promise your runner keeps. Repeating a capability we do not have is how an agency ends up eating an overage. **Leaving revoked clients' keys live.** Revocation is instant and free. Offboarding checklists that skip it are how a former client's automation keeps drawing your credits for a quarter.
Agencies running volume should read [bulk enrich without seats](/use-cases/bulk-enrich-without-seats) for the per-call model against seat-priced tools, and [enrichment backend for platforms](/use-cases/enrichment-backend-for-platforms) if you are embedding this in something you resell. The verification gate in [verify before the sequence push](/use-cases/verify-before-sequence-push) is worth enforcing per client, since bounce damage lands on their domain and your reputation. For delivery into client systems, [HubSpot](/integrations/hubspot) and [n8n](/integrations/n8n) cover the two most common agency stacks. [List build and verify](/use-cases/list-build-and-verify) is the chain most agency runs are built on, [the email finder API](/api/email-finder) is the endpoint reference, and [the pricing page](/pricing) has the credit tiers. The rest of the family sits in [the use-case index](/use-cases).
**Can I set a credit limit on a single key?** No. There are no per-key spend caps, no per-client budgets, and no billed sub-accounts. One team balance, shared by every key. **Can one client's job spend another client's credits?** Yes, in the sense that it spends from the same balance. That is the risk this page exists to state, and the reason the budget check belongs in your scheduler. **Can I see how many credits each client used?** Yes. Usage is attributed per key and exports to CSV. That is the strong half of this story. **What happens when I revoke a key?** That key stops authenticating. Every other key is unaffected. No rollover, no downtime for other clients. **Can I bill a client directly through RichAPI?** No. You buy credits, you invoice your clients, and the per-key export is the evidence behind the invoice. **Can different clients be restricted to different endpoints?** Not through keys. Endpoint allowlisting is a team-level control. Per-client restrictions belong in your runner. **Do I need a credit card?** No. 25 free credits on signup.
Create two named keys, run a job under each, and look at the usage export. If attribution is what you needed, you are done in an hour. If you needed isolated balances, you now know that before you signed anything. **[Get 25 free credits](https://app.richapi.ai)**