Quickstart

Start with something you can check yourself, right now, with no account and nothing to install. Fetch the published sample receipt and the published checker, and run it — Python 3.8+ standard library only.

curl -sSO https://www.bluefoxedge.ai/specimen-receipt.json
curl -sSO https://api.bluefoxedge.ai/verify_receipt.py
python3 verify_receipt.py specimen-receipt.json

the check passes: every signed field recomputed from the file's own bytes

Exit 0 means it passed; any failure is one sentence and a non-zero exit, never a stack trace. You just verified a BlueFox receipt without trusting BlueFox for the answer. No Python on the machine? The same check in JavaScript is verify_receipt.js, one file and no dependencies. The full walkthrough — including how to pin the key set and run it with the network unplugged — is Verify a Receipt.

Two sample receipts are published, and they do different jobs. specimen-receipt.json above is the signature-and-anatomy exhibit; it was minted before the transparency log existed, so it is not in the log and an inclusion query for it returns 404, correctly. To prove a receipt is in the log, use the in-log worked example, specimen-inlog.json (receipt 01M04TRZ3A08D0ABDKN6NDBV6V, minted 2026-08-16) — three more lines, still no account:

curl -sSO https://www.bluefoxedge.ai/specimen-inlog.json
curl -sSO https://api.bluefoxedge.ai/verify_inclusion.py
curl -sS "https://api.bluefoxedge.ai/v1/transparency/inclusion?log_id=reliance/v1&chain_self=sha256:05d2133e06c5e642cdd5d558853e3d7d7a543a9a36b141e2e403076173e029da" | python3 verify_inclusion.py

Exit 0 places the entry at leaf index 991 of a tree that has only grown since, verified against the log key the checker fetches from the published key set. The walk from checkpoint to consistency proof to inclusion is Walk the Log.

Sign up with your email to get a free API key — no credit card required. The free tier gives you 100 API calls per UTC day, which includes up to 10 claim-verification calls per UTC day, plus 1 signed mint per UTC day. The 10 claim-verification calls/day inner meter applies only to the REST /verify endpoints, never to MCP tool calls. Your key is shown once on the signup page; save it somewhere safe.

One of the things you can put on the record is a claim about the world. Send a brand and one or more claims; the answer comes back with a verdict, its evidence, and a receipt minted for you. depth picks the path: fast is the rule engine on cached data, standard is LLM verification, auto starts fast and escalates when uncertain.

curl -s -X POST https://api.bluefoxedge.ai/v1/brand/check \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "brand": "nike",
    "claims": ["Nike offers free returns for Nike Members"],
    "depth": "auto"
  }'

Every success response is a {data, meta} envelope. Each result carries a verdict in the domain's own vocabulary (e.g. accurate, inaccurate, neutral, unverifiable), a confidence tier, evidence, and a receipt_id.

{
  "data": {
    "brand": "nike",
    "results": [{
      "claim": "Nike offers free returns for Nike Members",
      "verdict": "accurate",
      "confidence": 0.95,
      "confidence_tier": "high",
      "evidence": "Nike's return policy allows free returns within 60 days of purchase for Nike Members.",
      "method": "llm_verify",
      "receipt_id": "01KXFM36XG1J15AQYFBPX0D3SK"
    }],
    "depth_used": "auto"
  },
  "meta": { "request_id": "...", "timestamp": "..." }
}

Every verification already mints one — that's the receipt_id above. You can also mint a receipt for any digest you present: the response records that your digest was presented at that time, signed, with no content judgment (the verdict is the act-word notarized).

We can evidence what was recorded while it was happening. We cannot evidence a month you were not recording.

DIGEST=$(printf 'hello, receipts' | openssl dgst -sha256 | awk '{print $NF}')
curl -s -X POST https://api.bluefoxedge.ai/v1/notarize/hash \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"hash\": \"$DIGEST\"}"

{
  "data": {
    "receipt": { "...": "the complete signed envelope — see Receipt Anatomy" },
    "receipt_id": "01KXFM36XG1J15AQYFBPX0D3SK",
    "replayed": false,
    "verify": {
      "jwks_url": "https://api.bluefoxedge.ai/.well-known/jwks.json",
      "instructions_pointer": "https://api.bluefoxedge.ai/docs"
    },
    "latency_ms": 12
  },
  "meta": { "request_id": "...", "timestamp": "..." }
}

Normative — the one pointer never to follow. The verify.jwks_url above is a convenience pointer. A verifier MUST NOT follow the jwks_url carried inside a receipt: it sits outside the signature, so a forged receipt can aim it at the forger's own key set. Pin the key set out of band at https://api.bluefoxedge.ai/.well-known/jwks.json.

This endpoint also works with no key at all: send the request without credentials and the HTTP 402 response is the quote — pay it via x402 and retry. Your signed-mint entitlement on the free tier is stated under Rate Limits below. Check any receipt yourself at Verify a Receipt.