Veritake API Docs
Deterministic decisions with a full audit trail.
Veritake gives agents one safe decision plus the evidence behind it. Use the endpoints below to request a decision, retrieve the audit timeline, and generate an explanation for human review or agent reasoning.
Quickstart
Send a decision request, then fetch the audit trail with the decision id.
POST /api/decision
curl -X POST https://api.veritake.ai/api/decision \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $VERITAKE_API_KEY" \
-d '{
"user": "agent_7",
"query": "book 2 nights in Vienna",
"context": { "budget": 320 }
}'GET /api/audit/{decision_id}
curl https://api.veritake.ai/api/audit/dec_8f1c4b2a \ -H "Authorization: Bearer $VERITAKE_API_KEY"
Authorization is optional in sandbox mode. Production keys enforce request limits and auditing.
Decision endpoint
POST /api/decision
Returns a single deterministic decision with the selected action, score, and policy version.
Request body
{
"user": "agent_7",
"query": "book 2 nights in Vienna",
"context": {
"budget": 320,
"currency": "EUR",
"loyalty_tier": "gold"
}
}- user — unique agent or customer identifier.
- query — task or intent to evaluate.
- context — structured inputs used for scoring (any JSON object).
Response
{
"decision_id": "dec_8f1c4b2a",
"action": "ALLOW",
"score": 6.9,
"policy_version": "policy_0.1",
"hash": "0a1b2c3d4e5f...",
"created_at": "2026-02-09T08:44:23.000Z",
"selected_hotel": {
"id": "hotel_82",
"name": "Hotel Belvedere",
"city": "Vienna"
},
"source": "primary",
"fallback_reason": null
}Store the decision_id to fetch the audit trail and explanation later.
Parameter notes
- decision_id — stable id for joins; keep it with your booking.
- action — one of ALLOW or DENY. No partials.
- score — 0.0 to 10.0; deterministic for the same inputs.
- policy_version — version of the policy used to evaluate the input.
- hash — deterministic fingerprint of the input payload.
Tricky fields
- created_at — ISO timestamp of the decision emission.
- selected_hotel — optional; present when a choice is made.
- source — primary when inputs are valid, fallback if inputs were missing.
- fallback_reason — null when valid, otherwise describes the missing field.
Audit endpoint
GET /api/audit/{decision_id}
Returns the immutable sequence of events that produced the decision, including policy evaluations and emitted actions.
Response
{
"decision_id": "dec_8f1c4b2a",
"policy_version": "policy_0.1",
"generated_at": "2026-02-09T08:44:24.000Z",
"source": "stored",
"events": [
{
"t": "2026-02-09T08:44:23.120Z",
"type": "INPUT_RECEIVED",
"details": {
"user": "agent_7",
"query": "book 2 nights in Vienna",
"source": "primary"
}
},
{
"t": "2026-02-09T08:44:23.560Z",
"type": "POLICY_EVALUATED",
"details": {
"policy_version": "policy_0.1",
"score": 6.9,
"source": "primary"
}
},
{
"t": "2026-02-09T08:44:23.890Z",
"type": "DECISION_EMITTED",
"details": {
"action": "ALLOW",
"decision_id": "dec_8f1c4b2a",
"selected_hotel_id": "hotel_82",
"source": "primary"
}
}
]
}Event anatomy
- t — ISO timestamp for ordering; use as evidence in explanations.
- type — INPUT_RECEIVED, POLICY_EVALUATED, DECISION_EMITTED.
- details — data captured at that step (user, score, action, etc.).
Tricky fields
- generated_at — when the audit record was assembled.
- source — stored if we recorded it, generated_fallback if missing.
- fallback_reason — appears when no stored audit record exists.
Explanation
Build a human-readable narrative
Use the audit timeline to generate explanations for human review or agent reasoning. The explanation should map to the audit events so every statement is verifiable.
Recommended structure
- Inputs — summarize the user, query, and key context used in scoring.
- Policy — mention the policy version and any thresholds applied.
- Outcome — describe the emitted decision and any selected option.
- Evidence — link each claim to a specific audit event timestamp.
Example explanation
Explanations should be deterministic and derived directly from the audit events.