Check what your agent is about to claim.

Quickstart

Send a policy and a reply. You get a verdict and the exact spans that broke a rule.

# 1. check one reply
curl https://api.curbi.io/v1/check \
  -H 'Content-Type: application/json' \
  -d '{
  "policy": {
    "prices":  [{"item": "Pro", "amounts": [49, 490]}],
    "forbid":  [{"id": "refund-promise", "phrases": ["full refund"]}],
    "actions": {"refunded": "billing.refund"}
  },
  "reply": "I have refunded you, and Pro is $39/mo."
}'

// 2. response
{
  "object": "check",
  "pass": false,
  "findings": [
    { "rule": "action:unrecorded", "text": "I have refunded",
      "why": "Says \"I have refunded\" but no billing.refund effect is DONE in the record." },
    { "rule": "price:mismatch", "text": "$39", "why": "Pro is $49 or $490, not $39." }
  ]
}

Use the findings in your app

const r = await fetch('https://api.curbi.io/v1/check', {
  method: 'POST', headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ policy, reply: draft, record: { effects } })
}).then(r => r.json());
if (!r.pass) return escalateToHuman(draft, r.findings); // never send a failing reply
await send(draft);

How it works

Curbi compares the reply with two inputs you supply:

The public checker does not query providers or a hosted ledger. Supply the records your system chose to rely on, and review their source separately.

Canonical public origin: https://api.curbi.io, with /v1/check and /mcp. Existing https://curbi.io/api/ routes remain compatible; account and project routes stay on the website origin.

Contract & versions

The API is described by an OpenAPI 3.1 contract and a JSON Schema for policies. The release tests compare the published schemas with the runtime on a labeled corpus. The contract test runner also exercises this page’s request examples against the Worker.

Batch

Batch mode: submit multiple cases per request against one policy (see Limits & errors for the current cap). The batch passes only if every case passes.

curl https://api.curbi.io/v1/check \
  -H 'Content-Type: application/json' \
  -d '{
  "version": "2026-11-01",
  "policy": { "prices": [{"item": "Pro", "amounts": [49, 490]}] },
  "cases": [
    {"id": "a", "reply": "Pro is $49 a month."},
    {"id": "b", "reply": "Pro is ＄59 a month."}
  ]
}'

// response (abridged)
{
  "object": "check.batch", "version": "2026-11-01", "pass": false,
  "results": [
    { "id": "a", "pass": true, "findings": [] },
    { "id": "b", "pass": false, "findings": [
      { "rule": "price:mismatch", "span": [7, 10], "text": "＄59" } ] }
  ]
}

Render text and why as text, never as HTML: they can contain whatever the reply or policy contained.

POST /v1/check

Body is JSON, either one reply or a batch. GET on the same path returns version and limits.

Policy object

Phrases are never interpreted as regular expressions, so a policy can't slow the checker down.

Records

Trust boundary: records are caller-supplied and unverified. The API does not query providers or the Curbi ledger, authenticate events, or bind an event to a customer. recordTrust is caller_supplied_unverified. A passing result means no configured rule matched; it is not permission to send, spend or execute.

{
  "effects": [{ "operation": "calendar.book", "status": "DONE" }],
  "facts":   [{ "near": "booked", "kind": "time", "value": "9am" }]
}

Only DONE counts. PENDING, FAILED and UNKNOWN do not, because an agent must not tell a customer something happened when the system doesn't know that it did. Fact kinds: time, date, money. The first value of that kind within 80 characters after near must equal value.

Signed receipts

Effects you list yourself are labelled caller_supplied_unverified. The API can authenticate an Ed25519-signed operation statement from a configured key. Production action signing is not connected yet. A signature authenticates the signer’s statement; it does not independently verify a booking, amount, time or customer.

{
  "verify": "required",                 // claims need a signed receipt
  "reply": "I've booked you for Monday.",
  "record": {
    "subject": "conv_9",               // the conversation the receipts belong to
    "receipts": ["curbi1.eyJ2IjoxLC…"]
  }
}

Responses report recordTrust: curbi_signed, mixed or caller_supplied_unverified, plus a per-receipt list of rejections. Public keys are at /.well-known/curbi-receipt-keys.json, so anyone can verify a receipt offline. Check key validity and revocation under your trust policy. Production signing is off. The separate offline verifier checks bundles using explicitly trusted keys.

Scope: receipts sign operation, subject and effect key—not action arguments or booking details. Caller-provided facts remain unverified and produce mixed trust. The same receipt can be checked again until expiry; this API has no cross-request replay ledger and grants no authority.

Findings

Each finding has rule, span (character offsets), text and why.

Limits & errors

POST requests have a best-effort burst guard of 30 per IP per minute within one Worker isolate. This is not a global quota; requests may reach different isolates. HTTP 429 includes Retry-After: 60. Managed access has separate per-key and shared-customer usage ceilings.

Body ≤ 64 KB · reply ≤ 4,000 chars · 50 cases · 50 prices · 50 forbid rules × 20 phrases · 40 actions · 100 effects · 20 facts.

Public access: no API key or SLA. The checker does not store submitted replies. Responses are Cache-Control: no-store. The interface may change before v1 is final; changes will be listed below.

Platform catalog

GET /api/platform returns Curbi's public ontology (People, Work, Tools, Agents, Evidence…) as read-only JSON with an ETag. It is a guide, not a permission source.

Changelog