Quattrino coinQuattrino

For developers

Build agents that can spend — safely.

One REST API and one MCP server, both sitting behind the same rules engine your users control. You get clean tools; their humans keep the veto. Nothing here can bypass a policy, a budget or an approval.

REST in 5 minutes

Create an agent, grab its scoped key, and make your first policy-checked spend with two curl commands.

Follow the quickstart →

MCP for assistants

Claude and other MCP clients connect to our streamable-HTTP server and get spending as native tools.

See the endpoints →

Break things safely

The sandbox has named failure scenarios — declines, timeouts, over-budget — so you can test every path.

Browse scenarios →

Quick start

  1. Sign up and create an agent.
  2. Create a sandbox wallet and attach it to the agent.
  3. Draft and activate a spending policy.
  4. Issue a scoped API credential (shown once).
  5. Request a transaction — the policy engine decides.

SDKs (single file, zero magic)

Thin, honest wrappers over the REST agent API — preflight, transactions, quotes, negotiation, marketplace purchases and receipts. Drop one file into your project.

Python

Only dependency: requests.

Download quattrino.py
from quattrino import Quattrino
q = Quattrino("https://quattrino.io", "qtrn_sk_key_...")
pre = q.preflight(amount_minor=1999, merchant="openai")
tx = q.request_transaction(amount_minor=1999, merchant="openai")

TypeScript

Fetch-based, zero dependencies.

Download quattrino.ts
import { Quattrino } from "./quattrino";
const q = new Quattrino("https://quattrino.io", "qtrn_sk_key_...");
const pre = await q.preflight({ amount_minor: 1999, merchant: "openai" });

Also public: the open service directory (GET https://quattrino.io/api/v1/public/directory) and agent-credential verification (POST https://quattrino.io/api/v1/public/identity/verify).

Authentication

Agents authenticate with an X-API-Key header. Every economic POST requires an Idempotency-Key.

curl -X POST https://quattrino.io/api/v1/agent/transactions \
  -H "X-API-Key: qtrn_sk_key_..." \
  -H "Idempotency-Key: order-1029" \
  -H "Content-Type: application/json" \
  -d '{
    "amount_minor": 2000,
    "currency": "USD",
    "merchant": "Company Search API",
    "category": "api",
    "transaction_type": "external_purchase",
    "purpose": "Ownership lookup"
  }'

Retrying with the same key returns the original transaction — it never charges twice.

Endpoints

  • GET /agent/whoami
  • GET /agent/wallet
  • POST /agent/transactions
  • GET /agent/transactions
  • GET /agent/transactions/{id}
  • POST /agent/transactions/{id}/cancel
  • GET /agent/approvals
  • GET /agent/approvals/{id} ← poll after next_action=await_approval
  • MCP /api/mcp/ ← official MCP server (streamable HTTP, same credentials)
  • GET /agent/quote?amount_minor=2000

MCP tools in Delivery 2 are thin adapters over exactly these operations — they cannot bypass the policy engine, budgets, risk controls, ledger or rate limits.

Errors

{
  "error": {
    "code": "above_autonomous_limit",
    "message": "Amount exceeds this agent's autonomous limit, so approval is required",
    "request_id": "req_...",
    "details": { "auto_limit_minor": 20000, "amount_minor": 29500 },
    "retryable": false
  }
}

Transaction states (26)

Needs approvalAPPROVEDCANCELLEDCompletedCREATEDDECLINEDDISPUTEDPartly refundedPAYMENT AUTHORIZEDPayment failedPAYMENT PENDINGBlocked by policyPOLICY CHECKPROVIDER OUTCOME UNKNOWNProvider unavailableREFUNDEDREFUND PENDINGREVERSEDBlocked by riskROUTINGSERVICE COMPLETESERVICE FAILEDSERVICE PENDINGService timed outSETTLEMENT PENDINGVALIDATING

Sandbox scenarios

  • success — Payment authorizes and settles normally
  • decline — Provider declines the payment
  • insufficient_funds — Funding source reports insufficient funds
  • provider_timeout — Provider does not respond in time
  • provider_timeout_charged — Provider times out AFTER it actually authorized (the dangerous ambiguous case)
  • provider_unavailable — Provider is temporarily unavailable
  • duplicate_webhook — Provider sends the settlement webhook twice
  • refund — Payment succeeds then is fully refunded
  • partial_refund — Payment succeeds then is partially refunded
  • dispute — Payment succeeds then is disputed
  • service_failure — Payment succeeds but the purchased service fails
  • funding_unavailable — No funding source is available for this rail
  • credential_creation — A single-use payment credential is issued

Autonomy levels

  • 0 — Disabled: No spending permitted
  • 1 — Approve every transaction: Every transaction requires human approval
  • 2 — Threshold-based: Auto-approve below the autonomous limit
  • 3 — Budget autonomy: Operate freely within policy budgets
  • 4 — Mission autonomy: Authority tied to an active mission and expiry

Agent scopes

wallet.read · transactions.read · transactions.request · transactions.cancel · approvals.read · marketplace.read · marketplace.purchase

Start free — no card required