Skip to main content
Before an agent starts a watchlist, backfill, or scheduled job, prove that the same API key can pay for the work. A successful test request only proves one request worked. It says nothing about the account limits, budget gates, or usage rights that apply to a larger run.

​
Check the credential that will run the job

These responses describe the organization behind this key, not a public price list. GET /v1/billing/rates can help compare published rates, but it cannot tell you whether this key can make a later request. Store the redacted responses with the run record; keep the key out of logs, prompts, and saved artifacts.

​
Quote the work before you fan out

Quote each route and intended unit count before starting a loop:
Save requestId, planKey, meterClass, units, budget, and budgetGate with the run record. A quote is an estimate, not a reservation. Set a maximum work-unit count before the job begins, then quote each route in the workload instead of extrapolating from one call.

​
Decide what the agent may retry

Do not retry a refusal until its cause changes. Stop and keep the response context for authorization, billing, budget-gate, hard-cap, or quota errors. For 429, honor Retry-After when present and reduce concurrency rather than starting parallel retry loops. API keys can read billing state, limits, and quotes. Budget changes use a signed-in organization session. Do not give an unattended process a human browser token to raise its own cap.

​
Give a machine its own key

A human organization member can issue a short-lived, single-use sponsor token through agent bootstrap tokens. The machine exchanges it at agent bootstrap, which returns an organization-scoped API key with billing, limits, and MCP installation metadata. This creates a machine credential; it does not give the machine permission to change a budget or mint more credentials. The sponsor-token secret and issued API-key secret are each sensitive and returned once. Do not put either in logs, task output, source control, or a prompt transcript. Expired, used, invalid, scope-limited, and API-key-limit responses are stop conditions, not reasons to mint credentials in a loop.

​
A production-ready first run

For the first scheduled run, use one issuer and one form, save the redacted preflight and quote, and verify the filing identity in the result. Then widen the issuer set only after the job stops cleanly at the configured auth, quota, billing, and budget boundaries. Read plans and pricing for plan and rights selection, and request diagnostics when a run fails.