OVERVIEW

Programmable cards, your rules.

APPEN gives a spender — an AI agent (the sharpest case), a script, or a person — a card it can use but never see: governed by a rulebook you write, evaluated server-side on every purchase decision, with the reason attached to every approve and every decline. One primitive serves both ends: a weekend pizza bot and a production fleet of infrastructure agents use the same API, the same rules, the same dashboard.

The mental model in one exchange: your agent asks (POST /intents with a merchant, category, and amount) and the engine answers approved, denied, pending_approval, or partial, with a per-rule trace of why.

the whole product in one request
POST /intents
{ "merchant": "Tony's Pizzeria", "category": "food", "amount_cents": 1250 }

→ 200
{
  "status": "approved",
  "decision_reason": "ok",
  "rule_results": { "decision": "approve", "results": [
    { "kind": "merchant_lock",   "status": "pass", "detail": "matches allow-list entry 'pizzeria'" },
    { "kind": "amount_ceiling",  "status": "pass", "detail": "$12.50 within $30.00 max" },
    { "kind": "spend_cap",       "status": "pass", "detail": "$12.50 of $200.00 day cap" },
    { "kind": "cooldown",        "status": "pass", "detail": "84s since last purchase (≥2s)" }
  ]}
}

What's in the box

  • A rule engine with 14 rule kinds — merchant, amount, cadence, time, and human-gate, the fourteenth being webhook_check (bring your own rule) — and budget envelopes with rollover. Written as JSON against a published spec, with no code for you to host. Rules reference →
  • Dual-principal auth — you hold a JWT; each agent holds its own revocable ak_live_ key, scoped per tool. An agent can declare purchases; it cannot approve them, mint keys, or see card numbers. Auth →
  • Cards as handles — the agent gets crd_… and a last-four. The PAN never appears in an API response, never in the data model the agent can reach.
  • A human approval queue — rules can park a purchase for your sign-off; approving re-runs every other rule. Intents →
  • Native agent surfaces — REST, an MCP server for Claude and friends, and a terminal mission control. MCP → CLI →

WHERE THIS RUNS TODAY

The rule engine decides every declared intent today — live in the API, the MCP server, and the demo. Enforcement on real card swipes begins at our BIN connection with our issuing partner, when the same pre-authorized, user-directed policies execute inside the network authorization step. Card issuance opens by invite once our issuing-partner sandbox is live.

Start here

The quickstart takes you from zero to a live rule-engine decision in about five minutes of curl, including the step where you break a rule on purpose and read the explained decline.