Overview

Each provider supported by Unipile (LinkedIn, Gmail, WhatsApp, etc.) applies its own rate limits to manage traffic and prevent abuse. If those limits are exceeded, the provider may temporarily block the account, flag it as suspicious, or restrict access — which can lead to degraded service or disconnections.

To avoid this and keep your integrations stable, Unipile enforces its own rate limiting at the Methods API level. Requests that exceed the allowed threshold are rejected by Unipile before they are sent to the provider. This:

Protects your accounts from being throttled or banned by providers
Keeps behavior consistent when calling external APIs
Reduces the risk of errors caused by provider-side limits

For provider-specific quotas and recommendations, see Limits and Restrictions.

Rate limit levels

Unipile can apply up to three levels of rate limiting at the same time. They help prevent abuse and keep usage within each provider’s constraints:

Limit type	Description
Per-method	Generic limit applied to each method individually.
Per-sensitive-method	Stricter limit for specific sensitive methods (e.g. sending messages, invitations). Optional, depending on provider and method.
Per-account	Generic limit applied to all method calls for an account.

Each provider has its own constraints. For example, some providers apply stricter limits when sending messages, so rate limit configurations may vary by provider. Check the Rate Limits section of the dashboard for detailed values and time windows.
Rate limits are enforced using rolling fixed windows: when a request is made and no active window exists, a new window starts. All requests are then counted against that window until it expires, at which point a new window is created on the next request.
You can also use response headers to dynamically adjust your integration’s behavior. See Rate limit for details.
Limits are per account. Hitting a limit for one account does not affect other accounts.
Cached responses do not count toward rate limits. Requests served from cache are not forwarded to the provider. See Manage Cache for details.

When you exceed the limits

API response

When you exceed Unipile’s configured rate limits, the API returns:

HTTP status: 429 Too Many Requests
Error type: api/too_many_requests

When the provider’s rate limiter is hit (e.g. stricter or different window), you get:

HTTP status: 429 Too Many Requests
Error type: provider/too_many_requests

The response body follows the standard error shape (RFC 7807), including type, title, detail, and req_id.

How to handle 429 errors

Identify the source
Use the type field: api/too_many_requests vs provider/too_many_requests.
Back off and retry
Implement retry logic with backoff (e.g. exponential). Avoid immediate retries.
Respect limits
If you often hit api/too_many_requests, consider:
- Using caching for GET requests so fewer calls hit the provider
- Spreading requests over time
- Checking your Rate Limits configuration in the Dashboard
Provider limits
For provider/too_many_requests, refer to Limits and Restrictions and align your usage with the provider’s quotas.

Configuring rate limits

Rate limits are configurable in the Unipile Dashboard under Rate Limits.

Default: Unipile applies a recommended configuration based on each provider’s documented limits.
Customization: You can change these values to match your usage. You can also revert to the default at any time.
Updates: We track provider rate limit changes and update our recommended defaults so your integration stays aligned with upstream constraints.