/v1 API is logged — success or failure. Each response includes an x-request-id header that you can use to find the request later. Request logs record metadata only — never secrets, payloads, or results.
What a request log contains
What request logs do not contain
- No request bodies or response bodies.
- No API key secrets or hashes.
- No customer information.
- No simulation results (simulations are non-persistent by design).
Endpoints
List request logs
Query parameters
Get a single request log
request_id. The ID is scoped to your account and environment — an unknown or foreign ID returns 404 with request_log_not_found.
Scoping
Request logs are scoped to the authenticated key’s account and environment:- A Test key sees only Test-environment logs.
- A Live key sees only Live-environment logs.
- A key from account A cannot see logs from account B.
logs:read scope grants access to your own traffic only — never to another account’s traffic.
In the workspace
The Developers page also shows request logs in the human console. Unlike the API (which is scoped to one environment), the console can search across both Test and Live environments, and can filter by request ID, status, and path.Using request logs
Request logs are useful for:- Debugging — Find a failed request by its
x-request-idand see the error code and timing. - Monitoring — Track API usage patterns and error rates.
- Support — When contacting support, include the
request_idso the team can find the exact request.
Logs never fail the response
The request log is written in afinally block after the response is sent. If the log write fails (for example, a database issue), the API response is not affected — the customer still gets their quote or simulation. The log failure is recorded in server-side error output.
For the full request log schema, see the API reference.