Developer Platform

Limits, rate limits, and idempotency

How clients should handle quotas, throttling, payload boundaries, retries, and safely repeated writes.

Developer limits should be explicit and observable. The API must fail clearly when a client exceeds a rate, payload, plan, storage, or execution boundary; it should never silently drop records or truncate a mutation.

Rate limiting

When a caller exceeds its current request allowance, the gateway returns 429 Too Many Requests and a retry interval. Clients should honor the server value and use exponential backoff with jitter rather than retrying every request immediately.

Idempotent writes

Operations likely to be retried after a network failure should accept an idempotency key. Repeating the same logical request with the same key returns or references the original operation rather than creating a second charge, import, workflow run, or other side effect.

Plan and resource limits

Some limits are application or subscription entitlements rather than traffic controls — for example storage pools, AI budgets, or feature access. Those failures should use structured error codes and include a safe explanation of the resource that needs attention.

Payload and execution limits

Large imports, exports, and long-running actions should move to asynchronous operation resources. Container-backed endpoints also have explicit execution and payload boundaries so a custom service cannot tie up the gateway indefinitely.

The current record-search contract bounds pageSize to 1–100 and query text to 400 characters. Every other request/list bound is defined by its OpenAPI schema or environment response; clients must validate against that contract instead of assuming the record-search values apply globally.

See Pagination, filtering, rate limits, and versioning for copyable request and traversal behavior.

Capability review: 2026-09-14. For exact current technical availability, use the generated API Map and first-class module inventory.