3 min read

Request ID Header

Every response from api.zenovay.com includes an x-request-id header. It is the single piece of information that lets Zenovay support trace a specific API call from your client all the way through the platform's internal logs.

What it looks like

x-request-id: 01HVNXT7K8M3F2Y9R6P4ZQAB1C

Each request gets a unique 26-character ULID generated at the edge. The ID is also tagged on every error report Zenovay's monitoring captures, so a single string ties together what your client saw and what the platform's logs recorded.

When it appears

Every successful response (2xx) — useful for retroactive debugging if something looked wrong after the fact
Every error response (4xx, 5xx) — the most useful case; include this with your support ticket
Tracker ingestion — pageview, event, and revenue calls all carry it
REST API and CLI endpoints — /api/external/v1/*, /v1/cli/*, MCP, etc.
Authentication endpoints — auth.zenovay.com calls also include it

How to read it from your code

From `fetch` responses

const response = await fetch('https://api.zenovay.com/api/external/v1/...', {
  headers: { Authorization: `Bearer ${apiKey}` },
});

const requestId = response.headers.get('x-request-id');

if (!response.ok) {
  console.error(`Zenovay API error (request ${requestId}):`, response.status);
}

From `axios`

try {
  const result = await axios.get('https://api.zenovay.com/api/external/v1/...', {
    headers: { Authorization: `Bearer ${apiKey}` },
  });
  console.log('request id:', result.headers['x-request-id']);
} catch (err) {
  console.error('failed; request id:', err.response?.headers?.['x-request-id']);
}

From `curl`

Add -i to print response headers:

curl -i https://api.zenovay.com/api/external/v1/analytics/<websiteId>/visitors \
  -H "Authorization: Bearer YOUR_KEY"

How to use it with support

When something goes wrong:

Capture the x-request-id from the failing response.
Include it in your support ticket or community post — verbatim, in a code block.
Note the rough UTC timestamp of the call (within a minute is usually enough).
If you can, include the request URL and the response status code.

With those four pieces of information, Zenovay support can usually find the exact call in seconds and tell you why it failed.

Logging tips

For production code that calls the Zenovay API, capture x-request-id on every error path:

function logZenovayError(label, response) {
  const requestId = response.headers.get('x-request-id') ?? 'unknown';
  console.error(`[zenovay:${label}] status=${response.status} req=${requestId}`);
}

If you use a structured logger (pino, winston, datadog, sentry, etc.), set the request id as a structured field rather than embedding it in the message — that way you can search and group by it.

CORS

x-request-id is exposed via the Access-Control-Expose-Headers response header on every CORS-enabled endpoint, so browsers can read it from JavaScript without any extra configuration on your side.

What you should not do with the request id

Don't try to reverse-engineer information out of it. It's a ULID, not an encoded payload.
Don't use it as a deduplication key — Zenovay handles request idempotency separately, on the resources that need it.
Don't expose it on a public-facing surface (a generic "Something went wrong" page is fine; a "Request 01HVNX... failed" page on a public marketing site is more information than your visitors need).