Get Your API Key

Before using Davix H2I, you must have a valid API key. External /v1/* requests are authenticated through API-key-based access, and requests without a valid key are rejected before processing.

The API key is the credential that allows your application, workflow, or connected system to access the public Davix H2I API. It should be treated as a sensitive secret and handled accordingly.

Why an API Key Is Required #

Davix H2I performs backend processing operations such as HTML rendering, image processing, PDF workflows, and analysis-related tasks. Because these operations are part of a controlled backend service, requests must be authenticated before they are allowed to reach the processing layer.

At the public API level, the API key is used to authenticate the caller and determine whether the request is allowed to proceed. For customer keys, the broader platform logic also applies plan-based access rules, endpoint permissions, and quota behavior as part of the request lifecycle.

How API-Key Authentication Works #

All public /v1/* routes use API-key authentication. The authentication middleware accepts either of the following header formats:

Option 1 — X-Api-Key #

Send the API key in the X-Api-Key request header. This is one of the two supported public authentication methods for external requests.

Option 2 — Authorization: Bearer <key> #

Send the API key as a bearer token in the Authorization header. This is also a supported authentication method for external /v1/* routes.

Both methods are accepted by the public API.

Supported Authentication Methods #

In production, the supported public authentication locations are:

• X-Api-Key: <your_api_key>
• Authorization: Bearer <your_api_key>

Production Restriction #

In production, Davix H2I explicitly rejects API keys sent in these locations:

• request body field: api_key
• query string parameter: ?key=

If a request sends the key through the body or query string in production, the platform returns:

• api_key_location_not_allowed with HTTP 400.

In non-production environments, those body/query fallbacks may still be accepted, but public integrations should use header-based authentication.

Authentication Failures #

If the API key is missing or invalid, the request is rejected with:

• invalid_api_key and HTTP 401

If a customer key has expired, the request is rejected with:

• key_expired and HTTP 401

These checks happen before the request is allowed to continue to the route handler.

Optional: Idempotency Key #

Davix H2I also supports an optional idempotency header for safer retries:

• Idempotency-Key
• X-Idempotency-Key

When present, the idempotency value must satisfy these validation rules:

• non-empty
• length between 8 and 128 characters
• characters limited to [A-Za-z0-9._:-]+

If the idempotency value is invalid, the request is rejected with:

• invalid_idempotency_key and HTTP 400

When valid, the platform echoes the value back in the Idempotency-Key response header.

Keeping Your API Key Secure #

Because an API key grants access to the public Davix H2I service, it should be handled as a secret credential.

Recommended practices for public integrations include:

• store the key securely on the server side
• keep it out of client-side code
• avoid committing it to repositories
• restrict access to the systems and services that truly need it
• replace the key if you believe it has been exposed.

Where the API Key Is Used #

A valid API key is required for the public processing endpoints, including:

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

These are the public endpoint groups through which customers access Davix H2I capabilities.

Summary #

To use Davix H2I, you must authenticate each public /v1/* request with a valid API key. In production, the supported methods are X-Api-Key and Authorization: Bearer <key>, while body and query-string key locations are explicitly rejected. Optional idempotency headers are also supported for safer retries.

The biggest fixes here were removing unsupported dashboard assumptions, removing unfinished placeholders, and tightening the production authentication rules so they exactly match the uploaded source files.