Request IDs & Debugging

Canonical Qufas request ID

Every gateway request receives a public-safe req_* identifier. The stable response header is x-qufas-request-id; X-Request-ID is returned as a compatibility alias with the same value.

1x-qufas-request-id: req_abc1232X-Request-ID: req_abc123

Client correlation input

You may send X-Request-ID as client correlation input. Qufas still generates and returns its canonical request ID; the client value does not replace it and is not echoed as the response request ID.

1curl -i https://qufas-ai.vercel.app/v1/models \2  -H "Authorization: Bearer $QUFAS_API_KEY" \3  -H "X-Request-ID: order-4821"

SDK access

1# Python management SDK2print(response.request_id)3 4// Node SDK5console.log(response.requestId);6console.log(stream.requestId);

Streaming usage metadata can also contain metadata.request_id, but the response header remains the transport-level identifier.

What the ID correlates

• Support cases and application logs
• Request logs, routing snapshot, and provider attempts
• Usage and billing transaction records
• Latency, TTFT, throughput, cost, and normalized errors

Debug an inference request

1. Capture x-qufas-request-id from the inference response.
2. Call GET /v1/generations/{request_id} with the same API key.
3. Inspect provider, latency, usage, stored cost, fallback attempts, and normalized error metadata.

1# req_original came from the inference response header2curl https://qufas-ai.vercel.app/v1/generations/req_original \3  -H "Authorization: Bearer $QUFAS_API_KEY"

The body Generation ID is the original inference request. The lookup response header contains a different request ID for the GET itself. See the Generations API.