Adapty · Rate Limits

Adapty Rate Limits

Adapty applies per-account rate limiting to its Server-Side REST API to protect platform stability. Adapty documents that server-side requests should be kept to reasonable volumes and recommends batching and caching where possible; exceeding limits returns HTTP 429. Specific numeric per-endpoint request-per- second/minute limits are not published in a reconciled table and vary by account and endpoint (profile reads vs. transaction writes). This artifact is not reconciled to exact values.

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

It captures 4 rate-limit definitions, measuring requests and events.

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

Tagged areas include Mobile, Subscriptions, Server-Side, Rate Limiting, and Quotas.

4 Limits Throttle: 429
MobileSubscriptionsServer-SideRate LimitingQuotasThrottling

Limits

Server-Side API Requests account
requests
see provider documentation
Per-account request rate on the Server-Side REST API; varies by endpoint.
Profile Reads account
requests
see provider documentation
GET /profile/ reads; cache profile state where possible to avoid throttling.
Transaction / Access-Level Writes account
requests
see provider documentation
set-transaction, grant/revoke access level, and Stripe validation writes.
Webhook Delivery account
events
n/a (outbound)
Adapty delivers events to your endpoint; you must respond promptly (2xx) or Adapty retries with backoff.

Policies

Backoff Strategy
Clients should implement exponential backoff with jitter on 429 responses and honor any Retry-After header.
Batching & Caching
Batch server-side operations and cache profile/access-level state to stay within limits; rely on the SDK for client-facing reads.

Sources