API Keys

API keys are the credentials used to authenticate requests sent to the Davix H2I public API.

Each request to the public /v1/* endpoints must include a valid API key. Once a request is authenticated, it can continue through the request pipeline and be processed by the H2I engine (PixLab). Requests without valid authentication are rejected before processing begins.

What an API Key Represents #

An API key identifies an authorized client that is allowed to access the Davix H2I public API.

API keys are used by the platform to:

  • identify the calling client
  • authorize access to public API operations
  • apply endpoint access rules
  • associate requests with usage tracking and quota enforcement
  • enforce request-limiting controls

Every request to the public API must include a valid key. Missing, invalid, or expired keys are rejected.

How API Keys Are Used #

API keys must be included in request headers on every public API request.

Davix H2I supports these authentication methods:

Option 1 — Authorization Header #

Send the key as a bearer token:

Authorization: Bearer <YOUR_API_KEY>

Option 2 — X-Api-Key Header #

Send the key in a dedicated header:

X-Api-Key: <YOUR_API_KEY>

Both methods are accepted for the public API.

Authentication Rules #

To ensure secure and consistent API key handling:

  • API keys must be sent in request headers
  • Authorization: Bearer <key> is supported
  • X-Api-Key: <key> is supported
  • in production, API keys sent in the request body are rejected
  • in production, API keys sent in the query string are rejected

If a production request sends the key through api_key in the body or ?key= in the query string, the API returns api_key_location_not_allowed with HTTP 400.

Example Request #

Using X-Api-Key #

curl -sS -X POST "https://pixlab.davix.dev/v1/h2i" \
-H "X-Api-Key: <YOUR_API_KEY>" \
-H "Idempotency-Key: api-keys-page-example-001" \
-H "Content-Type: application/json" \
-d '{
"action": "image",
"html": "<div style=\"width:100%;height:100%;display:flex;align-items:center;justify-content:center;font-family:Arial,sans-serif\">Davix H2I</div>",
"css": "body{margin:0;background:#ffffff;color:#111111}",
"width": 1200,
"height": 630,
"format": "jpeg"
}'

Using Authorization: Bearer #

curl -sS -X POST "https://pixlab.davix.dev/v1/h2i" \
-H "Authorization: Bearer <YOUR_API_KEY>" \
-H "Idempotency-Key: api-keys-page-example-002" \
-H "Content-Type: application/json" \
-d '{
"action": "pdf",
"html": "<main><h1>Davix H2I Report</h1><p>Generated through the API.</p></main>",
"css": "body{font-family:Arial,sans-serif;margin:0;padding:40px}",
"width": 1000,
"height": 1500,
"pdfFormat": "LETTER",
"pdfLandscape": false,
"pdfMargin": 24,
"preferCSSPageSize": true,
"scale": 1,
"printMode": false,
"printBackground": true
}'

These examples use verified public auth behavior and valid documented /v1/h2i request fields.

API Key Lifecycle #

From the platform’s perspective, an API key participates in a lifecycle that includes provisioning, validation, active use, and possible expiration or disablement.

For public documentation, the important behavior is:

  • a valid key can authenticate requests
  • an invalid key is rejected
  • an expired key is rejected
  • requests are associated with that key for access control and usage enforcement

The source documentation confirms lifecycle handling exists in the platform, including provisioning, status checks, and expiration handling, but those management flows are not exposed here as a public customer key-management API page.

API Keys and Usage Tracking #

Davix H2I uses API keys to associate requests with access and usage controls.

Depending on the key type and route behavior, requests may be subject to:

  • endpoint access restrictions
  • request limiting
  • quota enforcement
  • plan-based controls

The public routes apply these controls during request handling. Detailed numeric limits should be documented in your dedicated Errors and Limits section so they are maintained in one place.

Optional: Idempotency Key #

Davix H2I also supports optional idempotency headers for safer retries and request correlation.

You can send either:

  • Idempotency-Key
  • X-Idempotency-Key

A valid idempotency key must:

  • be 8 to 128 characters long
  • use only allowed characters: A-Z, a-z, 0-9, ., _, :, -

When accepted, the API echoes the value back in the Idempotency-Key response header. Invalid values are rejected with invalid_idempotency_key (400).

Managing API Keys Securely #

API keys provide access to the platform and should be stored securely.

Recommended practices:

  • store keys in environment variables or secret managers
  • never expose keys in client-side browser code
  • never commit keys to repositories
  • restrict access to systems that need them
  • rotate or replace keys if exposure is suspected

These practices align with the platform’s server-side header-based authentication model.

API Keys in Applications #

Applications typically store the API key in environment variables and attach it automatically to outgoing server-side requests.

A common pattern is to keep the key on your backend and include it in the request headers when calling Davix H2I. This keeps the key out of browser-delivered code and matches the supported authentication model.

API Keys in Integrations #

In integrations such as automation workflows or plugins, the API key is generally configured once and then attached automatically to API requests.

From the API’s perspective, the authentication requirement remains the same: the outgoing request must include a valid key in the supported header format.

Authentication Errors Related to API Keys #

Common API key-related authentication errors include:

  • invalid_api_key — the key is missing, invalid, or not accepted
  • key_expired — the key has expired
  • api_key_location_not_allowed — in production, the key was sent in the request body or query string

These errors occur before normal request processing starts.

Summary #

API keys are required to access the Davix H2I public API.

Each public API request must include a valid key in request headers. Supported authentication methods are Authorization: Bearer <key> and X-Api-Key: <key>. The platform uses API keys to authenticate clients, apply access rules, and associate requests with usage controls. Once authentication succeeds, the request can continue to the H2I engine (PixLab) for processing.

Was it helpful ?
Scroll to Top