Skip to main content
Turnkey rate limits API traffic to protect service availability. Rate limits control request throughput; resource limits control how many wallets, users, and other resources an organization can contain.

​
Plan rates

The published default rates vary by plan: There is also a default 10 RPS per-sub-organization limit across plans. Rates are enforced as per-minute buckets that refill continuously, so short bursts above the per-second rate are absorbed until the bucket empties. An organization’s custom limits can differ from these defaults. Contact Support to confirm capacity for your workload or request an adjustment.

​
How limits are applied

A request can count toward multiple rate-limit buckets:
  • Shared across a parent organization and its sub-organizations. The plan rate is applied here.
  • A single organization or sub-organization. The 10 RPS per-sub-organization default is applied here.
  • A particular query endpoint or activity type.
  • A group of related operations, such as signing.
These scopes overlap. An endpoint-specific limit does not replace the shared parent-level limit, and a sub-organization’s own allowance does not exempt it from that shared limit. The plan rates above are not a separate allowance for every API method. Custom limits that Support configures for a specific sub-organization take precedence over the default per-sub-organization limit. Which limits apply depends on the operation and your organization’s configuration. Organization-scoped limits are shared across your servers and API credentials. Distributing requests across machines or IP addresses does not increase those allowances. Pace traffic across workers and account for status polling as well as activity submissions.

​
Endpoint-specific limits

The Broadcast EVM transaction and Broadcast SVM transaction activities, and the Get balances query, have separate default 10 RPS limits across all plans. Do not assume your plan’s rate applies to these endpoints. Authentication also has abuse-prevention limits. See OTP rate limits for the per-user controls used with OTP authentication.

​
Handle rate-limit errors

When a request is rate limited, the API returns HTTP 429 with one of these messages, depending on which limit was exceeded: Query endpoints and unauthenticated endpoints return Resource exhausted; please wait a minute and try again. If you keep submitting activities while limited, the API returns one of the “has been rate limited” messages listed under API errors. Handle the 429 status in your retry logic rather than matching on message text. A 429 that says signing is disabled because your organization is over its allotted quota is a monthly signing quota, not a rate limit; see API errors.
  • Rate limits usually clear within a few seconds. Start retries with a short delay, then back off exponentially with jitter. Avoid having every worker retry at the same moment.
  • The API does not return rate-limit or Retry-After headers. Schedule retries from your own backoff logic.
  • For activity retries, preserve the original request body while it is within the signed-request validity window. Changing timestampMs creates a new activity. If you have an activity ID, query its status rather than creating another activity.
  • If throttling persists, contact Support with your organization ID, endpoint or activity type, timestamps, and observed request rate.
See API errors for other failure modes.