Turnkey · Rate Limits

Turnkey Rate Limits

Turnkey enforces request rate limits on its public API (api.turnkey.com) and gates activity throughput through plan-level wallet caps and per-month signature allotments rather than a single published RPM figure. Signing and administrative activities are additionally gated by the organization's policy engine and root-quorum consensus, which can hold an activity in a CONSENSUS_NEEDED state. Specific per-endpoint request-per-second limits are not publicly reconciled in this artifact.

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

It captures 5 rate-limit definitions, measuring requests, wallets, signatures, and activities.

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

Tagged areas include Crypto, Wallets, Key Management, Signing, and Secure Enclaves.

5 Limits Throttle: 429
CryptoWalletsKey ManagementSigningSecure EnclavesRate LimitingQuotasThrottling

Limits

API Request Rate organization
requests
see provider documentation
Per-organization HTTP request rate limiting on api.turnkey.com; specific RPS not publicly published.
Wallet Cap organization
wallets
tier-bound (Free 100, PAYG 1,000, Pro 2,000, Enterprise unlimited)
Hard cap on number of wallets per organization, set by plan.
Monthly Free Signatures organization
signatures
25
Free tier includes 25 free signatures per month; beyond this, signatures are billed per signature.
Policy Engine Gating organization
activities
policy-bound
Each submit activity is evaluated against organization policies before execution; denials are not throttling.
Root Quorum Consensus organization
activities
quorum-bound
Activities requiring consensus pause in ACTIVITY_STATUS_CONSENSUS_NEEDED until the root quorum threshold of approvals is met.

Policies

Tiered Caps
Wallet caps and free-signature allotments increase with plan tier; Enterprise lifts wallet caps entirely.
Backoff Strategy
Clients should implement exponential backoff with jitter on HTTP 429 and honor any Retry-After header.
Stamp Replay Protection
Each request carries a timestampMs in the stamped body; stale or replayed stamps are rejected.

Sources