Docs Start

Quickstart

LiveUpdated

View as Markdown

Agents. Written for people who build agents, the hosts they run in, and the people and companies the agents pay for.

One MCP server, installed in the host your agent already runs in. The sandbox key is self-serve; a person appears only when you want a live key.

1. Get a key

No account needed. One call creates a sandbox organization with an agent, a developer key, the sample policy and Ream & Rule (reamandrule.com) as an allowed payee. Five per IP per hour.

curl -X POST https://api.enruta.ai/v0/sandbox/keys

201 {
  "organization": { "id": "org_01M2R3V8H4Y6K9S1D5F7A2C4E6", "principal": "sandbox-k7m2p9qx" },
  "agent_id": "agt_sandbox_4f9q2z",
  "agent_key": "enruta_agt_…",
  "developer_key": "enruta_dev_…",
  "claim_url": "https://app.enruta.ai/claim/…",
  "expires_at": "2026-09-20T09:00:00Z"
}

The keys work at once against the sandbox rail. Open claim_url when a person wants the organization in the console; unclaimed sandboxes expire after seven days.

2. Install in your host

/plugin marketplace add enruta-ai/claude-plugin
/plugin install enruta@enruta

The plugin bundles the MCP server, an enruta-pay skill that teaches the agent when to request a payment or a refund, and a hook that blocks tool calls to known checkout endpoints unless a mandate is present.

Agents also read /.well-known/skills/index.json and the agent guide: which tools need a person’s confirmation and the rules the skill enforces.

3. Request a payment

From the agent’s side, a payment is one tool call. Everything Enruta needs to decide is in the arguments; everything it decides comes back in the result.

request_payment({
  payee: { name: "Ream & Rule", domain: "reamandrule.com" },
  amount: { value: "24.98", currency: "USD" },
  purpose: "2 packs of ballpoint pens for the office",
  checkout: { protocol: "ucp", reference: "chk_01M2511XQ4N7B8T2R6H9K3W5MD" },
  evidence: [{ type: "checkout", ref: "https://reamandrule.com/checkout-sessions/chk_01M2511XQ4N7B8T2R6H9K3W5MD", digest: "sha256:4b1c…" }],
  intent: { text: "Order two packs of pens, keep it under $30", slots: { quantity: 2, max_total: "30.00" } }
})

// → { decision: { result: "allow", … }, mandate: { id: "mnd_01M2512M8FQ7ZK4T1V9W3N6BXC", credential: { … } },
//     risk: { action: "authorized", score: 0 }, record_id: "rec_01M25129GZMJXTNQ47TMZRDGHN" }

On allow, the result carries the mandate and the credential the payee’s payment handler accepts. On clarify, the policy needs something the request did not say: the result carries questions; ask the person and send the answers with answer_clarification. On step_up, the agent waits for a person; the approval link opens in the console or on the approver’s phone. On deny, the reasons are in the result and in the record. On observe, the policy is in shadow mode: the mandate is issued and shadow_result says what an enforcing policy would have done.

4. Verify the record

npx enruta-verify rec_01M25129GZMJXTNQ47TMZRDGHN.json
# enruta-verify 0.3.0
# rec_01M25129GZMJXTNQ47TMZRDGHN  org_halvern  #12  kind payment
# canonical form   ok       RFC 8785, schema enruta/0.2
# seal             ok       sha256:7e2a…c41d
# chain            ok       prev rec_01M24YCQ55XZGQ5495CMR0DQ78
# attestations     ok       1 time-stamp valid, daily root 2026-09-10 checkpoint ok
# keys             ok       4 referenced, snapshot 2026-09
# strength         ok       protocol=third_party_signed, execution=customer_attested, receipt=third_party_signed, policy=customer_attested
#   ✓ DigiCert at seal 2026-09-10T17:42:08.000Z
# PASS

The verifier needs nothing from Enruta: no network, no account. Change one byte of the record and it fails. Reversals, settlements and reconciliation lines verify the same way, and the verifier prints how each one chains to the payment.

5. What follows the payment

  • A refund or a cancellation is `request_reversal`; the answer is a decision too.
  • get_settlement says where the money is and when it becomes final (settlement).
  • get_reconciliation returns the line that joins the mandate, the rail and the merchant’s order.
  • list_disputes shows the dispute packets generated from your records and their outcomes.
  • get_economics shows the money split: who paid, who received and who earned.
  • verify_merchant checks a merchant before the next payment (trust model).