Radar API / Developer guide
Usage, retries & billing
Unique opportunities, request IDs, rate limits and prepaid credit.
Read as MarkdownWhat consumes allowance
A canonical opportunity counts once per account and plan period on first successful delivery. Repeated delivery in that period, counts, empty results and errors consume no opportunity allowance. REST and MCP share the same account quota. Rate limits still apply to requests that use no opportunity allowance.
Periods and limits
Free includes 1,000 unique opportunities per UTC calendar month, 2 requests per second and up to 25 per page. Builder includes 25,000 unique opportunities per Stripe billing period, 10 requests per second and up to 100 per page. Growth includes 250,000 unique opportunities per Stripe billing period, 20 requests per second and up to 100 per page. Account restrictions may lower effective limits. Enterprise terms are account-specific.
Response usage headers
X-Radar-Opportunity-Limit, X-Radar-Opportunity-Used and X-Radar-Opportunity-Remaining describe plan allowance. X-Radar-New-Opportunity-Count describes new billable deliveries; X-Radar-Period-End gives the reset. X-Radar-Balance-Millicents and X-Radar-Usage-Charge-Millicents use millicents, with 100,000 millicents per US dollar. X-RateLimit headers describe request throttling, a separate limit. Read the account for the current plan and prepaid balance.
Prepaid usage
After included allowance, newly delivered opportunities consume prepaid credit at $0.004 each. A response must be covered atomically or returns 402 insufficient_balance. Purchased credit does not expire. Radar does not automatically charge a saved card for usage. Legacy wallet accounts retain their existing contract. Use the pricing page and account for subscription and balance actions.
Request IDs and retries
Generate a new X-Request-ID for every request, including retries. It is a correlation ID, not an idempotency key. Reusing one may return 409 duplicate_request_id. On a network timeout, delivery may already have been recorded. A retry with a new ID remains subject to canonical-ID deduplication in the same billing period, but can see changed inventory.
Backoff
On 429, obey Retry-After. Use explicit timeouts and a small retry budget with backoff for transient network or 5xx failures. Do not retry 400, 401, 402, 403 or 422 without fixing the cause. Record status, safe error code and request ID, never the credential or whole customer payload.