Skip to main content

Decision response headers

Every guarded response carries three headers. Log all three on every request — success or failure.

HeaderPresent onMeaning
x-request-idEvery responseUUID identifying this HTTP request
x-decision-idEvery guarded response (allow, block, or guardrail_unavailable)UUID identifying the guardrail decision
x-policy-versionEvery guarded response with a decisionIdentifier of the policy version that produced the decision

Absence of x-decision-id on a non-200 response tells you the request didn't reach the guardrails path — it's a platform-level fault, not a policy outcome.

Sending your own request-id

You can supply your own x-request-id on the request. The platform uses it verbatim if it's a UUID or short opaque string (≤128 chars) and echoes it back on the response; otherwise it generates a fresh one.

Recommendation: generate a UUID per outbound request in your client and pass it in. Your client-side logs and the platform's server-side logs will share a common correlation key.