How to handle missing values ​​or time discrepancies in data retrieved from a gold price API？

When a gold price API is connected to a market application, getting the price is only the first step. The harder part often begins after the data reaches your system.

A missing candle, an out-of-order timestamp, or a few hours of timezone drift can affect charts, indicators, alerts, and historical analysis. Before changing the data, it is important to determine whether you are looking at a genuine data gap, a normal market break, or a problem in the ingestion pipeline.

The most reliable approach is to validate the incoming data, standardize timestamps, make the pipeline aware of trading sessions, and keep raw records separate from any values created for display.

Start by distinguishing a real data gap from a normal market break

One common mistake is to assume that every empty interval means the API has lost data.

For tick data, there is no requirement for a new price update to arrive at a perfectly fixed interval. A quiet period can contain fewer updates. For candlestick data, however, you can check whether an expected bar is missing from an active trading session.

That distinction matters because the handling strategy is different. A one-minute candle missing during an active session deserves investigation, while an empty period that falls inside a scheduled market break should not automatically be filled.

A basic validation layer can check the required fields before a record enters your database:

function validateBar(bar, previousBar) {
if (!bar.symbol || bar.price == null || bar.timestamp == null) {
return { valid: false, reason: "missing required field" };
 }

 const timestamp = Number(bar.timestamp);

if (!Number.isFinite(timestamp)) {
return { valid: false, reason: "invalid timestamp" };
 }

if (previousBar && timestamp < Number(previousBar.timestamp)) {
return { valid: false, reason: "out-of-order timestamp" };
 }

return { valid: true };
}

The field names above represent an application-level normalized format. They are intentionally separated from any specific provider response schema, so the same validation logic can be used after data from different sources is normalized.

Do not fill missing gold prices too early

When a value is missing, the first instinct is often to fill it immediately. That can make a chart look cleaner, but it can also change the meaning of the underlying data.

For dashboards, carrying the previous valid price across a short display gap may be acceptable when the application clearly treats it as a visual continuity technique.

For quantitative research, the safer approach is different. Keep the original record unchanged, mark the gap, and determine whether the missing interval can be recovered from another request before generating any derived value.

A practical order of operations is:

Interpolation has a place in visualization and some statistical workflows, but an estimated value should not silently become a historical market record.

This distinction is especially important for quantitative systems. A synthetic price can change an indicator calculation just as easily as a genuinely wrong price can.

Use market sessions when checking for missing data

Time-based validation becomes much more reliable when the application knows when the instrument is expected to be active.

For example, the current AllTick Commodities API page lists XAUUSD as spot gold and publishes its trading sessions in GMT 0, including a daily break. A gap that occurs inside that scheduled break should not be treated in the same way as an unexpected gap during an active session.

This suggests a simple rule for a gold market data pipeline:

The key is that gap detection should happen before filling. Otherwise, a normal trading break can be turned into fake market activity.

Standardize timestamps before storing data

Timestamp problems are easy to miss because the price itself may still look correct.

Suppose one system stores Unix timestamps while another uses formatted UTC strings, or a frontend interprets UTC as local time. The same price can then appear several hours earlier or later than it should.

A safer design is to convert all incoming timestamps into one internal format before storage:

function toUtcIso(rawTimestamp) {
 const value = Number(rawTimestamp);

if (!Number.isFinite(value)) {
 throw new Error("Invalid timestamp");
 }

 // Example: support Unix seconds or milliseconds
 const milliseconds =
 String(Math.trunc(value)).length === 10 ? value * 1000 : value;

 const date = new Date(milliseconds);

if (Number.isNaN(date.getTime())) {
 throw new Error("Invalid date");
 }

return date.toISOString();
}

The storage layer should use one standard representation, preferably UTC. Timezone conversion can then happen at the presentation layer when users need local market time.

This also makes it easier to compare historical and real-time records, generate daily or hourly candles, and investigate unexpected gaps without guessing which timezone was used at each stage.

Handle WebSocket data differently from historical data

Real-time gold applications often use a streaming connection because they need updates as they arrive. A WebSocket connection is useful for this part of the pipeline, but it should not be treated as the only source of truth.

A more resilient architecture separates live ingestion from recovery:

WebSocket → live updates

REST or historical query → snapshots and recovery

Validation layer → normalized storage

Application layer → charts, indicators, alerts

When a streaming connection drops, the application can reconnect and then check whether the stored timeline contains an unexpected gap. Depending on the data type available from the provider, the missing range can be requested again instead of being replaced immediately with estimated values.

This is one reason access method matters when choosing a gold market data API. A real-time stream is useful for live applications, while request-based access can provide another path for snapshots, historical candles, or data checks.

AllTick currently provides its commodities data through REST and WebSocket, with XAUUSD listed as a supported gold instrument. Its commodities product page also lists spot pricing, bid/ask quotes, OHLC candles, and historical time series as available data types.

A practical checklist for evaluating a gold data API

Instead of judging an API only by the number of endpoints it provides, evaluate whether its data can be monitored and recovered when something goes wrong.

A provider should make enough information available for you to answer a simple question: When my application sees a gap, can I determine why it happened and recover the original market data?

That is often more valuable than simply having a long list of endpoints.

When should you use REST and when should you use WebSocket?

The choice depends on what the application needs at that moment.

REST is a natural fit for one-time requests, snapshots, historical candles, and data recovery workflows. WebSocket is better suited to continuously changing prices where repeatedly polling an endpoint would add unnecessary overhead.

For a gold dashboard, for example, the initial page load can request the latest or historical data, while a WebSocket connection keeps the live price updated.

For a quantitative application, the same separation can be useful when building a pipeline that combines historical research with real-time market monitoring.

The important part is not choosing one protocol for everything. It is making sure both paths feed into the same validation and timestamp-normalization layer.

FAQ about missing values in gold price API data

Should missing gold prices always be filled?

No. First determine why the value is missing. A scheduled market break should remain a gap, while an unexpected gap during an active session may need recovery. For analytical or trading-related calculations, avoid silently replacing missing market records with estimated values.

Is UTC the best format for storing gold market data?

UTC is a practical internal standard because it avoids mixing local display times with stored event times. The important point is consistency: historical and real-time data should use the same timestamp convention.

Is REST or WebSocket better for a real-time gold application?

They solve different problems. WebSocket is suited to continuous price updates, while REST is useful for snapshots, historical data, and recovery requests. A system that needs both live and historical workflows can use the two together.

Build the data pipeline around recovery, not just ingestion

A gold price API can deliver data quickly, but application reliability depends on what happens when the stream becomes incomplete or timestamps do not line up.

The practical pattern is straightforward: validate incoming records, understand the instrument's trading schedule, normalize timestamps to UTC, detect unexpected gaps, recover original data where possible, and keep raw records separate from display-level values.

For developers looking for a single market data workflow across commodities and other asset classes, AllTick provides REST and WebSocket access, with XAUUSD available through its Commodities API.

Explore the AllTick Commodities API

Read the AllTick API documentation