Getting access

0Pools access is an onboarding process, not a sign-up button. A headless liquidity API gives a partner the ability to build its own money UX, so 0Bit must approve the account, product, compliance model, pool list, limits, funding, and support path before live traffic.

Access lifecycle

Product fit review

0Pools is appropriate when:

• The partner must own the native customer UX.
• The partner has an approved compliance and support model.
• The integration is server-to-server.
• The use case needs direct quote/transact/status control.
• 0Gate's hosted widget or redirect is not the right product surface.

0Gate is usually better when the user can complete the ramp inside 0Bit-hosted screens.

Required setup

Deny-closed behavior

Every important gate fails closed:

This is intentional. A denied request should not move money.

Smoke test plan

Before launch, prove each path:

1. GET /v1/pools returns only allowed pools.
2. Capabilities match the approved side/network/limit set.
3. Indicative quote returns price or safe unavailable state.
4. Firm quote returns expiry and quote id.
5. Duplicate transact does not create a duplicate trade.
6. Status polling reaches a terminal test state.
7. Webhook handler verifies signature and dedupes event id.
8. Balance/ledger view reconciles with your order record.

What to send support

For access issues, include partner id or organization name, environment, request id, pool id, endpoint, and timestamp. Do not send secret keys, webhook secrets, bank credentials, or raw customer identity data.

Access approval matrix

Onboarding flow with evidence

Each step should produce evidence: config, test ids, screenshots if useful, and reconciliation rows. Live approval should not be based only on "the quote endpoint returned 200 once."

Before and after access

First production order checklist

Before sending meaningful volume, run one controlled production order and confirm:

• Live key mode is correct.
• Pool discovery returns only expected pools.
• Capabilities match approved side/network/limits.
• Firm quote has expected expiry and quote-bound destination.
• Transact is idempotent.
• Status can be retrieved after execution.
• Webhook arrives or polling fallback works.
• Ledger/reconciliation row closes with quote and trade ids.
• Support can find the order from the partner reference.

Access packet for production review

Access review should produce a clear packet that engineering, compliance, finance, and support can all inspect.

Environment readiness matrix

Approval decision record

{
  "partner_id": "partner_01H",
  "product": "wallet_buy_stablecoin",
  "requested_pools": ["EUR-USDT"],
  "approved_environment": "production",
  "approved_sides": ["buy"],
  "funding_model": "prefunded_balance",
  "webhook_verified": true,
  "support_escalation_ready": true
}

Implementation depth

This page is about moving from account review to usable sandbox or production access. For developers, the durable boundary is simple: your product should depend on access state, enabled pools, keys, funding model, and webhook readiness; it should not depend on internal provisioning scripts, approval queues, and operator tooling. That boundary is what lets 0Pools improve liquidity operations without forcing every partner to rebuild product code.

Product scenario

A partner wants to launch a native stablecoin buy flow. Before coding production paths, the team confirms account approval, key mode, pool entitlement, funding requirements, webhook endpoint, and support contacts.

Before and after in practice

System flow

Records to keep

A useful implementation stores these records before adding optional analytics. Analytics can be rebuilt from durable state; missing ids usually cannot be reconstructed after a customer-impacting failure.

Example product record

{
  "product_area": "getting-access",
  "partner_reference": "partner_order_123",
  "pool_id": "EUR-USDT",
  "quote_id": "pq_test_123",
  "transact_id": "pt_test_456",
  "status": "reserved",
  "request_id": "req_01HZY0POOLS",
  "reconciliation_state": "open"
}

This record is intentionally partner-facing. It references 0Pools objects and your own product ids, but it does not include private liquidity routes, treasury balances, raw provider payloads, or customer secrets.

Failure modes and recovery

Use-case patterns

Developer checklist

• Read runtime discovery and capabilities before rendering enabled actions.
• Create firm quotes only when the user is ready to accept the terms.
• Execute from your server with an idempotency key.
• Treat webhooks and status reads as the source of truth for settlement state.
• Reconcile by durable ids first, then by amount and timestamp.
• Do not branch product behavior on provider names, route names, reserve balances, or treasury assumptions.