> ## Documentation Index
> Fetch the complete documentation index at: https://docs.deribit.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Starbase Connectivity Quickstart
> Plan Starbase network access, resolve No active member errors, connect to test gateways and multicast feeds, and prepare a resilient production deployment.
This quickstart takes you from network planning to a validated Starbase connection. It focuses on connectivity and session readiness; message schemas and order workflows are covered in the [Binary API Reference](/starbase/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](mailto: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.
| Requirement | Recommended deployment |
| ------------------------------------------------ | ------------------------------------------------------------------------ |
| Lowest possible order-entry latency | Use hosted colocation or a cross-connect in LD4 |
| Private connectivity from an AWS-hosted stack | Use AWS Private Link; latency depends on the AWS region and route to LD4 |
| Monitoring, reconciliation, or disaster recovery | Run remotely, outside the critical execution path |
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](/starbase/overview#scope-and-migration).
For detailed trade-offs and cost categories, see [Infrastructure, Connectivity & Best Practices](/starbase/connectivity-best-practices#deployment-options).
## 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. Configure a [Member and its portfolios](/starbase/account-model).
4. Arrange hosted colocation, a cross-connect, or AWS Private Link with [colo-support@coinbase.com](mailto:colo-support@coinbase.com).
5. Provide the source IP addresses that Deribit should allowlist.
Starbase API keys are separate from standard Deribit API keys. A subaccount must belong to a Member before it can authenticate to Starbase.
## 3. Create a Starbase API Key
Create the key from the [Starbase section](https://www.deribit.com/account/BTC/starbase/api-keys) of the Account Panel. 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](/starbase/creating-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.
**"No active member" error**: Key creation fails if the target account does not belong to an active Member. Add the account to a Member first — Members are managed at the **main-account level only** — 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.
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 8 connections across the 4 gateway pairs with a single key.
* Reconnecting the same key to the same gateway **terminates the existing session**.
## 4. Prepare the Client
Download the integration resources:
* [SBE XML schemas](https://statics.deribit.com/files/deribit-sbe-xmls.zip) — schema definitions for order entry and market data
* [Starbase SDK](https://statics.deribit.com/files/starbase-deribit-sdk.zip) — client SDK for integrating with Starbase
* [Market data PCAP](http://statics.deribit.com/files/starbase-market-data.pcap) — sample multicast packet capture
Then implement:
* [SBE framing, encoding, and decoding](/starbase/binary-api-reference#message-structure)
* [TCP session establishment, authentication, heartbeats, and sequence tracking](/starbase/session-messages)
* Automatic reconnect and state recovery
* [Cancel on Disconnect handling](/starbase/cancel-on-disconnect)
* [UDP multicast reception, packet sequencing, and gap detection](/starbase/multicast-subscription-guide)
* [Snapshot plus incremental L3 order-book reconstruction](/starbase/order-book-maintenance)
Use **IPv4**. SBE order entry uses TCP, multicast market data uses UDP, and REST utility endpoints use HTTPS. FIX Drop Copy and multicast traffic are not TLS-encrypted because they are available only on private connectivity.
**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`](/api-reference/market-data/public-get_index_price), or `ticker.{instrument}.{interval}`). See [Reference Data](/starbase/reference-data#index-prices-and-derived-statistics). Note also that `quantityExponent` is available via the multicast snapshot only — it is not present in `get_instruments`.
## 5. Validate Test Connectivity
Use the addresses and ports in [Gateway Connectivity](/starbase/gateway-connectivity#test-environment). 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](/starbase/fix-drop-copy-api) and complete its session logon.
4. Receive both snapshot and incremental traffic from the required [multicast channels](/starbase/multicast-channels).
5. Verify that [retransmit requests](/starbase/retransmit-gateway) can recover an intentional market-data gap.
6. Connect to the [REST portfolio-management endpoints](/starbase/portfolio-management) over HTTPS.
Do not treat a successful TCP connection as a complete test. Authentication, heartbeats, sequence handling, multicast group membership, and recovery must all work.
## 6. Build a Resilient Session Layout
Production order-entry gateways are organized into hot-hot **A/B pairs** according to the instrument's [underlying tier](/starbase/underlying-tiers):
| Product group | Order-entry connections |
| ------------------------------------------------- | ----------------------- |
| [BTC (Tier 1)](/starbase/underlying-tiers#tier-1) | BTC A and BTC B |
| [ETH (Tier 1)](/starbase/underlying-tiers#tier-1) | ETH A and ETH B |
| [Tier 2](/starbase/underlying-tiers#tier-2) | Tier 2 A and Tier 2 B |
| [Tier 3](/starbase/underlying-tiers#tier-3) | Tier 3 A and Tier 3 B |
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 events are scoped to the API key and gateway session that originated the order.
## 7. Validate End-to-End Behavior
On test, verify the complete lifecycle before requesting production access:
* [Submit](/starbase/placing-new-order), [amend](/starbase/amending-order), and [cancel](/starbase/cancelling-order) a single order.
* Send a [mass quote](/starbase/mass-quotes) if your strategy uses option quoting.
* Confirm responses on the originating SBE session.
* Confirm lifecycle events and fills on [FIX Drop Copy](/starbase/fix-drop-copy-api).
* Confirm trades through the standard private WebSocket API.
* Confirm that open Starbase orders do **not** appear in the web UI or 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](/starbase/fix-drop-copy-api#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](/starbase/cancel-on-disconnect) behavior.
* 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.
* 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](/starbase/speed-bumps), [Market Maker Protection](/starbase/mmp), [Self Match Prevention](/starbase/smp), and [risk bypass](/starbase/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](/starbase/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, reduces load on Deribit's risk and margin engines, and is unaffected by the ongoing pre-trade risk testing.
## 8. 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](/starbase/mass-quotes) 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](/starbase/api-rate-limits) for bucket behavior, defaults, and other limits — including the `get_open_orders` REST endpoint, which is capped at 1 request per minute per IP and intended as a recovery tool rather than a live order feed.
## 9. 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](/starbase/multicast-channels), including snapshot and [retransmit recovery](/starbase/retransmit-gateway)
* Independent [FIX Drop Copy](/starbase/fix-drop-copy-api) ingestion and durable event persistence
* [Clock synchronization](/starbase/binary-api-reference#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](mailto:colo-support@coinbase.com). Send protocol rejects and account-configuration questions to your Technical Account Manager or Deribit Support.
## Next Steps
Review deployment costs, gateway architecture, failover, and protocol selection.
Find test and production addresses, ports, and gateway mappings.
Implement session and order-entry messages.
Configure multicast reception and local book maintenance.
## Related topics
- [Starbase API Overview](/starbase/overview.md)
- [Gateway Connectivity](/starbase/gateway-connectivity.md)
- [Quickstart Guide](/articles/deribit-quickstart.md)
- [Infrastructure, Connectivity & Best Practices](/starbase/connectivity-best-practices.md)
- [Starbase API Changelog](/changelogs/starbase.md)