How to verify a booking made by an AI agent

Short answer: a confirmation email is a claim about a booking, not proof of one. Verifying means reconciling that claim against supplier-authoritative evidence - a live supplier record or a supplier-issued transactional document - and treating anything weaker as unknown, not confirmed. BookingTruth is a free-sandbox API and MCP server that does exactly this: documents in, cited verdicts out.

Why confirmation emails are claims, not proof

Every booking document was written by a system with something to sell. A supplier notification that says "we are processing your trip" describes intent, not state. An OTA itinerary proves the OTA recorded a request; it says nothing about whether the airline or hotel holds the reservation. Even an aggregate UI message like "All Reservations Booked" is generated by the page, not the supplier ledger. Agents that repeat these claims to users are quoting marketing copy as fact - and the user finds out at the airport desk or the hotel lobby.

The evidence ladder

Not all booking evidence is equal. BookingTruth ranks every document it parses on a six-rung ladder, strongest first:

• Tier 6 - supplier record. An authenticated, live lookup against the supplier's own system (API or account). The gold standard.
• Tier 5 - supplier-issued transactional document. An eTicket receipt with a ticket number, an invoice with a record locator issued by the supplier itself. Supplier-authoritative.
• Tier 3 - OTA confirmation. An Expedia-style itinerary. A real record, but of the OTA's books, not the supplier's.
• Tier 2 - supplier notification prose. "We are processing your reservation." Intent, not state.
• Tier 1 - aggregate UI message. "All Reservations Booked." Proves nothing on its own.
• Tier 0 - unverified extraction. Anything an LLM or heuristic merely thinks it saw. Never authoritative - including BookingTruth's own candidate parsing.

The rule: CONFIRMED is returned only on tier 5-6 evidence. Anything below returns an honest UNKNOWN with the indicated state - what the evidence hints at - rather than a confident guess.

What verification returns

Each check produces a verdict; CONFIRMED verdicts carry a citable proof packet:

{
  "booking_id": "chk_031a072fc0a0868e",
  "supplier": "united",
  "state": "confirmed",
  "indicated_state": null,
  "evidence_tier": 5,
  "authoritative": true,
  "explanation": "Decided by highest-class status evidence...",
  "proof_url": "https://api.bookingtruth.com/v1/bookings/chk_031a072fc0a0868e/proof"
}

Verify a booking in one call

REST, free sandbox (any Bearer key starting with sb_):

curl -s https://api.bookingtruth.com/v1/check   -H "Authorization: Bearer sb_demo"   -H "Content-Type: application/json"   -d '{"documents":[{"filename":"confirm.eml","content":"...email text..."}]}'

MCP (streamable HTTP): https://api.bookingtruth.com/mcp, tool booking_check. Demo fixtures to test with: /v1/demo/fixtures. Machine-readable: llms.txt, OpenAPI, A2A agent card.

When UNKNOWN is the right answer

If the strongest evidence is an OTA itinerary or a "processing" email, the honest answer is UNKNOWN with the indicated state - not a confident "confirmed" that invents certainty. An agent that passes an UNKNOWN to its user ("the documents say processing; the supplier record is not in evidence yet") is more useful than one that guesses, because the user can act on it: call the airline, re-check in an hour, or fetch the actual receipt.

BookingTruth · Pilot program