Rate Limits

Appibase rate limits protect the API from abuse, runaway automation, and traffic spikes that could affect platform reliability. They are designed to stop pathological usage, not to interfere with normal checkout and order processing.

When a limit is exceeded, Appibase returns 429 Too Many Requests and includes rate limit headers so clients can back off and retry safely.

How limits work

Limits are tracked per request category and identity scope.
Each rule uses a fixed window: requests / seconds.
Multiple rules may apply to a single request, such as an account rule plus a token rule.
If the API is in monitor mode, Appibase logs the would-be block and still serves the request.

What they protect

Rate limits are mainly intended to protect endpoints that are sensitive to burst traffic or repeated automation:

OAuth token issuance
Authentication and password endpoints
Checkout and payment creation
Webhook-related API traffic
General API read and write traffic

They are not a substitute for authorization, fraud checks, or application-level business rules.

Current categories

Category	Applies to	Scopes	Default limit
oauth_token	POST /oauth/token	client, ip	10 / 60s, 30 / 60s
auth	/api/v1/auth, /api/v1/password	ip	20 / 60s
read	Authenticated GET and HEAD API requests	ip, account, client, user, token	120-300 / 60s
write	Authenticated write API requests	ip, account, client, user, token	60-120 / 60s
checkout	Checkout and payment creation paths	ip, account, client, user, token	30-60 / 60s
webhook	Webhook-related API paths	path, ip	120-300 / 60s

Response headers

When Appibase evaluates a rate limit, it returns standard headers that clients can use to understand the current window:

RateLimit-Limit: 60
RateLimit-Remaining: 12
RateLimit-Reset: 34
RateLimit-Scope: account

If a request is blocked, the response also includes Retry-After when a reset time is available.

How to avoid hitting limits

Retry with exponential backoff after a 429 response.
Use idempotency keys for create flows where retries are expected.
Batch non-urgent requests where possible.
Prefer webhooks over frequent polling for status changes.
Keep merchant traffic and system-to-system traffic separate when designing integrations.

What to expect at Appibase

Appibase aims to allow normal merchant traffic, including seasonal spikes, while still protecting the platform from abuse and accidental overload. If your integration consistently hits limits during legitimate usage, the limits should be revisited rather than worked around.

If you need higher throughput for a specific workload, contact the Appibase team with the endpoint, request pattern, and approximate volume so the limit can be tuned safely.