Introduction

The Caibo Global API lets your platform send stablecoin payouts programmatically — screened, verified, and settled on-chain.

The Caibo Global API is a REST API for outbound payouts. You create a payout, we screen the destination, move the funds on-chain, and notify you when it settles. It is built for platforms that need to pay out to many recipients reliably — marketplaces, payroll and contractor platforms, remittance apps, and treasury operations.

Every request is authenticated with an API key, scoped to your organization. You integrate once against a stable, versioned contract and get idempotent writes, cursor pagination, consistent error objects, and signed webhooks.

What you can do today

The current API surface (v1) covers the full payout lifecycle:

  • Payouts — create, retrieve, list, and cancel stablecoin payouts.
  • Balances — read your organization's balance per asset.
  • Rates — read conversion rates for a currency pair.
  • Catalog — read supported countries and payment methods.
  • Webhooks — register signed endpoints and subscribe to payout events.
  • API keys — create, list, and revoke keys for your organization.
  • Organization & KYB — onboard your business and submit verification.

The payout rail

Payouts settle over the stablecoin rail: USDC and USDT on a set of supported networks. When you create a payout, Caibo signs and broadcasts the transfer from treasury to your recipient's address. The supported networks are:

  • EVM: Polygon, Arbitrum, Optimism, Base, BSC, Ethereum (USDC, USDT)
  • Tron (USDT)
  • Solana (USDC, USDT)
There is no fiat payout rail yet. The API only sends stablecoin payouts. Anything not listed in this documentation does not exist — these guides describe only what the API actually does today.

Base URL & conventions

All requests go to the versioned base URL over HTTPS:

bash
https://api.caiboglobal.com/v1

A few conventions hold across every endpoint:

  • Money is strings. Amounts are decimal strings like "100.50", never floats — this avoids binary rounding.
  • Timestamps are ISO 8601 UTC, e.g. 2026-07-23T14:03:00Z.
  • IDs are prefixed so they are self-describing: org_, po_ (payout), whe_ (webhook endpoint), kyb_.
  • Writes are idempotent via the Idempotency-Key header.
  • Lists are cursor-paginated and return { data, has_more, next_cursor }.

Test and live

Every organization has two modes, distinguished by the API key prefix. ck_test_ keys run in a full sandbox that never touches the blockchain but returns realistic states and webhooks. ck_live_ keys move real funds and require a verified business (KYB). You can build and test your entire integration in sandbox before requesting live access.

How this fits together

A typical integration looks like this:

  1. Create your organization and get a ck_test_ key.
  2. Build against the sandbox: create payouts, handle webhooks, verify signatures.
  3. Submit KYB to unlock live mode.
  4. Create a ck_live_ key, register a production webhook endpoint, and start sending real payouts.

Next steps