Otter · Rate Limits

Otter Rate Limits

The Otter (TryOtter) Public API enforces rate limits at two levels. A global IP-based limit applies across all requests from an IP address, and a finer-grained per-endpoint limit is applied individually at the store level per application — i.e. each (application, store, endpoint) combination has its own budget. Documented per-endpoint budgets are expressed in requests per minute and range from 2/min (store status and account-pairing operations) to 32/min (high-volume order, inventory, and menu-availability operations), with 8/min and 16/min tiers in between. Exceeding any limit returns HTTP 429. Limits are not self-service; raising them is handled through your Otter Technical Account Manager (TAM).

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

It captures 6 rate-limit definitions, measuring requests_per_second and requests_per_minute.

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

Tagged areas include Rate Limiting, Restaurant, Order Management, and Online Ordering.

6 Limits Throttle: 429 Quota: 429
Rate LimitingRestaurantOrder ManagementOnline Ordering

Limits

Authenticated requests (per IP) IP
requests_per_second · second
20
Counts all authenticated requests made by the IP address, across all endpoints.
Unauthenticated requests (per IP) IP
requests_per_minute · minute
3
Applies to requests that are not authenticated (e.g. token acquisition before a valid bearer token is presented).
Per-endpoint — low-tier operations application/store/endpoint
requests_per_minute · minute
2
Applies to sensitive low-volume operations such as Update Store Status and account-pairing store-link callbacks (e.g. updateStoreStatusEndpoint, upsertStorelinkWebhook).
Per-endpoint — standard-tier operations application/store/endpoint
requests_per_minute · minute
8
Default tier for most endpoints and webhook callbacks (e.g. ping, customer-payment updates, menu publish/upsert-hours callbacks, inventory shipment listing).
Per-endpoint — elevated-tier operations application/store/endpoint
requests_per_minute · minute
16
Applies to higher-frequency operations such as the generalized callback error endpoint (publishError) and the send-menu callback.
Per-endpoint — high-tier operations application/store/endpoint
requests_per_minute · minute
32
Applies to high-volume order and inventory operations such as order status updates, inventory summary/shipment listing and creation, and menu-entity-availability callbacks.

Policies

Two-level enforcement
Limits are enforced both globally by IP address and individually per (application, store, endpoint). A request can be throttled by either level independently.
Throttle response
When any limit is exceeded the API returns HTTP 429 until the request rate drops below the threshold. The documentation does not specify a Retry-After header.
Backoff and retry
Clients should slow down and retry after a 429. No explicit backoff interval is published; exponential backoff is recommended practice.
Raising limits
Rate limits are not self-service. Persistent throttling should be escalated to your Otter Technical Account Manager (TAM) to review limit increases.
Scope binding
Per-endpoint budgets are scoped to a single store under a single application; the same endpoint for a different store or application has an independent budget.

Sources