Policy endpoints

The /policy/* API surface that adds project quotas, policy evaluation, streaming metadata, and audit events.

The /policy/* surface requires a Policy Gateway plan. The /v1/* compat surface is available to every account.

abliteration.ai exposes two parallel API surfaces. Both accept the same request bodies — the difference is governance.

Surface	Endpoints	Behavior
Compat	/v1/chat/completions, /v1/messages, /v1/responses	Transparent proxy. Optional inline policy. No project/quota gating.
Policy	/policy/chat/completions, /policy/messages, /policy/responses	Resolves the caller to a project, evaluates the project’s linked policy, enforces project quotas, injects policy metadata into responses and streams, emits an policy event.

When to use which

• Use /v1/* for a drop-in experience with the OpenAI or Anthropic SDK — optionally with an inline policy for one-off evaluation.
• Use /policy/* when you want persistent project-level quotas, a console-managed policy, policy events, and streaming policy metadata.

Headers

/policy/* endpoints read three optional headers:

Header	Purpose
X-Policy-Project	Project ID the request belongs to. Overrides the project bound to the API key. Required when using JWT auth.
X-Policy-Target	Free-form label (any string) used for shadow/canary grouping and for filtering policy events. Not an enum — pick whatever makes sense (e.g. "support-bot", "mobile-app").
X-Policy-User	Subject string for per-user quotas and audit attribution.

Example:

curl https://api.abliteration.ai/policy/chat/completions \
  -H "Authorization: Bearer $ABLIT_KEY" \
  -H "X-Policy-Project: proj_support_bot" \
  -H "X-Policy-Target: support-bot" \
  -H "X-Policy-User: user_42" \
  -H "Content-Type: application/json" \
  -d '{"model": "abliterated-model", "messages": [{"role":"user","content":"Hello"}]}'

The same three values can also be sent as top-level request body fields (headers take precedence):

Header	Body alias(es)
X-Policy-Project	policy_project_id
X-Policy-Target	policy_target
X-Policy-User	policy_user or policy_user_id

You can also pick a policy inline with policy_id (or policyId) at the top level.

Inline policy (no project needed)

Instead of relying on a linked project policy, you can pass a policy object directly in the request body. Useful for one-off evaluation or testing:

{
  "model": "abliterated-model",
  "messages": [{"role": "user", "content": "..."}],
  "policy": {
    "policy_id": "byop-gateway",
    "rules": {
      "allowlist": ["account support"],
      "denylist": ["illegal instructions"],
      "flagged_categories": ["self-harm/intent"],
      "redact_pii": true
    }
  }
}

Response metadata

/policy/* responses include extra fields alongside the upstream body:

{
  "id": "chatcmpl-policy-...",
  "object": "chat.completion",
  "model": "abliterated-model",
  "choices": [ ... ],
  "usage": { "prompt_tokens": 18, "completion_tokens": 12, "total_tokens": 30 },
  "remaining_credits": 48,
  "estimated_credits_used": 1,
  "estimated_cost_usd": 0.00015,
  "policy": {
    "policy_id": "support-bot",
    "decision": "allow",
    "effective_decision": "allow",
    "reason_code": "ALLOW",
    "rollout_mode": "enforced",
    "enforced": true,
    "triggered_categories": [],
    "allowlist_hits": ["refund policy"],
    "denylist_hits": [],
    "policy_target": "support-bot"
  }
}

Streaming responses carry the same policy object on every SSE frame — see streaming policy metadata.

Related

• Policy Gateway overview — what policies do
• Onboarding — create a project and link a policy
• Connectors — event shape, decision fields, and SIEM destinations