Rate Limits

Davix H2I applies rate-limiting controls to protect the public API and maintain stable service behavior across customer traffic. These limits control how quickly requests can be accepted on the external /v1/* API.

Requests sent to Davix H2I are processed by the platform layer behind the product, including the H2I engine (PixLab) for rendering workflows. When a request exceeds the applicable request-frequency limit, the API returns a rate-limit error instead of continuing with processing.

Rate-limit-related errors #

When a rate limit is exceeded, the API returns:

Error code
rate_limit_exceeded

HTTP status
429

Standard API error responses use the shared JSON error envelope:

{
  "status": "error",
  "code": "rate_limit_exceeded",
  "message": "Rate limit exceeded.",
  "error": {
    "code": "rate_limit_exceeded",
    "message": "Rate limit exceeded."
  },
  "request_id": "<REQUEST_ID>"
}

A related error is:

Error code
rate_limit_store_unavailable

HTTP status
503

This error indicates that the rate-limit persistence layer was unavailable and the request could not be processed.

Customer burst limits #

Davix H2I customer API keys can be subject to short-window burst limiting.

Burst limiting uses these plan settings:

• request limit
• window duration
• scope of endpoints covered

Burst-limit behavior:

• if the burst limit is zero or less, burst limiting is disabled
• over-limit requests return rate_limit_exceeded
• the window defaults to 60 seconds when no positive window is set
• the burst scope can apply to H2I only or to all supported external processing endpoints

Rate limits by plan #

Plan	Requests	Window	Scope
Free	5	60 seconds	All supported external processing endpoints
Pro	20	60 seconds	All supported external processing endpoints
Business	30	60 seconds	All supported external processing endpoints

These are the current customer burst limits for Free, Pro, and Business plans. The current plans apply burst limiting across all supported external processing endpoints.

What rate limits apply to #

The rate limits on this page apply to customer-facing request frequency on the external API, including:

• POST /v1/h2i
• POST /v1/image
• POST /v1/pdf
• POST /v1/tools

Rate limits are different from quotas #

Rate limits and monthly quotas are separate:

• Rate limits control how quickly requests can be accepted
• Monthly quotas control how much total usage is allowed during a billing period

Monthly quota failures return:

• monthly_quota_exceeded
• HTTP 429

but they are not the same as rate-limit failures and should be handled separately in application logic.

How applications should handle rate limits #

Applications integrating with Davix H2I should treat rate_limit_exceeded as a temporary refusal and reduce request pressure before retrying.

Practical approaches include:

• slowing request frequency
• avoiding unnecessary burst traffic
• queueing work instead of sending large spikes at once
• reusing prior outputs when possible instead of regenerating the same asset repeatedly

Store failure behavior #

In some cases, a failed request related to rate limiting may not mean that the request volume itself exceeded the allowed threshold. The API can also return:

• rate_limit_store_unavailable
• HTTP 503

Applications should treat this as a temporary service-side failure rather than as a customer overuse condition.

How to use this page #

Use this page as the canonical reference for customer-facing request-frequency limits. Other documentation pages should link here instead of repeating request-rate values. For monthly quotas, file limits, upload caps, render caps, page caps, and timeout-related request allowances, use Usage Limits.

Summary #

Davix H2I uses customer-facing burst rate limiting on the external API to control short-window request spikes.

Relevant public rate-limit errors are:

• rate_limit_exceeded (429)
• rate_limit_store_unavailable (503) in store-failure scenarios