What is OBit?
Understand the 0Bit platform, the product surfaces, and how developers should choose the right integration path.
0Bit is crypto-financial infrastructure for applications that need payment flows, liquidity access, stablecoin/fiat movement, merchant payment objects, routing review, and protocol-activity visibility. The platform is not one monolithic API. It is a portfolio of product surfaces that share platform conventions: organization accounts, partner credentials, environment modes, idempotent writes, signed webhooks, and reconciliation records.
The docs are organized by product ownership. Each product owns a different business workflow and a different public contract. That matters because a hosted ramp session, a headless liquidity quote, a merchant payment intent, and a routed execution review are not interchangeable records.
Product map
| Product | What it owns | Default reader |
|---|---|---|
| 0Gate | Hosted sessions, buy/sell/swap flows, embed/redirect/widget UX, ramp status, payment/payout events, and partner-safe settlement tracking. | Developers adding a hosted crypto payment or ramp flow to an app. |
| 0Pools | Entitled pool discovery, quote preview, firm quote execution, trade status, partner-visible balances, and liquidity-network concepts. | Approved partners building headless liquidity or swap workflows. |
| 0Base | Merchant payment objects: checkouts, payment intents, links, invoices, settlement reports, ledgers, payout settings, and webhook records where enabled. | Merchants and platforms that need crypto checkout/payment-object infrastructure. |
| 0Link | Routing review, multi-venue abstraction, fallback boundaries, quote context, route confirmation, and settlement-handling concepts. | Teams reviewing connected or routed execution workflows without exposing source internals. |
| 0Pools Scan | Explorer-style visibility for transactions, swaps, pool movement, mint/burn events, assets, statuses, and analytics. | Operators, developers, and support teams investigating public-safe activity. |
Why the platform exists
Before infrastructure like 0Bit, every application that wanted crypto money movement had to assemble its own stack: payment methods, KYC handoff, asset support tables, quote logic, liquidity providers, route failover, status pages, support tooling, settlement exports, reconciliation jobs, and webhook retry behavior. That creates fragmented user experiences and fragile developer contracts.
0Bit moves those responsibilities into product surfaces with stable public objects:
| Before | With 0Bit |
|---|---|
| A partner copied provider-specific payment states into its own UX. | The partner integrates a stable 0Bit object such as a session, quote, payment intent, trade, route, or event. |
| Liquidity changes became partner-facing product changes. | 0Pools and 0Link keep source and route details behind product-safe records. |
| Browser callbacks drove fulfillment. | Signed webhooks and trusted reads drive backend state. |
| Every app wrote bespoke reconciliation tools. | 0Bit ids, event ids, ledgers, reports, and Scan visibility give teams a common investigation chain. |
| Product availability was assumed from examples. | Availability is checked by environment, entitlement, product config, asset, country, currency, and allowed domain. |
How developers should think about it
Your organization owns credentials and product entitlements. Product APIs use those credentials plus product-specific checks. A valid key is not the same thing as product availability. A valid sk_* can still receive a 403 if the organization is not entitled, if KYC/KYB is incomplete, if a pool is not allowed, if an origin is not allowlisted, or if an asset/country/currency path is disabled.
Shared conventions
| Convention | Meaning |
|---|---|
/v1 APIs | Product APIs expose versioned routes. Breaking changes should move to a new major version. |
pk_* | Publishable key. Browser-safe where the product allows it, mainly for hosted/embed bootstrap. |
sk_* | Secret key. Server-only. Used for privileged creates, reads, and executions. |
whsec_* | Webhook signing secret. Server-only. Used to verify inbound webhook signatures. |
Idempotency-Key | Server-generated retry key for state-changing writes. |
| Signed webhooks | Durable asynchronous state. Verify raw body and dedupe by event id. |
| Scan records | Visibility and investigation context, not a replacement for webhook verification. |
Choosing correctly
| If your user needs to... | Use |
|---|---|
| Buy crypto, sell crypto, swap, or complete hosted payment UX | 0Gate |
| Receive a native/headless quote and execute against approved liquidity | 0Pools |
| Pay a merchant checkout, payment link, invoice, or payment intent | 0Base |
| Review route selection, quote availability, fallback, or settlement handling | 0Link |
| Search activity, support a customer, or inspect protocol status | 0Pools Scan |
Public boundary
Public docs should explain what developers can safely build, not internal operations. Do not model your integration around provider names, treasury balances, reserve thresholds, market-maker terms, worker names, bank details, unsupported launch claims, or private route logic. The stable public model is product object plus status plus event plus reconciliation.