Rate Limits

Dynamic applies rate limits to keep the platform reliable for everyone. Limits are applied per IP address and per project environment, and are subject to change. When you are rate limited, the API returns a 429 status code with a Retry-After header telling you how many seconds to wait. Design your application to honor Retry-After and retry with exponential backoff rather than on a fixed interval. If your application needs higher limits, email support@dynamic.xyz.

Limits by action

The limits below cover the actions that matter most when designing your application. Two windows apply:

Burst: requests allowed in a 10 second window.
Sustained: requests allowed in a one minute window.

These limits apply to requests from your app through the client SDK.

Action	Burst (10s)	Sustained (1 min)	Limited by
All SDK requests	60	250	IP address
Sign in	—	10	IP address, email, wallet address, or phone
Verification codes (email, SMS, social OTP)	—	3	IP address, email, or phone
Connect a wallet	—	10	IP address
MFA (register, verify, recover)	—	5	IP address
Create an embedded wallet	—	5	Device
Sign a message or transaction	15	30	IP address, wallet
Broadcast a transaction	—	30 per wallet (3000 per caller)	Wallet, caller
Get token balances	—	20	IP address
Update a user	—	4	IP address
Delete a user	—	2	IP address

Limits are also applied per project environment. The values above are the ones you are most likely to hit when scaling your application.

Server SDK limits

These limits apply to server-side calls, such as the Node SDK acting on server wallets with an API key.

Action	Burst (10s)	Sustained (1 min)	Limited by
Sign a message or transaction	500	—	IP address
Delegate a signature	100	—	IP address
Import, refresh, or reshare a key	500	—	IP address

Server signing operations are limited to the equivalent of 50 requests per second, which the 10 second burst window already enforces.

Handling rate limits

Retry a 429 response after the delay in the Retry-After header, with exponential backoff between attempts. Two cases return a different error shape so the response stays consistent with the endpoint’s contract:

Email and SMS verification endpoints return 422 with a too_many_email_verification_attempts or too_many_sms_verification_attempts code:

{
  "code": "too_many_email_verification_attempts",
  "error": "Too many email verification attempts, please try again later"
}

Broadcast a transaction returns 200 with a broadcast_rate_limited code. submissionState is not_submitted, so the transaction never reached the network and retrying with the same idempotency key is safe:

{
  "code": "broadcast_rate_limited",
  "error": "Too many broadcast requests for this wallet. Retry after the indicated delay.",
  "payload": {
    "attempts": 0,
    "retryable": true,
    "submissionState": "not_submitted"
  }
}

Detect rate limiting from the status code or these error codes rather than the response body.

Developer API limits

Endpoints under /environments and /organizations (the Developer API, used with a dashboard token or dyn CLI) have their own limits, separate from the end user SDK limits above. General traffic is limited to 250 requests per 10 seconds and 1500 requests per minute per IP address.

Action	Limit	Limited by
Bulk create users	30 per 10s, 150 per min	IP address
Create embedded wallet	300 per min per IP, 30 per 10s	IP address, project environment
Create user	10 per min	IP address, user
Get user	30 per min	Path
Get user wallets	20 per min	IP address
Verify API key	60 per min	IP address
Organization invites	20 per min	IP address
List users and visitors	300 per min (shared)	Project environment
Webhooks	100 per min	IP address

Webhooks

Outbound webhook deliveries have their own limits. See webhooks limits.

Learn

Build with

Limits by action

Server SDK limits

Handling rate limits

Developer API limits

Webhooks

​Limits by action

​Server SDK limits

​Handling rate limits

​Developer API limits

​Webhooks

Limits by action

Server SDK limits

Handling rate limits

Developer API limits

Webhooks