BOB Gateway

API Overview

Complete reference for the BOB Gateway API - cross-chain Bitcoin transactions and integrations

Welcome

The BOB Gateway API enables seamless cross-chain interactions for Bitcoin-powered applications. Build bridges, swaps, and DeFi integrations with Bitcoin liquidity.

OpenAPI Specification

View the complete API specification

What's new in V4

This reference targets /v4. See the Migration Guide to upgrade an existing integration.

  • Source-chain refunds — refundAddress is optional when requesting a quote but required before create-order for every route. Use a Bitcoin address for onramps and an address on the source chain for offramps and token swaps. A missing address returns MISSING_REFUND_ADDRESS.
  • No ownerAddress parameter — V4 quote requests use sender, recipient, and refundAddress; remove ownerAddress from your requests.
  • Optional slippage — omit slippage from GET /v4/get-quote to let Gateway choose a suitable tolerance for the route. The quote reports the resolved value in basis points. Explicit values remain supported; V3 still requires the parameter. See the recommendation example.
  • Onramp submission only — PATCH /v4/register-tx accepts { "onramp": { "order_id": "...", "bitcoin_tx_hex": "..." } }. Gateway validates, screens, and broadcasts the signed Bitcoin transaction. A txid alone is not accepted. Offramp and token-swap source transactions are indexed from the chain without registration.
  • Shared response models — V4 keeps V3's tagged EVM/Tron/Solana transaction data, paginated orders, settlement transfers, and optional USD values. Model names such as GatewayCreateOrderV3 and GatewayTokenAmountV2 still appear in the V4 specification.

Authentication

API keys are optional — the API is reachable without authentication. A key unlocks:

  • Analytics dashboard — your orders, volume, and affiliate earnings
  • Higher rate limits than keyless usage

Partner Onboarding

Get an API key and go live — full flow and contact details

When you have a key, send it as a Bearer token on every V4 request:

Authorization: Bearer <api-key>

Keys are exactly 32 characters long. The SDK takes the same key via new GatewaySDK({ apiKey }) and sets the header for you.

How It Works

Use this flow for Bitcoin↔chain swaps and cross-chain token swaps. Transaction submission depends on the source chain:

Get Available Routes

Call GET /v4/get-routes to fetch all supported routes, chains, and tokens. This helps you understand what swaps are available and present options to your users.

GET /v4/get-routes

Returns information about supported chains, tokens, bridges, and fee structures.

Get a Quote

Call GET /v4/get-quote with your swap parameters (amount, source/destination chains, tokens, etc.). The API returns a discriminated quote (onramp, offramp, or tokenSwap) with routing information, fees, and expected outputs.

GET /v4/get-quote?srcChain=bitcoin&dstChain=bob&amount=10000000...

If you don't know what slippage to set, omit slippage and read the recommendation from the returned variant's slippage field. To set your own tolerance, supply basis points, for example slippage=300 for 3%. Review the resolved tolerance before passing the quote unchanged to create-order.

Addresses and token identifiers are 0x… on EVM chains and Base58 on Tron/Solana. Pass affiliates=0xAddr1:50,0xAddr2:25 to route a basis-point cut to one or more recipients on settlement, and supply refundAddress encoded for the source chain before creating an order. To execute a quote requested without it, request a fresh quote with the address included.

Create an Order

Pass the quote to POST /v4/create-order to lock in the quote and create an order. This reserves liquidity with the market maker and returns transaction details including:

  • For BTC to X (onramp, Bitcoin → chain): A Bitcoin address to send to, or a PSBT to sign.
  • For X to BTC (offramp, chain → Bitcoin): chain transaction data to execute.
  • For tokenSwap (chain → chain): chain transaction data to execute.
POST /v4/create-order
{ "onramp": { ...quote data } }

Order creation returns HTTP 201. For offramp and tokenSwap, the returned transaction data is a tagged GatewayTxData union — dispatch on type ("evm", "tron", or "solana").

Sign and Send Transaction

Execute the transaction:

  • For BTC to X (onramp): Create and sign a Bitcoin transaction to the provided address, or finalize the provided PSBT. Pass the raw signed transaction hex to Gateway in the next step.
  • For X to BTC (offramp) or tokenSwap: Sign and broadcast the chain transaction using the provided transaction data. On EVM/Tron use the call fields (to, data, value); on Solana, decode the base64 unsigned VersionedTransaction, sign it, re-serialize, and broadcast.

Submit a Signed Bitcoin Transaction

For onramps only, delegate broadcasting to Gateway:

PATCH /v4/register-tx
Content-Type: application/json

{
  "onramp": {
    "order_id": "f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
    "bitcoin_tx_hex": "<signed raw Bitcoin transaction hex>"
  }
}

Send the finalized transaction hex, not a PSBT or bitcoin_txid. Gateway validates the transaction against the order, screens it, and broadcasts it. The response is a string or an onramp object containing txid.

Skip this endpoint for offramps and token swaps: broadcast the source-chain transaction with the user's wallet, then monitor the order. Gateway indexes it from the chain.

Monitor Single Order

Track the status of a specific order using GET /v4/get-order/{id}. Returns the status and details for a single order by its order ID.

GET /v4/get-order/0x1234abcd...

Use this endpoint to monitor the progress of an individual order, including its current state and any updates.

Monitor All User Orders

Track the progress of all orders for a user using GET /v4/get-orders/{user_address}. Returns a page of pending and completed orders associated with the specified user address. Pass limit and reuse nextCursor as cursor until it is null or absent.

GET /v4/get-orders/0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb

Poll to update your UI from the inProgress, success, failed, or refunded status object. Settled transfers appear in received_tokens or refunded_tokens; dstInfo is the estimated destination amount.

The SDK wraps order creation and supported signing flows in executeQuote(), returning { order, tx }. Poll orders separately for settlement. For Solana source transactions, use the API and a Solana signer directly; see the SDK guide.

On this page