Portal
Documentation: all sections

Payment rail

The payment rail lets an agent invoice and settle a payment between two parties without Sable ever touching the money. You mint a signed invoice, the payer sends USDT directly to the payee on-chain, and Sable verifies that transfer and returns a signed settlement receipt. Both artifacts are EIP-191 signed and verify through the same public /v1/receipts/verify as every other Sable signature.

This is deliberately different from funding your Sable balance. Funding is a deposit to the Sable treasury that credits your prepaid compute. The payment rail is peer-to-peer: the money moves between a payer and a payee, Sable is only the facilitator that attests it happened.

Non-custodial, precisely

Sable never holds the funds. There is no escrow account and no treasury in this flow. The payer pays the payee's address directly on-chain. Sable's role is to sign the invoice up front and to verify the on-chain transfer afterward, so either party (or a third party) can prove what was owed and what was paid. EVM chains in v1.

Quickstart

The payment rail is key-authed: send a sk-sable_ API key as Authorization: Bearer.

# 1. Mint a signed invoice for a payee address
curl https://api.buildsable.com/v1/pay/requests \
-H "authorization: Bearer $SABLE_API_KEY" \
-H 'content-type: application/json' \
-d '{
  "payee_address": "0xPayee…",
  "amount_usd": 25,
  "chain_id": 1,
  "memo": "invoice-4192"
}'

# 2. The payer sends USDT directly to payee_address on-chain, then you settle:
curl https://api.buildsable.com/v1/pay/requests/$REQUEST_ID/settle \
-H "authorization: Bearer $SABLE_API_KEY" \
-H 'content-type: application/json' \
-d '{"tx_hash": "0xabc…"}'

The create call returns the invoice plus its signature. request is the signed payload string:

{
  "id": "pay_3a9c…",
  "payee_address": "0xPayee…",
  "amount_usd": 25,
  "chain_id": 1,
  "memo": "invoice-4192",
  "status": "open",
  "request": "eyJ2Ijox…",
  "signature": "0x7d1e…",
  "signer": "0xA1b2…9F"
}

Settling verifies the on-chain USDT transfer, from the payer's linked wallet to the payee, for at least the invoiced amount, and returns a signed settlement receipt:

{
  "settlement": "eyJ0eXBlIjoic2V0dGxlbWVudC…",
  "signature": "0x9b44…",
  "signer": "0xA1b2…9F",
  "payload": {
    "request_id": "pay_3a9c…",
    "tx_hash": "0xabc…",
    "amount_micro_usd": 25000000,
    "settled_at": "2026-09-03T12:00:00Z"
  }
}

Verifying either artifact

Both the invoice and the settlement are ordinary Sable signatures, so anyone can check them with no Sable account by posting the payload string and its signature to the public verify endpoint:

curl https://api.buildsable.com/v1/receipts/verify \
-H 'content-type: application/json' \
-d '{"receipt": "<request or settlement string>", "signature": "0x…"}'

A {valid: true, recovered_address, payload} response recovers the Sable signer, so the counterparty can confirm the invoice and the settlement both came from Sable and describe the same payment.

Endpoints

All key-authed (Authorization: Bearer sk-sable_…).

MethodPathWhat it does
POST/v1/pay/requestsMint a signed invoice. Body {payee_address, amount_usd, chain_id, memo?, expires_in_secs?}.
GET/v1/pay/requests/{id}Fetch a payment request and its status.
POST/v1/pay/requests/{id}/settleVerify the on-chain transfer and return a signed settlement receipt. Body {tx_hash}.

Limits and honesty