0Bit Documentation

API reference

Explore 0Bit API groups, authentication, request and response boundaries, idempotency, errors, webhooks, status lifecycles, and production notes.

The 0Bit API reference is organized by product surface and availability boundary. The published partner API pages currently cover 0Gate and 0Pools. 0Base and 0Link product documentation remains available, but their endpoint-level partner API pages are not published until those products are ready for partner API access.

Use this page as the product-safe overview. Operation pages and product guides can go deeper, but they should keep the same rules: keep secrets server-side, use idempotency keys for writes, verify webhooks, branch on machine-readable error fields, and avoid unsupported live availability claims.

OpenAPI-backed references

The 0Gate and 0Pools API pages are curated from their OpenAPI contracts and reviewed for public partner wording. Use the raw YAML specs for code generation, and use the authored pages for lifecycle guidance, examples, safety boundaries, and production rules.

What this page covers

  • API group boundaries by product.
  • Authentication and key placement.
  • Documented endpoint groups.
  • Request/response and idempotency conventions.
  • Error, retry, webhook, pagination, and production readiness behavior.
  • Which areas are public, partner-gated, review-only, or account-gated.

API group overview

AreaPurposeCommon operations
0Gate sessionsCreate, retrieve, list, and cancel hosted payment sessions.POST /gate_sessions, GET /gate_sessions/{id}, POST /gate_sessions/{id}/cancel.
0Gate embedBootstrap hosted browser experiences.POST /embed/bootstrap using publishable key and session client_secret.
0Gate capabilitiesDiscover configured countries, fiat currencies, assets, payment methods, payout methods, and eligibility where approved.GET /capabilities/*.
0Gate transactionsList and retrieve partner transaction records.GET /transactions, GET /transactions/{refid}.
0Gate webhooksInspect delivery logs, replay dead-lettered deliveries, and send test events where supported.Webhook delivery list, replay, and test sample operations.
0PoolsQuote and execute partner-scoped liquidity workflows.GET /pools, POST /pools/{id}/quote, POST /pools/{id}/transact, trade/quote reads.
0Pools ScanQuery normalized protocol activity and explorer records.Transactions, swaps, pool activity, mint/burn, assets, status, analytics, indexer views.

0Base and 0Link API pages are not published yet

0Base and 0Link product guides remain available under Products, but their partner API reference pages are intentionally hidden until those surfaces are ready for partner API access. Do not build against unpublished endpoint paths.

OpenAPI contract sources

ArtifactSource
0Gate OpenAPI titleGate API
0Gate OpenAPI version2026-05-25
0Gate YAML/openapi/gate-v1.yaml
0Gate curated pages0Gate API
0Pools OpenAPI title0Pools Partner API
0Pools OpenAPI version2026-05-25
0Pools YAML/openapi/pools-v1.yaml
0Pools curated pages0Pools API

The website copy should stay aligned with the current OpenAPI files. If an OpenAPI contract changes, update the YAML, update the curated endpoint pages, review SDK examples, and update the changelog before release.

Authentication model

CredentialWhere it livesWhat it is for
sk_test_* / sk_live_*Server onlyCreates or reads privileged resources, creates sessions, locks quotes, executes writes, reads protected records.
pk_test_* / pk_live_*Browser/mobile only where allowedBrowser-safe bootstrap or discovery calls, such as 0Gate embed bootstrap or product-specific publishable-key discovery.
client_secretBrowser-safe but session-scopedBinds a hosted experience to a single server-created session.
whsec_*Server onlyVerifies signed webhook deliveries.
Idempotency keyServer-generated per logical writeCollapses duplicate retries into one logical operation.

Never expose secret keys

sk_* keys belong on your server. Browser code can receive only product-approved browser-safe values such as pk_* and session-scoped client secrets.

Request and response conventions

ConventionGuidance
Decimal valuesSend and store amounts as strings where the operation expects decimal strings.
Fake examplesDocumentation examples use fake ids, keys, URLs, users, and order references.
IdempotencySend Idempotency-Key on state-changing writes and persist it with your order/workflow record.
Request idsLog response request ids and event ids for support and reconciliation.
Undocumented fieldsDo not depend on fields that are not in the operation/schema reference.
EnvironmentUse sandbox/test keys and fake data until live access is approved.

0Gate session example

curl -X POST https://gate-api-sandbox.0bit.app/v1/gate_sessions \
  -H "Authorization: Bearer sk_test_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 00000000-0000-4000-8000-000000000123" \
  -d '{
    "amount": "100.00",
    "currency": "EUR",
    "return_url": "https://partner.example/complete",
    "target_token": "USDT",
    "metadata": { "order_id": "order_test_123" }
  }'

The creation response includes a client_secret for the browser. Retrieval responses should not expose that raw secret again.

0Pools quote and transact lifecycle

0Pools endpoint-level documentation is partner-sensitive. The public-safe lifecycle is:

StepAPI shapeNotes
DiscoverGET /poolsReturns partner-entitled pools and availability.
QuotePOST /pools/{id}/quoteLocks a short-lived single-use quote; unavailable routes should not create stale locks.
ExecutePOST /pools/{id}/transactExecutes against a quote; repeated execution should be idempotent for the quote/logical transaction.
RetrieveQuote/trade read endpointsUse for support and reconciliation.

Errors, retries, and idempotency

Published Gate and Pools specs use a common error envelope with fields such as type, code, message, request_id, doc_url, and statusCode. Integrations should branch on machine-readable fields, log request ids, and avoid parsing free-form messages as business logic.

ConditionRetry?Notes
Network timeout or connection errorYes, with bounded backoff and jitterUse idempotency keys for writes.
429Yes, respecting retry guidance where providedAdd jitter and alert on sustained rate limiting.
5xxYes, with bounded backoffPreserve request ids for support.
Validation errorNo, unless request changesFix the request body or user input.
Auth or permission errorNo, unless credentials/access changesRotate or request access; do not loop.
State conflictUsually noRetrieve current state and branch intentionally.

Webhook lifecycle

Webhook handlers should verify signatures, reject stale timestamps, dedupe by event id, persist state transitions, and return 2xx only after durable handling. Browser callbacks are useful UX signals, not settlement truth.

Production readiness

  • Product access approved.
  • API credentials issued and stored server-side.
  • Publishable keys isolated to client configuration.
  • Allowed origins configured.
  • Webhook endpoint deployed over HTTPS.
  • Raw-body signature verification implemented.
  • Idempotency implemented for writes.
  • Duplicate event handling implemented.
  • Bounded retry strategy implemented.
  • Sandbox tests completed.
  • Reconciliation, monitoring, alerting, support, security, and compliance reviews completed.

On this page