Orb · Rate Limits

Orb Billing Rate Limits

Orb does not publish a hard, numeric rate limit for production API usage or a maximum request payload size; the docs instead ask customers to notify Orb before changing request volume or payload size by an order of magnitude from initial setup. The event ingestion path (POST /ingest) is the primary high-throughput surface and supports batched events per request. Test-mode event ingestion is constrained (documented around 2,000 events/minute and ~10 requests/second). When limits are exceeded the API returns HTTP 429 Too Many Requests, and Orb recommends retrying with exponential backoff. Specific production per-endpoint values are not reconciled in this artifact.

Orb Billing Rate Limits is the machine-readable rate-limit profile for Orb on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 4 rate-limit definitions, measuring requests, events, and bytes.

The profile also includes 2 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Billing, Usage-Based Billing, Metering, Subscriptions, and Rate Limiting.

4 Limits Throttle: 429
BillingUsage-Based BillingMeteringSubscriptionsRate LimitingQuotasThrottling

Limits

Production API account
requests
no hard published limit
Orb asks for a heads-up before changing volume by an order of magnitude; no fixed numeric cap is documented.
Event Ingestion (production) account
events
batched, coordinate high volume with Orb
POST /ingest accepts batched events; high-throughput ingestion is supported and coordinated with Orb.
Event Ingestion (test mode) account
events
~2000 events/minute, ~10 requests/second
Test-mode ingestion is rate limited; production ingestion is not capped at these values.
Request Payload Size request
bytes
no hard published limit
No fixed maximum payload size documented; notify Orb before large changes.

Policies

Backoff Strategy
On HTTP 429, retry the request with exponential backoff.
Idempotency
Mutating requests and event ingestion support idempotency keys so retries are safe and de-duplicated.

Sources