Overview #
Applications that integrate with Davix H2I should design requests carefully so rendering workflows remain reliable under load. Davix H2I’s HTML-rendering capability is executed by the H2I engine (PixLab), and the external API applies limits, timeout handling, and concurrency controls around those operations.
For public documentation, performance guidance should stay close to the platform behaviors that are actually documented: HTML size limits, render-size controls, rate limits, concurrency controls, quotas, and request tracing.
Design efficient HTML templates #
HTML rendering is one of the core capabilities of Davix H2I, and /v1/h2i accepts HTML layouts, templates, and dynamically generated markup as input. Because HTML input length is explicitly limited, applications should avoid unnecessarily large markup and keep templates as compact as practical.
A practical guideline is to:
- keep layouts simple
- avoid unnecessary markup expansion
- avoid extremely large HTML payloads
The limits documentation shows that /v1/h2i enforces an HTML length cap and returns html_too_large when that limit is exceeded.
Control rendering dimensions #
H2I rendering requests use width and height to control render size. The public API reference documents these parameters for both image mode and PDF mode on /v1/h2i.
Applications should set rendering dimensions intentionally and avoid requesting unnecessarily large outputs. The canonical limits doc shows:
- render width is capped
- render height is capped
widthandheightare clamped to configured ceilings- render pixel area is checked separately and rejected when too large
One source mismatch matters here:
- the limits doc names the pixel-area failure
render_too_large - some external-facing docs elsewhere use
render_size_exceeded
Until your source docs are unified, this page should describe that case as a render-size limit error instead of asserting one final public code.
Respect rate limits #
The platform enforces request limits to protect stability and enforce plan usage. The loaded docs distinguish between:
- public daily limits
- customer burst limits
- customer monthly quotas
When request volume exceeds allowed limits, the API can return:
rate_limit_exceededrate_limit_store_unavailablein some backing-store failure modes
Applications should monitor request frequency and avoid unnecessary spikes in traffic.
Because you want numeric limits centralized under Errors and Limits, this page should explain the behavior without repeating values here.
Manage concurrency #
Each external endpoint has its own concurrency semaphore. For /v1/h2i, the limits doc shows that H2I requests acquire a bounded worker slot and return server_busy if they cannot obtain one within the configured wait window.
Applications should avoid sending very large bursts of simultaneous rendering requests. Practical client-side approaches include:
- queueing requests
- pacing requests over time
- avoiding unnecessary parallel spikes
The important documented behavior is that concurrency pressure on /v1/h2i can surface as server_busy.
Monitor usage quotas #
Customer API keys can be subject to monthly quota enforcement. The limits docs show that all four external /v1/* routes reserve quota before heavy execution and return monthly_quota_exceeded when quota is exhausted.
Applications that generate high volumes of output should monitor usage so automated workflows do not fail unexpectedly due to quota exhaustion.
Because you want public limit values kept in one place, this page should link to the centralized limits page rather than restating quota numbers here.
Use reusable templates #
The loaded documentation explicitly supports HTML layouts, templates, and dynamically generated markup as the input model for H2I rendering. Reusing templates is therefore a natural implementation pattern for workflows such as reports, certificates, and social-media-style generated assets.
Template reuse helps keep rendering workflows consistent and easier to maintain at the application level. This is not a special platform feature, but it fits the platform’s documented HTML-rendering model.
Avoid unnecessary retries #
The error architecture documents temporary failure conditions such as:
server_busytimeout- some cases of
rate_limit_exceeded
By contrast, request-shape failures such as missing_field, invalid_parameter, and html_too_large are request-correction issues rather than good retry candidates.
Because the loaded docs do not define an official retry schedule, public documentation should recommend cautious retry behavior without prescribing exact wait intervals unless you document them formally elsewhere.
Track request identifiers #
The platform attaches request IDs early in the request lifecycle and mirrors them in API responses and headers. Standard JSON API envelopes almost always include request_id, and the request ID is also exposed through the Request-Id response header.
Applications should log request identifiers for failed or slow operations so specific requests can be traced during debugging.
Summary #
Efficient integration with Davix H2I depends on keeping HTML inputs reasonable, choosing render dimensions carefully, respecting rate limits, managing parallel request volume, monitoring quota usage, and logging request identifiers. These are the main performance-related behaviors that are directly supported by the loaded platform documentation.
