A crypto order book is a changing collection of buying and selling interest, not a prediction engine. A developer integrating one needs to know which venue produced it, which product it describes, and whether the local copy is still synchronized. Without that context, an attractive depth chart can be a confident picture of an outdated state.
The engineering problem is straightforward to state: construct a valid initial book, apply updates using the venue’s exact rules, and stop treating the result as current whenever continuity is uncertain. The details are where mistakes occur. An update can replace a quantity rather than add to it. A symbol can represent different quote assets on different venues. A reconnect can invalidate assumptions that were true seconds earlier.
Use this guide alongside the crypto bids page. The examples describe an implementation approach, not live market observations or a strategy for profitable trading.
Define the product precisely
Start with venue, product identifier, base asset, and quote asset. Do not normalize two markets into the same key merely because their names look similar. A BTC-USD market and a BTC-USDT market have different quote assets; an application should not silently treat their prices as interchangeable dollar observations. Spot and derivative instruments also need separate identities.
Store the provider’s original product identifier even after creating your own normalized key. That original value is useful for subscriptions, reconciliation, and support. Add the source’s precision and size constraints to instrument metadata rather than discovering them through repeated order failures. For read-only charts, those definitions still matter: rounding distinct levels into the same display value can hide meaningful differences in the data your application actually received.
Choose the level of detail you need
A top-of-book view focuses on the best bid and ask. A price-level book aggregates displayed quantity at each price. An order-level view carries finer information when the venue makes it available. More detail means more processing, storage, and recovery work; it is not automatically more useful for the person using the product.
Write the question the interface needs to answer. A comparison card might need only the best bid, best ask, and freshness. A depth visualization needs multiple levels and well-defined aggregation. A replay tool needs a retained stream and reproducible rebuild process. Selecting the data shape from the use case avoids collecting a complex feed simply because its name sounds more sophisticated. It also gives you a clear acceptance test for whether the chosen source is sufficient.
Follow the venue’s snapshot and update rules
The Coinbase Exchange WebSocket channel documentation describes its level2 snapshot and update workflow. Its update sizes represent the updated size at a price level, rather than an amount to add to the previous size. That distinction belongs in the adapter, not in a generic consumer that guesses how every exchange behaves.
Test replacement quantities
Build a fixture with an initial level of 2.0 units followed by an update to 1.5 units. A replacement-based implementation should end at 1.5, not 3.5. Add a removal fixture using the provider’s documented zero-size behavior. These tiny tests are more valuable than a beautiful chart during early development because they establish whether the local state means what the source intended. Apply the same discipline to every new venue rather than reusing an unverified mapping.
Treat synchronization as an explicit state
Give the local book a state such as initializing, synchronized, recovering, or unavailable. Rendering should depend on that state. A connection being open is not enough to label the book synchronized: the initial snapshot may still be missing, or a protocol-specific continuity check may have failed.
During recovery, the interface can retain the last valid view for context while clearly marking it as stale. Rebuild according to the provider’s prescribed process before re-enabling any dependent calculations. Avoid patching a suspected gap with an arbitrary fresh REST response unless the documented protocol explains how that response aligns with buffered updates. A superficially complete book can still be wrong if its snapshot and increments belong to different points in the event stream.
Use decimal-safe representations
Prices and quantities need a representation that preserves the precision your provider requires. A proposed internal format can use decimal strings at boundaries and a decimal arithmetic library for calculations. The important requirement is consistent interpretation, not a particular programming language or database.
Test values near precision limits, very small quantities, and repeated updates at the same price. Decide how the chart groups levels and distinguish presentation rounding from the underlying stored value. If a display groups prices into wider buckets, label that aggregation. A reader should not have to guess whether a large bar is a single quoted level or a sum across several levels. Keep the ungrouped observation available for debugging when the visual result seems surprising.
Calculate depth with transparent assumptions
A depth chart often accumulates displayed quantities as prices move away from the best quote. Explain whether the vertical measure is base-asset quantity or quote-asset value. Those are different calculations. In a fictional book, 2 units at 50 quote units per asset contribute 100 quote units of displayed value, while the base quantity remains 2.
Treat any estimated fill calculation as a scenario based on the observed book. It cannot establish that the same quantities will remain available when an order arrives. Include the snapshot time and the assumed quantity in the result. Fees, order restrictions, and changing liquidity may affect an actual outcome. A helpful interface exposes those assumptions instead of turning an illustrative calculation into an execution promise.
Monitor useful data, not just traffic
Measure the age of the last accepted book update, the time spent recovering, rejected messages, queue length, and the number of active product subscriptions. Separate administrative messages from state-changing updates. Otherwise, a stream of heartbeats can make a dashboard look healthy while the underlying book has stopped changing.
Use bounded queues and decide what happens when processing falls behind. For a stateful feed, dropping arbitrary updates may destroy correctness. Depending on the protocol, a controlled resynchronization can be safer than continuing with a partially applied stream. Alert on the domain-level consequence, such as “book stale,” rather than only reporting a generic network error. This makes the problem understandable to both operators and users without exposing unnecessary implementation detail.
Keep order submission in a separate path
A market-data consumer should not hold more authority than it needs. Keep read access separate from credentials capable of placing or cancelling orders. Where an application includes execution, route commands through explicit account authorization, budget controls, and a review process appropriate to the product.
The order lifecycle must be reconciled independently of the public book. Seeing a price level disappear does not prove that your own order filled; other market participants can change the same aggregate level. Use the account-specific order and execution records provided for that purpose. The bid API architecture guide explains how to separate observations, commands, and outcomes without losing the relationships between them.
Prove recovery before expanding coverage
Before adding a dozen venues, demonstrate that one connection can survive a restart, duplicate message, slow consumer, invalid payload, and interrupted initialization. Compare a rebuilt local state against a controlled fixture so the test has a definite expected result. Record enough diagnostic information to explain a mismatch without retaining secrets or unnecessary customer data.
A trustworthy crypto order book integration is a small state machine with strong evidence, not just a WebSocket and a chart. Choose the product precisely, follow the venue’s protocol, and mark uncertain state honestly. Once those foundations work, the event-handling reference provides complementary patterns for the asynchronous account events that may accompany a broader bidding application.
