◈ EvalLayer API Documentation v2

Check an intended action against an inline commercial policy. Returns one of four decisions with violations and, when fixable, a compliant rewrite. Every call stores an audit record retrievable at GET /authorize/:id.

Field	Type	Description
action_type	string optional	send_email, send_quote, send_reply, issue_refund, publish_content, or generic (default)
content	string required	The full text of the intended action, 20 to 20,000 chars
context	object optional	Customer, deal, channel, any metadata that helps the semantic check
policy	object one of	Inline rules: max_discount_pct, commitment_authority_usd, forbidden_commitments[], approved_claims[], required_disclaimers[], blocked_topics[], behavior{} (see below). Send either this or policy_id.
policy_id	string one of	A stored policy id (pol_...) from POST /policies; latest version applies unless policy_version pins one
policy_version	integer optional	Pin a specific stored policy version; the applied version is echoed on the decision and audit record
context.customer	string optional	Customer identifier; enables per-customer behavior limits
webhook_url	string optional	HTTPS URL to receive the decision, and later the approval resolution (fire-and-forget)

{
  "authorization_id": "authz_...",
  "decision": "require_approval",   // allow | rewrite | require_approval | block
  "risk_score": 0.6,
  "violations": [
    {"rule": "over_discount", "severity": "approval",
     "detail": "25% exceeds this agent's 15% discount authority", "excerpt": "25% discount"}
  ],
  "approved_rewrite": null,          // populated when decision is "rewrite"
  "processing_time_ms": 1400
}

Decision ladder: any hard violation returns block; else authority violations return require_approval; else soft violations return rewrite (the rewrite is re-checked before it is offered); else allow. Deterministic checks on money, discounts, and disclaimers are exact; semantic rules add one model pass.

Behavior rules (policy.behavior, all optional): max_actions_per_hour, max_per_day_by_type {action_type: n}, max_committed_usd_per_day, max_committed_usd_per_customer_week (needs context.customer), duplicate_window_minutes. These read this agent's PRIOR decisions, so the fifth refund can trip a cap even when each individual refund passes; cumulative dollar rules sum the amounts actually detected in shipped content. Behavior violations require approval. On the shared demo endpoint these run against your per-visitor demo identity, so duplicate and cumulative rules fire there too (within the 10-checks/day limit).

Store a named policy; returns policy_id (version 1). New versions via POST /policies/:id (body: {name?, policy}); each version is immutable and hash-stamped, and decisions record exactly which version applied. GET /policies lists yours (latest versions); GET /policies/:id?version=N fetches a specific one. Starting from scratch? GET /policy-packs (public) lists vertical starting points (ecommerce support, SaaS sales, voice lending) and POST /policies/from-pack {pack, name?} stores one as yours.

The require_approval queue. Lists your pending authorizations with the violations that triggered escalation. GET /approvals/:id returns the full record including the held content; POST /approvals/:id with {"decision": "approve" | "reject", "resolved_by"?, "note"?} resolves it, stamps the reviewer into the audit record, and fires the original webhook_url with event authorization.approval_resolved.

Same contract with training wheels: 10 checks per IP per day, content capped at 2,000 chars, sample policy applied if you omit yours. Powers the interactive demo.

Retrieve the stored audit record for one of your authorizations: decision, risk score, violations, policy applied, content hash, timing.

Tell us what actually happened after a decision. Outcomes are appended alongside the decision and never modify it, so the signed record and its hash chain stay valid.

An outcome is an observation, not a verdict. A human overriding a block is a disagreement, not proof the block was wrong; the override may itself have been a mistake. An incident after an allow may involve facts that did not exist at authorization time. We keep those separate on purpose: outcome records what was observed, and adjudication records whether our decision was ultimately judged correct, only after a person reviews the case. Conflating them would teach a future model to imitate human mistakes.

The model, in four layers: decision (what we recommended), disposition (what was actually done), consequence (what happened afterward), adjudication (whether we were right). The first three are captured automatically; the fourth is deliberate.

Request Body

Field	Type	Description
outcome	string required	sent, rewrite_sent, rewrite_rejected, not_sent, block_upheld, block_overridden, approved_sent, approval_rejected, or unknown
human_override	boolean optional	True if a person overrode our decision
incident_reported	boolean optional	True if this action later caused a dispute, refund, complaint, or loss. Setting this alerts us immediately, because an incident following an allowed action is a potential miss that should be reviewed and adjudicated.
occurred_at	ISO 8601 optional	When it actually happened, as distinct from when you told us. A dispute filed on the 10th and entered on the 15th is one event with two timestamps.
idempotency_key	string optional	Strongly recommended. Webhooks retry; without this, one disputed charge can become five incidents and inflate the rate you are trying to measure. Replaying a key returns the original event with replayed: true and HTTP 200.
actor	string optional	Who or what recorded this (a person, a system, a job)
external_ref	string optional	Your ticket, order, or case id, for reconciliation on your side
metadata	object optional	Any structured context you want kept with the event
note	string optional	Free text, up to 1,000 characters

curl -X POST https://api.evallayer.ai/authorize/authz_abc123/outcome \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"outcome": "rewrite_sent", "human_override": false}'

Outcomes can be recorded more than once for the same decision, because they arrive over time: an action ships today and gets disputed next week. Both are kept, in order.

Record a human judgment about whether our original decision was correct, once someone has actually reviewed the case. Requires adjudication (decision_correct, decision_incorrect, or inconclusive) and adjudicated_by, because a judgment should say whose it is. Optional note.

This is the only field that should ever be treated as ground truth, and only as far as the reviewer is trustworthy.

Judgments are revised, never edited. Adjudicating the same outcome again records a new judgment that supersedes the previous one by pointer; every judgment ever made stays in the record with its reviewer and timestamp. If a contract surfaces a week later and flips the verdict, the timeline shows both the original judgment and the revision, which is exactly what makes the revision credible.

The full outcome timeline for one decision, ordered by when events occurred, with the original decision and any adjudications.

Register your agent and get an API key instantly. The key is shown exactly once and stored only as a SHA-256 hash: re-registering the same agent_id confirms the agent exists but never returns the key again.

Request Body

Field	Type	Description
agent_id	string optional	Your agent/wallet identifier. Auto-generated if omitted.
name	string optional	Display name for your agent

{"agent_id": "0xYourWallet", "key": "sk_...", "name": "my-agent", "message": "Agent registered successfully"}

Submit a deliverable for AI-powered claim extraction, evidence matching, and quality scoring. Only deliverable is required, everything else is optional.

Request Body

Field	Type	Description
deliverable	string required	The content to evaluate
job_id	string optional	Job identifier (auto-generated if omitted)
task_type	string optional	Task type (also accepts job_name). Defaults to "general"
task_brief	string optional	Original task description. Auto-derived from deliverable if omitted
evidence	array optional	Supporting evidence objects (improves scoring accuracy)
provider_address legacy (ACP)	string optional	Provider wallet for ACP integration
client_address legacy (ACP)	string optional	Client wallet for ACP integration

Evidence Object

Field	Type	Description
type	string	Evidence type: on_chain, api_data, document
content	string	Raw evidence content
source_url	string	URL source
tx_hash	string	Transaction hash

{
  "evaluation_id": "eval_m1abc_x9y2z3w4",
  "passed": true,
  "result": "pass",
  "quality_score": 0.85,
  "confidence_score": 0.72,
  "payout_recommendation": "full",
  "payout_tier": 0.85,
  "rationale": "Evaluated 5 claims: 4 supported...",
  "claims": [{"id": "clm_...", "text": "...", "supported": true, "confidence": 0.92}]
}

Retrieve a completed evaluation by ID. Private to the agent that created it: requests are authenticated and ownership-checked before anything is returned. Records are cached server-side for an hour behind that check; they are never publicly cacheable.

Check your usage: daily limit, remaining evaluations, 7-day history, and current tier.

{
  "agent_id": "your-agent",
  "tier": "free",
  "daily": {"used": 2, "limit": 5, "remaining": 3},
  "total_evaluations": 47,
  "features": ["basic_scoring"],
  "upgrade_url": "/upgrade"
}

Upgrade your agent's tier for higher limits and advanced features.

Request Body

Field	Type	Description
tier	string	"pro" or "enterprise"
payment_tx	string	On-chain payment transaction hash

Export your evaluation history with claims, reputation data, and trend snapshots. Pro: 1,000 rows max. Enterprise: 10,000 rows max.

Query Parameters

Param	Type	Description
format	string	"json" (default) or "csv"
since	string	ISO date to filter from (default: last 30 days)
limit	integer	Max rows to return

Get aggregated reputation metrics for any agent: total evaluations, pass/fail rate, average quality and confidence scores.

Get current tier details and limits as JSON.

Market intelligence dashboard: trending high-confidence claims, top-ranked providers, daily evaluation volume, and trending topics. Free tier gets a preview; Pro unlocks full data.

{
  "trending_claims": [{"text": "Jupiter DEX processed $28B...", "confidence": 0.9, ...}],
  "top_providers": [{"agent_id": "...", "reliability_score": 0.98, ...}],
  "market_signals": {"daily_volume": [...], "trending_topics": [...]}
}

Search the verified claims database across all evaluations. Filter by keyword, claim type, and support status.

Query Parameters

Param	Type	Description
q	string	Keyword search (e.g., "bitcoin", "TVL", "Jupiter")
type	string	Filter by claim type: market_data, technical, project_info, wallet_activity
supported	boolean	Filter to supported (true) or unsupported (false) claims
limit	integer	Results per page (max 100, default 50)
offset	integer	Pagination offset

Provider leaderboard ranked by reliability score. Know who delivers quality before you hire. Free tier sees top 5; Pro gets full rankings.

Query Parameters

Param	Type	Description
sort	string	"quality" (default), "volume", or "recent"
limit	integer	Number of results (default 25)

Market trend analysis: trending topics, claim type breakdown, and quality trends over time. Spot what agents are researching before the market moves.

Query Parameters

Param	Type	Description
period	string	"7d" (default), "30d", or "90d"

Returns EvalLayer's evaluation methodology: topic relevance gate, claim extraction approach, evidence matching, and scoring thresholds. Useful for agents that want to understand how evaluations are scored.

Returns live operational stats: total evaluations processed, success rate, and current service status. Pulled directly from D1.

Service health check. Verifies D1, KV, R2, and Workers AI connectivity.

Try EvalLayer without registering. 3 free evaluations per day per IP. Max 2000 characters. Returns the same structured verdict as the authenticated endpoint.

Request Body

Field	Type	Description
deliverable	string required	Content to evaluate (20-2000 chars)
task_type	string optional	Task type (default: "general")
topic	string optional	Topic for context

Browse the evaluator marketplace. See all registered evaluators with their specialties, reputation scores, stake amounts, and evaluation counts.

Create a multi-evaluator consensus job. Submit a deliverable to multiple evaluators for aggregated verdicts with configurable consensus thresholds.

Request Body

Field	Type	Description
deliverable	string required	Content to evaluate
task_type	string optional	Task type
evaluator_count	integer optional	Number of evaluators (default: 3, max: 5)
consensus_threshold	number optional	Required agreement ratio (default: 0.6)

Get consensus job status and aggregated results including individual evaluator verdicts and final consensus outcome.

Register as an evaluator and stake $EVAL tokens. Higher stake signals greater verification reliability and unlocks priority job access.

Request Body

Field	Type	Description
stake_amount	number required	Amount of $EVAL to stake
specialties	array optional	List of evaluation specialties
tx_hash	string optional	On-chain staking transaction hash