Use a stream-first crypto currency price API design with a REST snapshot as the repair path. Trust stream updates only while sequence numbers stay continuous and the connection is younger than the venue limit, 24 hours for Binance streams. On any gap or reconnect, discard local state, refetch a snapshot, and republish after the sequence resumes, or you keep serving a stale price.
- REST snapshots are point-in-time and carry no promise about the next update, so they cannot keep state fresh on their own.
- Coinbase requires a subscribe message within five seconds of connecting, or the server closes the connection.
- Binance stream connections expire after 24 hours and send a serverShutdown event, so planned reconnects are safer than surprise ones.
Where a Crypto Currency Price API Breaks in Production
A price service often looks perfect in a test and wrong in production. The usual reason is simple. The same asset arrives from two paths: a REST snapshot and a live WebSocket update.
Both can be correct and still disagree for a few seconds. A risk job that marks positions from a quiet stream keeps using an old number while the snapshot has already moved. This guide shows how to pick one trusted price, notice when it goes stale, and recover when a connection drops.
How Snapshot and Stream Paths Split Responsibility
A REST call returns one value at one moment. It says nothing about the next value, so polling decides freshness by call frequency. A stream sends changes as they happen, but those changes can be delayed, dropped, or cut off.
Coinbase states that a client must send a subscribe message within five seconds of connecting, or the server disconnects it. Binance states that a single stream connection stays valid for 24 hours and that a serverShutdown event warns before the venue closes it.
Coinbase Exchange WebSocket overview
Binance spot WebSocket streams reference
Implementation Choices, Failure Modes, and Recovery Controls
Two designs cover most services. A REST-only poller is easy to reason about but trades freshness for simplicity. A stream-first design reacts to every change but must rebuild state after any gap.
In both cases, one component should own the trusted price. Use sequence numbers as the referee: Coinbase documents that messages carry increasing sequence numbers per product, and that a jump larger than one integer means a message was dropped.
- Check that each update carries a sequence number or trade ID you can compare with the last one you applied.
- Check that the connection age is inside the venue window, which is 24 hours for Binance streams.
- Check that the newest update is inside the freshness budget you set for that asset.
- Check that no shutdown notice arrived, such as the Binance serverShutdown event.
Gaps, out-of-order messages, and clock skew cause most wrong prices. The safe response is the same for all three. Stop publishing, refetch a snapshot, resubscribe, and republish only after the sequence resumes. Store the source and receipt time with every value, because a number without a timestamp cannot be aged or audited.
Verification, Observability, and Deployment Decisions
Test the repair path the way you test a happy feed. Replay a recorded message log with one missing sequence number, then check that the service drops state, refetches a snapshot, and stays untrusted until the stream is continuous again.
For monitoring, track message gaps, resync time, connection age, and the age of the newest update. Set alert limits from your own measurements, not from vendor documentation, because venues publish limits but not your latency budget. Choose REST polling when seconds of delay are acceptable, and stream-first when your logic reacts to each trade.
The reconnect windows and limits above come from the venues' published documentation. Your freshness budget and alert thresholds remain your own operating choices.
Sources
- Exchange WebSocket Overview Coinbase Developer Documentation · 2026-09-29
- General WebSocket Streams information Binance Open Platform · 2026-09-29