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_…).

Method	Path	What it does
POST	Path`/v1/pay/requests`	What it doesMint a signed invoice. Body `{payee_address, amount_usd, chain_id, memo?, expires_in_secs?}`.
GET	Path`/v1/pay/requests/{id}`	What it doesFetch a payment request and its status.
POST	Path`/v1/pay/requests/{id}/settle`	What it doesVerify the on-chain transfer and return a signed settlement receipt. Body `{tx_hash}`.

Limits and honesty

Non-custodial. Sable never holds the funds. It signs the invoice and verifies the settlement transfer; it does not move money.
The transfer must match. Settlement verifies a USDT transfer from the payer's linked wallet to the payee address for at least the invoiced amount. A short, mis-addressed, or unlinked-sender transfer does not settle.
EVM chains in v1. The rail settles USDT on EVM chains. Pass the chain_id you intend to settle on.
This rail attests a payment between two parties. To top up your own Sable compute balance instead, see paying with USDT.