# Usage, retries & billing

Unique opportunities, request IDs, rate limits and prepaid credit.

## What 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.