Request IDs

Every response from the Exo API carries an X-Request-Id header. It is the one handle that resolves a single call.

HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
X-Request-Id: req_9f2c41ab7d0e5c18

The same value appears inside every problem body as requestId, so a logged error payload is self-describing even if you discarded the headers.

{
  "type": "https://docs.get-exo.com/errors/permission_denied",
  "title": "Permission denied",
  "status": 403,
  "detail": "This operation requires the 'memory:forget' scope.",
  "code": "permission_denied",
  "requestId": "req_9f2c41ab7d0e5c18"
}

It is on every response, including the empty ones

This matters more than it sounds. Four routes return 204 No Content, and a 204 has no body to put a requestId in. Those routes are written to return no body at all rather than an empty response object, precisely so the header the dependency stack stamps survives. So DELETE /v1/keys/{key_id}, DELETE /v1/sandbox/keys/{key_id}, DELETE /v1/subjects/{subject_id} and DELETE /v1/me all give you a request id even though they give you nothing else.

Capturing it

curl -sS -D - -o body.json https://api.get-exo.com/v1/me \
  -H "X-Exo-API-Key: $EXO_KEY" \
  | grep -i '^x-request-id:'

import logging
import httpx

response = httpx.get(
    "https://api.get-exo.com/v1/me",
    headers={"X-Exo-API-Key": EXO_KEY},
)

request_id = response.headers.get("X-Request-Id")
logging.info("exo %s %s -> %s [%s]",
             response.request.method, response.request.url.path,
             response.status_code, request_id)

const response = await fetch("https://api.get-exo.com/v1/me", {
  headers: { "X-Exo-API-Key": process.env.EXO_KEY! },
});

const requestId = response.headers.get("X-Request-Id");
console.info("exo GET /v1/me ->", response.status, `[${requestId}]`);

The habit worth forming: log the request id on every call, not only on failures. When something looks wrong two days later, the successful call is often the one that needs explaining.

What to do with it

Quote it in support. With a request id, one specific call can be found. Without it, the answer starts with “which one”.
Attach it to your own traces. Putting the Exo request id on your span turns a cross-system investigation into a lookup.
Include it in user-facing error surfaces, quietly. A support ticket that arrives with the id already in it skips a round trip.

The format

Request ids look like req_ followed by a hex string. Treat the whole value as opaque: match on it, do not parse it, and do not assume the length is fixed.

Sending your own

There is no supported way to set the request id from the client in v1. The value on the response is the one Exo assigned, and it is the one to quote.

Errors

The problem envelope that repeats this id as requestId.

Rate limits

The other headers on every response, and what to do with them.

Start

Building with Exo

Platform

Request IDs

It is on every response, including the empty ones

Capturing it

What to do with it

The format

Sending your own

Next

Errors

Rate limits

​It is on every response, including the empty ones

​Capturing it

​What to do with it

​The format

​Sending your own

​Next

Errors

Rate limits

It is on every response, including the empty ones

Capturing it

What to do with it

The format

Sending your own

Next