Rate Limits

The Sent API v3 implements rate limiting to ensure platform stability and fair access for all users.

Rate limits apply per customer account: all API keys for the same account share one rate limit pool, and requests scoped to a profile via the x-profile-id header count against the organization's pool. Unauthenticated requests are limited per IP address.

For backoff, monitoring, and throttling implementations, see How to handle Sent API rate limits.

Rate Limit Tiers

Standard Endpoints

Most API endpoints, including message sending (POST /v3/messages), use the standard limit:

Tier	Limit	Window
Standard	200 requests per minute	Sliding 60-second window

Sensitive Endpoints

Two endpoints that perform sensitive operations have stricter limits:

Tier	Limit	Window
Sensitive	10 requests per minute	Fixed 60-second window

Sensitive endpoints:

Webhook secret rotation (POST /v3/webhooks/{id}/rotate-secret)
Webhook test delivery (POST /v3/webhooks/{id}/test)

All other endpoints, including user invitation (POST /v3/users) and profile completion (POST /v3/profiles/{profileId}/complete), use the standard limit of 200 requests per minute.

Which Requests Count

Requests rejected during authentication (401, 403) do not count against rate limits. All other requests count toward your limit, including those that fail validation (400, 422).

Rate Limit Headers

Rate limit headers are sent only on 429 Too Many Requests responses. Successful responses do not carry X-RateLimit-* headers, so there is no per-request quota readout. Treat 429 responses as the signal that you have reached the limit.

Retry-After: 60
X-RateLimit-Limit: 200
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1705312800

Header Reference

Header	Description	Example
`Retry-After`	Seconds until you can retry	`60`
`X-RateLimit-Limit`	Maximum requests allowed in the window	`200`
`X-RateLimit-Remaining`	Requests remaining (always `0` on 429)	`0`
`X-RateLimit-Reset`	Unix timestamp when the current window expires	`1705312800`

Standard limits use a sliding window, so capacity returns gradually as requests age out of the preceding 60 seconds rather than resetting at a fixed time.

429 Response Body

When rate limited, the API returns error code BUSINESS_002 in the standard error envelope:

{
  "success": false,
  "status": 429,
  "error": {
    "code": "BUSINESS_002",
    "message": "Rate limit exceeded. Please retry after 60 seconds.",
    "doc_url": "https://docs.sent.dm/reference/api/rate-limits"
  },
  "meta": {
    "request_id": "req_abc123",
    "timestamp": "2024-01-15T10:30:00Z",
    "version": "v3"
  }
}

Rate Limiting by Endpoint

Rather than enumerate every operation, the rule is:

Scope	Limit	Window
Webhook secret rotation (`POST /v3/webhooks/{id}/rotate-secret`)	10/min	Fixed 60-second
Webhook test delivery (`POST /v3/webhooks/{id}/test`)	10/min	Fixed 60-second
Every other v3 endpoint	200/min	Sliding 60-second

The exception list above is exhaustive: the two sensitive endpoints listed here are the only exceptions in v3. Contacts, messages, templates, webhooks, users, profiles, conversations, brands, number lookup, and GET /v3/me all use the standard 200/min limit, so a new endpoint is at 200/min unless this page says otherwise.

The /v2 API has its own limits, including a separate daily cap on quick-message. See Rate limits (v2).

Increasing Rate Limits

Higher limits are available for legitimate high-volume use cases. Contact support@sent.dm with your use case, expected volume, and the rate limit issues you are experiencing.

Before requesting an increase, confirm your integration is not wasting its budget on avoidable requests. How to handle Sent API rate limits covers caching, throttling, and using webhooks instead of polling.

How to handle Sent API rate limits: exponential backoff, 429 monitoring, client-side throttling, and paced batch processing.
How to retry Sent API requests safely: idempotency keys for retried mutations.
How to handle Sent API errors: the error envelope and code-based branching.

On this page