Usage quotas define how much of the Davix H2I service your account or plan can use during a quota period.
These quotas help regulate access to processing capacity across the platform. Because Davix H2I performs rendering, image processing, PDF processing, and analysis operations through the H2I engine (PixLab), the platform applies quota controls to help keep service usage fair and predictable.
Why Usage Quotas Exist #
Davix H2I provides backend operations that consume platform processing resources, including:
- HTML rendering
- image processing
- PDF processing
- analysis-related operations
Usage quotas help the platform:
- provide fair access across customers
- prevent excessive consumption
- support predictable capacity planning
- maintain stable service behavior across plans
These controls are part of the customer-facing usage model supported by the platform’s plan system.
How Usage Quotas Work #
For customer-facing access, usage quotas are tied to your account or plan.
The loaded platform documentation confirms a monthly quota model for customer plans. During request handling, the platform checks whether the authenticated customer has remaining quota available before allowing the request to continue through normal processing. If the available monthly quota has already been exhausted, the request is rejected.
Because you want all concrete limit values maintained in one place, this page should explain the quota model without listing numeric quota values. Those customer-facing values should appear only in the dedicated Errors and Limits section.
Quota Period #
The customer quota model confirmed in the loaded documentation is a monthly quota model. Customer plans include a monthly quota allocation, and requests are checked against that allocation during request processing.
When a Quota Is Reached #
If the remaining monthly quota is exhausted, the API rejects additional requests that would exceed the allowed quota.
The API returns:
- HTTP
429 - error code
monthly_quota_exceeded
This means the request was not accepted because the account or plan no longer has sufficient quota available for the current monthly period.
Example Error Response #
{
"error": {
"code": "monthly_quota_exceeded",
"message": "Monthly quota exceeded."
},
"request_id": "<REQUEST_ID>"
}
The platform’s error model also includes request_id, which can be used for support and diagnostics.
How Quota Enforcement Fits Into Request Processing #
For customer traffic, quota checks are part of the request lifecycle.
The loaded docs confirm this general pattern:
- the request is authenticated
- the platform checks whether quota is available
- if quota is available, the request can continue
- if quota is not available, the request is rejected with
monthly_quota_exceeded
The internal implementation uses reserve, finalize, and refund behavior to keep quota accounting correct across success and failure paths, but customer-facing documentation does not need to expose those internal accounting details. Publicly, the important behavior is that quota is checked as part of request admission and enforced before additional usage is allowed.
Monitoring Usage #
Applications and integrations should monitor usage so they do not unexpectedly stop when quota is exhausted.
Recommended practices:
- track successful operations in your own application
- monitor API responses for quota-related errors
- estimate usage per workflow or automation path
- avoid unnecessary duplicate processing
- review the customer-facing limits page regularly
The exact quota amounts and plan-specific values should be maintained only in the dedicated Errors and Limits section.
Designing Systems Around Quotas #
To work effectively within usage quotas:
- avoid sending duplicate processing requests
- cache reusable outputs where appropriate
- design workflows to minimize unnecessary regeneration
- store important generated files in your own systems when needed
- spread non-urgent work sensibly over time
- review the dedicated limits documentation when planning integrations
These practices help reduce wasted processing and make quota usage more predictable across applications and automation flows.
Plan-Based Quotas #
Usage quotas are plan-based.
The loaded plan documentation confirms that customer plans define quota and capability limits, including monthly usage allocation and other request constraints. Different plans can therefore provide different quota allowances and operational limits. To keep all changeable values in one place, the specific plan-based quota values should be documented only in the Errors and Limits section.
Usage Quotas and Other Limits #
Usage quotas are one part of the broader request control model.
Depending on the endpoint and plan, other controls may also apply, such as:
- rate limits
- upload limits
- file count limits
- dimension limits
- page limits
- endpoint availability by plan
To avoid duplication and make future updates easier, those customer-facing values should be centralized in the Errors and Limits section and referenced from other pages instead of repeated throughout the documentation.
Summary #
Usage quotas define how much of the Davix H2I service a customer can use during the quota period supported by their plan.
The loaded platform documentation confirms a monthly customer quota model. When the available monthly quota is exhausted, the API returns monthly_quota_exceeded with HTTP 429, and additional requests are not processed until quota becomes available again under the applicable plan period. Specific customer-facing quota values and plan limits should be maintained only in the Errors and Limits section.
