Authorize spend over REST or MCP.

Every spend goes through a single POST /api/agents/authorize call. Send a delegate token and an amount; the policy engine returns a decision.

curl -X POST "https://api.example.com/api/agents/authorize" \
  -H "Authorization: Bearer $GC_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "token": "<delegate_token>",
    "amount": 12.50,
    "merchant_name": "Anthropic",
    "merchant_category": "saas"
  }'

Production hosts and request paths are shown in your workspace after you sign in.

Authenticate with a bearer token in the Authorization header:

• •gc_live_ / gc_test_ — API keys minted on the Developer page. Best for server-side integrations.
• •oat_ — short-lived OAuth access tokens issued through the “Connect with Greene” flow for remote MCP clients.

Keys are shown once and stored hashed. Rotate or revoke them any time from the Developer page and Settings.

An approval returns the transaction id and remaining budget:

{
  "authorized": true,
  "transaction_id": "a1b2c3d4-…",
  "remaining_balance": 487.50,
  "message": "Transaction approved"
}

Other outcomes carry a status code and a machine-readable reason your agent can branch on:

// 403 — denied by policy
{ "authorized": false, "code": "over_single_max", "reason": "Amount exceeds per-transaction limit" }

// 202 — held for human approval
{ "authorized": false, "status": "pending_approval", "pending_approval_id": "…", "transaction_id": "…" }

// 402 — out of credits
{ "error": "Payment Required", "link": "/dashboard/top-up" }

// 401 — bad API key or token   ·   429 — rate limited

Greene Comply ships a native MCP server (packages/greene-mcp) that exposes an authorize_spend tool and a health_check tool. Point your MCP host at it with your base URL and API key:

{
  "mcpServers": {
    "greene-comply": {
      "command": "node",
      "args": ["packages/greene-mcp/dist/index.js"],
      "env": {
        "GREENE_BASE_URL": "https://api.example.com",
        "GREENE_API_KEY": "gc_live_…"
      }
    }
  }
}

For hosted clients like ChatGPT, use the remote MCP endpoint at /api/mcp and connect over OAuth — no key handling required. Manage connected sessions from Settings.

Authorization is the source of truth; settlement is a swappable rail that runs after an approve. When a spend target is configured for the circle_usdc rail, Greene Comply moves USDC over Circle Developer-Controlled Wallets and pins the on-chain transaction hash to the decision. We never take custody — Circle is the regulated custodian, and today settlement runs on Base Sepolia testnet only.

// On an approved spend whose target uses the "circle_usdc" rail,
// Greene Comply settles asynchronously over Circle and records the result.
// Settlement never blocks the authorize response — poll the transaction
// (or watch Activity) for the on-chain state.

// outbound_spend_executions row, once settled:
{
  "transaction_id": "a1b2c3d4-…",
  "rail":           "circle_usdc",
  "status":         "succeeded",
  "external_ref":   "0xabc123…",        // on-chain tx hash
  "chain":          "BASE-SEPOLIA"
}

Settlement is best-effort and asynchronous: a failed or skipped transfer never changes the authorize outcome or your audit record. Mainnet is gated on counsel review.

The forthcoming open-source @greene-comply/x402 middleware lets you paywall any endpoint for paying agents — it returns an HTTP 402, settles a sub-cent USDC payment over Circle, and can verify a Greene attestation before letting the request through. See the x402 toll-booth overview for the quickstart.