Request IDs
Every response carries a request id; send your own to follow a request through.
What the API sends
Every response has an X-Request-Id header. Every error repeats it as request_id in the problem document, and a product's own documents carry the request_id they were produced under (in Ciresk CI, every job and summary), so a --json envelope can name it. Include it when you report a problem: it is the one key that finds the request in the product's logs and audit rows.
HTTP/1.1 201 Created
Content-Type: application/json
X-Request-Id: 3f1c9a52-8e0b-4d7a-9c61-0b5e2f7d4a18What you can send
| Header | Effect |
|---|---|
X-Request-Id | Your own id, up to 128 letters, digits, - or _; the product adopts it and echoes it back, so your logs and the product's share one key. Any other value is replaced by an id the product mints. |
The ciresk ci CLI prints the request id on every error line and in the request_id field of its --json envelope; an MCP error result carries it in _meta["ciresk/problem"]. In Ciresk CI, audit rows record the X-Request-Id of every job submission, cancellation, lease, policy change and token exchange.