Developers

Initiate a payout with one request

Kick off a payout the way that fits your stack: an x402 payment request straight from your agent, or a plain REST API call from your backend. Either way, you send a customer ID and an amount — Zippr does the rest.

Request early API access Compare x402 vs. API

# x402 POST — pay a human from an agent
POST https://api.zippr.io/x402/payouts

X-Payment-Protocol: x402
Authorization: Bearer sk_live_...
Content-Type: application/json

{
  "customerId": "cus_8fk20a9",
  "amount": 125.00
}

curl -X POST https://api.zippr.io/x402/payouts \
  -H "X-Payment-Protocol: x402" \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "customerId": "cus_8fk20a9", "amount": 125.00 }'

const res = await fetch("https://api.zippr.io/x402/payouts", {
  method: "POST",
  headers: {
    "X-Payment-Protocol": "x402",
    "Authorization": `Bearer ${process.env.ZIPPR_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    customerId: "cus_8fk20a9",
    amount: 125.00
  })
});

The request

Two parameters. That's the whole payload.

You don't tell Zippr how to pay someone — the recipient already decided that. You only say who and how much.

🆔

`customerId`

The Zippr identifier for the person you're paying. It's tied to their verified identity and their chosen payout method.

💵

`amount`

How much to send, in your account's settlement currency. Zippr converts to the recipient's currency at payout time.

Two ways in

x402 or REST — pick what fits

⚡

x402 payment request

x402 turns an HTTP request into a payment instruction. Your agent hits the endpoint, the payment is authorized inline, and the payout settles — no separate billing flow, no invoices. Ideal for autonomous, pay-as-you-go agent workflows.

Payment travels with the request
Great for machine-to-human settlement
Same customerId + amount payload

🔌

REST API call

A conventional authenticated POST from your backend. Use it when a human or a service — not the agent itself — is the one triggering the payout, or when you want to batch and reconcile on your side.

Bearer-token auth
Webhooks for status updates
Idempotency keys for safe retries

What happens next

After you send the request

Zippr validates

The customer ID is checked, the amount is authorized, and the request is acknowledged synchronously. The funds are retrieved.

Funds held in non-custodial escrow

The amount is locked in a non-custodial escrow until the recipient claims the funds. Zippr never takes custody of funds.

You get a voucher code

Zippr generates a voucher code and unique redeem link. Send the voucher code and/or link to the recipient. The recipient can now claim the funds.

Want to build on Zippr?

The API and x402 endpoints are in private development. Get on the list for early access and docs.

Request early access