Changelog

0Pools API pages are for approved headless partners. They cover the partner-visible quote, transact, status, trade, and balance lifecycle only.

The 0Pools partner API is versioned by a single date, carried in the spec's version field. This page records what each version exposes and how changes are made. The current version is 2026-05-25.

Early access — 2026-05-25

The first partner-facing version of the 0Pools API. It provides the full on-ramp quote-to-settlement lifecycle plus partner-scoped reads. For field-level contracts, follow the linked endpoint pages — this entry is a summary, not a re-doc.

Discovery and capabilities

• List entitled pools — GET /pools. Publishable-key discovery of the pools this partner is entitled to; pool ids are pair-shaped (for example EUR-USDT).
• Pool capabilities — GET /pools/{id}/capabilities. Per-pool supported networks, sides, tier, draw fee, spread cap, and order limits. Read this instead of hard-coding values.

Quote lifecycle

• Create a quote — POST /pools/{id}/quote. Firm (executable, quoteId + ~15s expiresAt) or indicative (price-only, no quoteId) quotes. Fail-soft: an unquotable pool returns HTTP 200 with available: false and an unavailableReason, never a quoteId.
• Retrieve a quote — GET /pools/quotes/{quoteId}. Read a quote's current state (active, consumed, expired, rejected).
• Reject a quote — POST /pools/quotes/{quoteId}/reject. Release an unused firm quote. Not idempotent — a second reject conflicts.

Transact and settlement

• Execute against a quote — POST /pools/{id}/transact. Idempotent: an Idempotency-Key header is required and execution is also idempotent on the quoteId.
• Get transaction status — GET /pools/transactions/{quoteId}. The status poll advances settlement (idempotently). The terminal returned status surfaces here.
• On-ramp EVM delivery — purchased crypto is delivered to a locked EVM address captured on the quote; the customer needs only a single EVM wallet address.

Reconciliation reads

• List trades — GET /pools/trades. Cursor-paginated trade history with side, status, and time filters.
• Retrieve a trade — GET /pools/trades/{transactId}. A pure read that does not advance settlement.

Balance and funding

• Read balance — GET /pools/{id}/balance. Partner-visible availability, tier, allowed pools, and balance.
• Get funding — GET /pools/funding. Funding instructions for a partner balance.
• Read ledger — GET /pools/ledger. Cursor-paginated balance entries (payin_credit, buy_debit, buy_refund).

Cross-cutting behavior

• Unified error envelope — every error carries { type, code, message, request_id, doc_url, statusCode } and an X-Request-Id response header. Branch on code/type/statusCode, never on the free-form message. See Errors.
• Denial codes — 403 responses carry a machine-readable code: pools_not_enabled, pool_access_suspended, kyc_not_approved, pool_not_allowed, or key_mode_mismatch. Cross-tenant access is 404, never 403.
• Cursor pagination — list reads return nextCursor / hasMore; page by passing the last id as cursor.
• The returned status — a settled trade whose downstream payout or delivery could not complete is automatically and idempotently refunded to your partner balance. It surfaces via the status poll and the ledger only — there is no returned webhook.
• Webhooks — three terminal events (pool.transaction.settled, pool.transaction.failed, pool.transaction.released), signed with a Gate-Signature header, deduped on eventId, delivered at least once with backoff and a dead-letter store. See 0Pools webhooks.

Versioning

The API version is the date in the spec's version field (currently 2026-05-25). The model below tells you what to expect from future changes and how to build defensively.

Additive vs breaking

How changes are announced

• Additive changes are reflected in these reference pages as the surface evolves; the linked endpoint pages remain the field-level source of truth.
• Breaking changes are coordinated with approved partners during account review before they take effect — they are not made silently.
• This changelog records the partner-facing surface per version.

Stability posture

The 0Pools partner API is early access: per-partner, operator-provisioned, not generally available, and not self-serve. The surface may change before general availability. Limits, economics, corridors, assets, and rails are confirmed during account review rather than fixed here — read them at runtime from pool capabilities.

Public boundary

This reference covers partner-visible discovery, quote, transact, status, trade, and balance behavior. Liquidity operations, routing internals, provider details, reserve logic, and runbooks are outside the public API contract.

Related pages