Skip to main content
This quickstart takes you from network planning to a validated Starbase connection. Create and assign a Member before you create any API key; Starbase authentication depends on it. Message schemas and order workflows are covered in the Binary API Reference.
Starbase is not available over the public internet. You must connect through hosted colocation or a cross-connect in LD4, or through AWS Private Link. Contact colo-support@coinbase.com to arrange network access.

​
1. Choose a Deployment Model

The Starbase matching engine and its gateways run in Equinix LD4 in London. The Starbase API is exposed through several protocols, including SBE order entry, SBE multicast market data, FIX Drop Copy, and REST. A server in Tokyo or another remote region cannot match the round-trip latency of LD4 colocation because every order must reach the matching engine in London.
Scope: Starbase is for derivatives only. Spot trading is not available on Starbase and will migrate to a brokered solution via Coinbase Exchange (existing spot APIs remain unchanged). The standard WebSocket API is supported indefinitely alongside Starbase; the legacy SBE feed is scheduled for deprecation at the end of 2026. See Scope and migration.
For detailed trade-offs and cost categories, see Infrastructure, Connectivity & Best Practices.

​
2. Request Starbase Access

Before connecting:
  1. Ask your Account Manager or Technical Account Manager to enable Starbase on your test account.
  2. Confirm which main account and subaccounts will trade through Starbase.
  3. Arrange hosted colocation, a cross-connect, or AWS Private Link with colo-support@coinbase.com.
  4. Provide the source IP addresses that Deribit should allowlist.
Starbase API keys are separate from standard Deribit API keys. Do not create keys yet. The next step assigns those subaccounts to a Member, which is required before any Starbase key can be created.

​
3. Create and Assign a Member

Create a Member on the main account and assign every UID that will trade on Starbase before you create any API key. Skipping this step is the usual cause of the “No active member” error, and leaves the subaccount with no Starbase authentication.
  1. Switch into the main-account UID. Subaccounts cannot create or manage Members.
  2. Open the Starbase section of the Account Panel (not the standard API section).
  3. Click Add Member, give it a name, and select every main-account and/or subaccount UID that needs Starbase access.
  4. Confirm the Member is active and that each trading subaccount appears in its account list.
Most clients can configure only one Member, so add every UID to that Member. Broker clients that need separate Members for independent end clients must contact support@deribit.com first. You can do the same programmatically from the main account with private/set_member. See Creating and Assigning a Member for the UI and API workflow, and Account Model for how Members, portfolios, and rate limits relate.
“No active member” error: Key creation fails if the target account does not belong to an active Member. Members are managed at the main-account level only. Add the account to a Member first, then create the key while switched into the subaccount UID. Every subaccount that trades on Starbase needs a Member; without one there is no Starbase authentication for that subaccount.

​
4. Create a Starbase API Key

Create the key from the Starbase section of the Account Panel after the subaccount belongs to an active Member. Members are configured on the main account, but the key itself is created while switched into the subaccount UID that will use it. Select the Member and portfolio permissions required by the trading application. See Creating a Starbase API Key for the full UI and API workflow. Keep credentials out of source code, logs, packet captures, and support tickets. Store them in your organization’s secret-management system. Key and session limits to plan around:
  • Up to 8 Starbase API keys per subaccount (separate from the standard Deribit key quota; standard keys cannot authenticate to Starbase).
  • One connection per gateway per key, up to 10 connections across the 5 gateway pairs with a single key.
  • Reconnecting the same key to the same gateway terminates the existing session.

​
5. Prepare the Client

Download the integration resources: Then implement: Use IPv4. SBE order entry uses TCP, multicast market data uses UDP, and REST utility endpoints use plain HTTP. No Starbase traffic is TLS-encrypted. REST, FIX Drop Copy, and multicast are available only on private connectivity, and omitting TLS keeps latency lower.
Index and mark prices are published on the multicast feed. Index prices are distributed per currency pair via IndexInfo (12), mark price and price bands via InstrumentInfo (14), and funding rates and open interest via InstrumentRef (15). They are also available from the standard API (deribit_price_index.{index_name}, public/get_index_price, or ticker.{instrument}.{interval}). See Reference Data. Note also that quantityExponent is available via the multicast snapshot only; Starbase REST get_instruments conveys the same information via qty_tick_size, which equals minOrderQuantity × 10^quantityExponent. Classic JSON-RPC does not return qty_tick_size; use min_trade_amount instead. Neither field is contract_size. See Reference Data.

​
6. Validate Test Connectivity

Use the addresses and ports in Gateway Connectivity. Validate each service separately:
  1. Establish TCP connectivity to the test SBE order-entry gateway.
  2. Authenticate and maintain a healthy heartbeat exchange.
  3. Connect to FIX Drop Copy and complete its session logon.
  4. Receive both snapshot and incremental traffic from the required multicast channels.
  5. Verify that retransmit requests can recover an intentional market-data gap.
  6. Connect to the REST portfolio-management endpoints over HTTP.
Do not treat a successful TCP connection as a complete test. Authentication, heartbeats, sequence handling, multicast group membership, and recovery must all work.

​
7. Build a Resilient Session Layout

Production order-entry gateways are organized into hot-hot A/B pairs according to the instrument’s underlying tier: Connect only to the product groups you trade, but always connect to both A and B within each required pair. Both sides are active, and their rate-limit buckets are independent. Each API key can establish one connection to each gateway instance. A second connection using the same key on the same gateway disconnects the first. Order placement and fills are scoped to the API key and gateway session that originated the order. Amend and cancel acknowledgements are also delivered to the other session in the pair when that session sent the request. See Cross-session acknowledgements.

​
8. Validate End-to-End Behavior

On test, verify the complete lifecycle before requesting production access:
  • Submit, amend, and cancel a single order.
  • Send a mass quote if your strategy uses option quoting.
  • Confirm responses on the originating SBE session.
  • Confirm lifecycle events and fills on FIX Drop Copy.
  • Confirm trades through the standard private WebSocket API.
  • Confirm that open Starbase orders appear in the web UI (open orders and pre-trade risk refresh every 10 seconds) and do not appear in the private WebSocket order feed.
  • Reconcile orders across feeds: starbase_order_id on the standard APIs maps to OrderID (Tag 37) on Drop Copy, and fills deduplicate on the (starbase_match_id, starbase_order_id) tuple. See Reconciliation Across APIs.
  • Simulate a Drop Copy gap and recover it: detect the gap via MsgSeqNum (34), then replay fills with EventResendRequest (F3) and block trades with TradeCaptureReportRequest (AD).
  • Disconnect a session and verify Cancel on Disconnect behavior.
  • Reconnect with resetSeqNum=0 and confirm that a too-low inbound seqNum is rejected while a gap is ignored; after a SEQUENCE_RESET, reconnect with resetSeqNum=1. See Sequence numbers.
  • Reconnect, rebuild state, and resubmit only after reviewing current market conditions.
  • Exercise A/B failover without losing the local view of orders or the book.
Reconciliation essentials:
  • FIX Drop Copy is configured per Member. One session delivers the full Member feed for all subaccounts; filter on portfolioId for per-portfolio separation.
  • ClOrdID is FIX-only. To track a client order ID on WebSocket notifications, send it in the deribitLabel field.
  • Liquidation cancels arrive on the gateway where the order was placed. Monitor OrdersCanceled with cancelReason = 5 on every session.
  • A cancel sent from another session is reported to the submitting session as OrdersCanceled (schema version 17 or later). The cancelling session receives CancelOrderResponse.
  • Persist Drop Copy Execution Reports as they arrive; rejected and zero-fill orders cannot be retrieved from order history later.
Cancel on Disconnect is always enabled and session-scoped. Orders from a disconnected session are cancelled immediately and are not restored when the session reconnects.
Before production, also review behavior that can change order acceptance or timing: speed bumps, Market Maker Protection, Self Match Prevention, and risk bypass. Note the MMP scoping difference: order MMP applies per subaccount and base/quote pair, while mass-quote MMP works through an explicit mmpGroupId referenced on every MassQuoteRequest.
Utilizing the MMP risk bypass is the lowest-latency method for market access and the recommended default for most integrating clients. It works for both orders and mass quotes and reduces load on Deribit’s risk and margin engines.

​
9. Review Capacity

Starbase rate limits are applied per Member, per gateway, and per quoting type. API keys and sessions within the same Member do not each receive a fresh allocation. Before production:
  • Estimate steady-state and burst order rates by product tier. Burst and steady-state rates are identical under the defaults; per-member overrides can decouple them.
  • Separate single-order traffic from mass-quote traffic. Within a product tier, options and futures share the same buckets.
  • Use both A and B gateways where appropriate. Multiple keys or sessions do not multiply limits. The independent A and B buckets (an effective 2x per pair) are the only scaling factor.
  • Remember that cancels are never rejected for rate limits but do consume tokens: standard cancels cost the same as a new order, mass-quote cancels 1/20th, and mass cancels nothing.
  • Confirm the number of API keys and active orders required.
  • Discuss non-default allocations with your Account Manager.
See API Rate Limits for bucket behavior, defaults, and other limits, including the get_open_orders REST endpoint. That endpoint is capped at 10 requests per minute per portfolio on each REST gateway and is intended as a recovery tool rather than a live order feed.

​
10. Prepare for Production

Production readiness should include:
  • Redundant client hosts, network interfaces, and power where applicable
  • Active connections to both sides of every required gateway pair
  • Both A and B multicast feeds, including snapshot and retransmit recovery
  • Independent FIX Drop Copy ingestion and durable event persistence
  • Clock synchronization; colocated clients can request PTP
  • Metrics and alerts for session state, heartbeats, sequence gaps, rejects, and recovery
  • A tested runbook for disconnects, stale books, failover, and reconciliation
Use the production endpoints only after Deribit confirms that account, credentials, source IPs, and network access are ready.

​
Troubleshooting

If connectivity fails, record:
  • Test or production environment
  • Connectivity type and hosting provider
  • Account UID and Starbase ClientID
  • Source IP, destination IP, port, protocol, gateway, and side
  • UTC timestamps and the last successful heartbeat or sequence number
  • Whether side A, side B, or both are affected
  • TCP-connectivity results and a short sanitized packet capture
  • Expected behavior, observed behavior, and any reject code
Send network and multicast issues to colo-support@coinbase.com. Send protocol rejects and account-configuration questions to your Technical Account Manager or Deribit Support.

​
Next Steps

Creating and Assigning a Member

Create the Member and assign every trading subaccount before generating API keys.

Production Readiness Checklist

Verify Member setup, API key scopes, MMP risk bypass, SBE XMLs, and logon.

Infrastructure & Best Practices

Review deployment costs, gateway architecture, failover, and protocol selection.

Gateway Connectivity

Find test and production addresses, ports, and gateway mappings.

Binary API Reference

Implement session and order-entry messages.

Multicast Subscription Guide

Configure multicast reception and local book maintenance.