Most crypto developers think of OHLCV as “candles on a chart.”

But in real-time systems, OHLCV behaves less like a candle and more like a live weather radar - constantly updating as conditions change.

If you treat a live radar feed like a daily forecast PDF, you’ll be surprised by the bandwidth bill.

Analogy

• REST OHLCV = downloading a finished report
• WebSocket OHLCV = subscribing to a live newsroom ticker

Same information domain, radically different delivery mechanics.

The misconception: “OHLCV is cheap”

Many developers assume OHLCV data is inherently lightweight.

The reasoning is straightforward:

• OHLCV is aggregated
• Aggregated data should be compact
• Therefore, streaming OHLCV must be inexpensive

This assumption breaks down in real crypto markets.

Crypto trading is continuous, not episodic. During active periods, trades occur constantly, prices move rapidly, and volatility increases the rate at which candle values change. As a result, exchanges and data providers emit incremental updates while a candle is still forming, rather than waiting to publish a single, final value at the end of the interval.

The result is that an aggregated candle can still generate many updates over its lifetime.

Key takeaway: aggregation reduces dimensionality, not update frequency.

REST OHLCV vs WebSocket OHLCV

Although REST and WebSocket OHLCV expose the same type of market data, they differ fundamentally in how that data is delivered, updated, and consumed.

REST OHLCV

REST OHLCV follows a classic request–response model. Each request returns a completed candle for a given period, making usage straightforward and predictable.

It is well suited for:

• charting and visualization
• historical analysis and backtesting
• dashboards and reporting systems

Because each request returns a fixed payload, REST OHLCV usage scales primarily with the number of requests made.

WebSocket OHLCV

WebSocket OHLCV is a streaming feed. Instead of delivering a single finalized candle, it publishes incremental updates while the candle is still forming.

Updates are typically sent:

• when trades occur and prices change
• at regular intervals during the open candle window

This makes WebSocket OHLCV ideal for:

• live trading strategies
• real-time monitoring
• signal generation and alerting systems

However, the number of messages generated depends on market activity and configuration, not just candle duration.

REST vs WebSocket OHLCV at a glance

A single OHLCV “candle” represents a logical aggregation window, not a guarantee of a single network message. In streaming systems, that window can produce many updates before it closes.

Why WebSocket OHLCV usage can spike month to month

When teams see a sudden increase in streaming usage, the cause is almost always architectural or behavioral. In practice, four factors account for the vast majority of month-over-month spikes.

1. Number of subscribed symbols

Each subscribed symbol produces its own independent stream of OHLCV updates. Subscribing to hundreds or thousands of symbols scales data volume linearly, even if all other settings remain unchanged.

2. Candle granularity

Shorter candle intervals generate updates more frequently:

• 1SEC/5SEC candles update rapidly and can produce many messages per minute
• 1MIN/5MIN candles change more gradually and generate fewer updates

Lower granularity increases sensitivity to market micro-movements, which directly increases message volume.

3. Market activity and volatility

Streaming volume is not constant over time. During periods of high volatility, trades occur more frequently and prices move faster, causing OHLCV values to update more often. Quiet markets naturally generate fewer updates.

4. Always-on subscriptions

WebSocket subscriptions are continuous by design. Leaving streams open 24/7 accumulates bandwidth over time, even if no one is actively monitoring the data or consuming every update downstream.

Key takeaway: a 10× increase in WebSocket OHLCV usage almost always reflects a change in subscription scope, configuration, or market conditions - not a billing or metering error.

Does OHLCV calculation methodology affect usage?

It’s reasonable to ask whether internal changes to OHLCV calculation could affect data usage. In practice, the impact is limited.

Minor improvements or refinements may slightly influence how often updates are emitted, but this effect is noticeable only at very low timeframes, such as sub-second or one-second candles. At higher intervals, candle values evolve more smoothly and update frequency remains effectively unchanged.

Crucially, these types of changes cannot explain order-of-magnitude increases in data volume.

Conclusion: significant usage spikes are driven by subscription scope, candle configuration, and market activity, not by changes to OHLCV calculation methodology.

Pricing transparency: how WebSocket data is actually billed

Understanding how streaming data is billed is essential for avoiding surprises and designing systems with predictable costs.

CoinAPI pricing model (simplified)

At a high level, CoinAPI applies different billing models depending on how data is delivered:

• REST APIs are billed using request-based credits
• Streaming APIs are billed by data volume (bandwidth), categorized into Tier 1 and Tier 2
• OHLCV over WebSocket falls under Tier 2 data

This distinction exists because streaming and request–response systems behave very differently at scale.

Why bandwidth-based pricing exists

WebSocket connections are continuous. Once a subscription is established, data flows whenever the market changes, without additional requests from the client. As a result, infrastructure cost scales with the number of bytes delivered, not with the number of API calls made.

For this reason, streaming usage is measured by bandwidth rather than request count.

An important difference from REST APIs

Unlike REST endpoints, WebSocket streams do not have discrete “request limits.” Usage is driven by external factors such as market activity, candle granularity, and the number of subscribed symbols. When markets are more active, more data is generated and delivered.

CoinAPI’s billing is deterministic and usage-based. Every byte delivered over streaming connections is measured, logged, and auditable. Customers can monitor near real-time consumption in the Customer Portal, with usage broken down by data tier and day. Spend Management controls allow teams to enforce hard limits and prevent unexpected overages entirely.

How to avoid unexpected overages (practical guidance)

Unexpected overages are rarely the result of a single mistake. They typically arise when real-time systems scale organically without clear guardrails. The following best practices help keep WebSocket OHLCV usage predictable and aligned with your budget.

Practical steps to reduce risk:

• Limit subscribed symbols to only those required for your strategy or application logic
• Avoid unnecessarily low candle periods, especially for monitoring or visualization use cases
• Close unused WebSocket connections rather than leaving streams running indefinitely
• Use REST OHLCV for charts, dashboards, and historical analysis where real-time updates are not required
• Enable Spend Management and configure a hard daily cap to prevent unplanned overages

These controls allow teams to benefit from real-time data where it matters, while keeping costs transparent and intentional.

Spend Management & safeguards

Spend Management exists to give teams explicit control over how much data they consume in a given day.

By setting a hard daily budget, customers can define an upper bound on usage. Setting the daily budget to $0 blocks overage entirely - once the daily allowance is reached, additional streaming data is paused rather than billed.

This approach eliminates surprise charges, but it introduces an important tradeoff.

The tradeoff: continuity vs cost certainty

With Spend Management enabled, teams gain cost certainty at the expense of uninterrupted data flow. If limits are reached, WebSocket streams may pause until the next billing window resets or limits are adjusted.

For applications where continuous real-time data is critical, teams may choose higher limits or allow overages. For cost-sensitive environments, strict caps provide predictability and protection.

The key is that the choice is explicit and configurable, allowing teams to align data delivery with their operational and budgetary priorities.

When WebSocket OHLCV is the right tool

WebSocket OHLCV is designed for use cases where timeliness matters more than completeness. It excels when applications need to react to market changes as they happen, not after a candle has closed.

WebSocket OHLCV is a good fit if you:

• trade or manage risk in real time
• react to intra-candle price or volume changes
• require sub-second or near-real-time visibility into market movements

In these scenarios, the additional data volume is a necessary tradeoff for speed and responsiveness.

When REST OHLCV is a better choice

REST OHLCV is better suited to use cases where finalized data and predictable usage are more important than immediacy.

REST OHLCV is typically the right option if you:

• render charts or visualizations
• build analytics or reporting dashboards
• run historical analysis or backtests
• prioritize cost predictability over real-time updates

Choosing the right delivery method ensures you get the data you need without unnecessary complexity or cost.

FAQ

Why do I receive multiple OHLCV updates for the same candle?

Because WebSocket OHLCV streams live aggregation. Updates are sent while the candle is still forming, not only when it closes.

Is WebSocket OHLCV more expensive than REST?

It can be, depending on:

• number of symbols
• candle period
• market activity REST has predictable costs; WebSocket scales with bandwidth.

Did CoinAPI change OHLCV calculation and increase my bill?

Methodology changes do not materially affect bandwidth usage except at very low timeframes. Large usage increases are driven by subscription patterns and market activity.

How can I cap my usage?

Enable Spend Management in the Customer Portal and set a hard daily budget. This blocks data flow once the limit is reached.

What plan should I use for large OHLCV subscriptions?

If you stream OHLCV across many symbols continuously, higher-tier or custom plans are usually more cost-effective than pay-as-you-go overages.

Can I monitor my usage in real time?

Yes. The Customer Portal shows near real-time usage by data tier, allowing proactive adjustment.

Conclusion

Real-time crypto market data behaves differently from historical or request-based data. Streaming systems reflect market activity as it happens, which affects update frequency and usage.

Understanding these mechanics, and applying appropriate limits, helps teams use WebSocket OHLCV effectively and predictably.

To go further, review the Market Data API documentation, or talk to support before scaling real-time subscriptions.