Access MCX Spot Gold (MCX-XAUS) - Per 10 Grams Exchange Rates in JSON Format for REST APIs

For developers who need MCX spot gold in their apps, Access MCX Spot Gold (MCX-XAUS) - Per 10 Grams Exchange Rates in JSON Format for REST APIs is a pragmatic way to drive pricing, hedging, and analytics right where decisions get made—inside trading tools, fintech dashboards, ERP and MRP systems, jewelry e-commerce, and quant research notebooks. This guide shows how to retrieve MCX-XAUS quotes in JSON with Metals-API, interpret the payload correctly (including per 10 grams units), scale your integration, and avoid common pitfalls like weekend gaps and timezone mismatches—all with minimal code and maximum reliability.

Why MCX-XAUS in JSON matters for real products and trading desks

MCX (Multi Commodity Exchange of India) spot gold is the north star for jewelers, bullion dealers, wealth managers, and commodity traders in India. Exposing MCX-XAUS programmatically enables:

• Instant product repricing per 10 grams in Shopify, Magento, or custom POS.
• Risk dashboards that mark-to-market bullion inventory every few minutes.
• Quant models and time-series analytics on MCX spot moves and regime changes.
• Procurement apps that capture a dip to trigger purchase orders, or enforce margin controls.
• Research and learning tools that blend MCX-XAUS with currency moves (e.g., USDINR sensitivities).

With Metals-API Website, you get normalized, real-time and historical MCX-XAUS prices, delivered as compact JSON with consistent fields, timestamps, and units. That means less time parsing ad hoc feeds and more time building value on top of reliable data.

What you’ll build in this guide

We’ll focus on a realistic workflow that powers a live product page and a research chart:

• Fetch the latest MCX-XAUS spot rate (per 10 grams) to reprice a jewelry SKU.
• Query daily historical and time-series rates for MCX-XAUS to backfill a chart and compute volatility.
• Interpret fields you will actually use: timestamp, base, unit, and the MCX-XAUS rate.
• Add caching and weekend handling to avoid noisy UX and wasted calls.
• Harden the integration with error handling, quotas, and observability.

We’ll cover only the endpoints you need right now—Latest, Historical (by date), and Time-Series—then link to the full Metals-API Documentation and Metals-API Supported Symbols for anything beyond this workflow.

Quick primer: Gold units, base currency, and timestamps

Before we dive into requests, a few conventions will save you time:

• Unit: MCX-XAUS is quoted per 10 grams. Treat “per 10 grams” as the canonical unit for this symbol. If your business prices per gram or per troy ounce, convert explicitly.
• Base currency: Metals-API returns rates relative to a base currency (commonly USD by default). 1 USD equals X units of the selected metal according to the rate field. You can convert amounts explicitly using the API’s conversion endpoint (see docs), or apply your own math carefully.
• Timestamps: The API returns epoch timestamps and calendar dates. Treat timestamps as UTC unless your UI forces a local conversion, and be careful around day boundaries and market holidays.
• Market closures: MCX has non-trading days and off-hours. Latest will still return a payload with the most recent available timestamp; that’s expected and should not break your logic.

Symbols and availability

Always confirm symbol availability and attributes before you ship. MCX spot gold is represented as MCX-XAUS. Check it on the official symbols index: Metals-API Supported Symbols. This ensures your symbol is valid, unit semantics are clear, and your integration won’t fail due to a typo or unsupported symbol.

Authentication: your API key

You’ll need an access_key for all requests. Pass it as the access_key query parameter. If you don’t have one yet, sign up at the Metals-API Website and get a free API key to start testing today.

Endpoints you’ll use for MCX-XAUS

To keep your implementation focused and robust, we’ll use three endpoints:

• Latest Rates: for real-time MCX-XAUS to drive live pricing and risk.
• Historical Rates: for a single past date (e.g., yesterday’s close) to anchor P&L and reporting.
• Time-Series: for a range of daily values to backfill charts and compute metrics.

Update cadence for Latest depends on your subscription level (for example, updates can be every 60 minutes, 10 minutes, or faster, per plan). Historical data availability dates back to 2019 for most symbols.

Endpoint 1: Latest MCX-XAUS (per 10 grams)

Purpose

Retrieve the most recent MCX-XAUS spot price in JSON for use in live pricing, quotes, and immediate risk display.

HTTP request (curl)

curl -G https://metals-api.com/api/latest \
--data-urlencode "access_key=YOUR_ACCESS_KEY" \
--data-urlencode "symbols=MCX-XAUS"

Typical success response

{
"success": true,
"timestamp": 1790295597,
"base": "USD",
"date": "2026-09-25",
"rates": {
"MCX-XAUS": 0.01125
},
"unit": "per 10 grams"
}

Field-by-field explanation you’ll actually use

• success: Boolean indicating the request succeeded.
• timestamp: Unix epoch seconds for the price snapshot. Use this to manage caching, session coherence, and “as-of” labeling in your UI.
• date: Calendar date aligned to the timestamp. Treat as UTC. If your UI is in IST or local time, convert carefully.
• base: The currency the rates are relative to (commonly “USD”). That means the number in rates.MCX-XAUS expresses how many per-10-gram MCX units 1 USD buys, or equivalently how much MCX-XAUS per 1 base unit. If you need price per 10 grams in INR, you can combine this with a USD→INR rate or use the Convert endpoint.
• rates.MCX-XAUS: The rate for MCX-XAUS. Store it as a high-precision decimal. Avoid float rounding until display time.
• unit: “per 10 grams” indicates the quantity the MCX-XAUS figure refers to. Convert to grams or troy ounces when needed.

Common operations on the latest payload

• Per gram conversion: Divide per-10-gram price by 10. If your rate is R per 10g, per-gram = R / 10.
• Per troy ounce conversion: 1 troy ounce ≈ 31.1034768 grams. From per-gram, multiply by 31.1034768.
• Marking inventory: Price your on-hand grams = grams_on_hand × per-gram price. Store a snapshot with timestamp to preserve auditability.
• Staleness checks: If now - timestamp exceeds your tolerance (e.g., 30 min), display “Last updated” and consider a refresh.

JavaScript fetch example

async function fetchLatestMcxXaus(accessKey) {
const url = new URL("https://metals-api.com/api/latest");
url.searchParams.set("access_key", accessKey);
url.searchParams.set("symbols", "MCX-XAUS");

const res = await fetch(url.toString(), { method: "GET" });
if (!res.ok) {
throw new Error("HTTP " + res.status + " when fetching latest MCX-XAUS");
}
const data = await res.json();

if (!data.success || !data.rates || typeof data.rates["MCX-XAUS"] !== "number") {
throw new Error("Unexpected payload for MCX-XAUS: " + JSON.stringify(data));
}

const per10g = data.rates["MCX-XAUS"];
const perGram = per10g / 10;
const perTroyOunce = perGram * 31.1034768;

return {
asOf: new Date(data.timestamp * 1000).toISOString(),
base: data.base,
unit: data.unit, // expected "per 10 grams"
per10g,
perGram,
perTroyOunce
};
}

// Example usage
// fetchLatestMcxXaus(process.env.METALS_API_KEY).then(console.log).catch(console.error);

Performance and reliability tips for Latest

• Client- and edge-caching: Cache the latest payload keyed by symbol and base for a brief TTL aligned with your plan’s update frequency (e.g., 1–10 minutes). This reduces request volume and improves UI latency.
• Backoff and retry: Implement exponential backoff on transient HTTP errors. Consider circuit-breaking to fall back to the last known good value with an “as-of” label.
• Precision: Keep numbers as strings server-side and convert with a decimal library if your language’s float is imprecise. Round only in the final render step.
• Observability: Log timestamp deltas and payload size to detect anomalies (e.g., sudden staleness due to market closure or upstream issues).

Endpoint 2: Historical MCX-XAUS (by date) for P&L and reporting

Purpose

Pull the MCX-XAUS rate on a specific calendar date to anchor end-of-day P&L, compliance reporting, or to reconcile yesterday’s quotes in a ledger.

HTTP request (curl)

curl -G https://metals-api.com/api/2026-09-24 \
--data-urlencode "access_key=YOUR_ACCESS_KEY" \
--data-urlencode "symbols=MCX-XAUS"

Typical success response

{
"success": true,
"timestamp": 1790209197,
"base": "USD",
"date": "2026-09-24",
"rates": {
"MCX-XAUS": 0.01132
},
"unit": "per 10 grams"
}

How to use it in production

• EOD valuation: Store the exact JSON and timestamp with your ledger entries to ensure forensic reproducibility of P&L.
• Reconciliation: If your system ingests intraday quotes, re-mark to the historical close at 23:59:59 UTC (or your chosen EOD policy) using this endpoint for a stable book.
• Backfills: When first activating Metals-API, backfill gaps since 2019 (availability may vary) for the MCX-XAUS series your analytics require.

Best practices specific to historical data

• Date boundaries: Treat “date” as UTC. If your business day rolls over in IST or another timezone, normalize carefully when querying day D vs D-1.
• Missing days: Holidays and weekends may have no trading; you’ll receive the data the API has for the requested date. Consider a policy to roll forward the last business day for valuation or to flag a non-trading day in UI.
• Idempotency: Historical results for a past date are stable. Cache aggressively and pin hashes to detect silent downstream changes.

Endpoint 3: Time-Series MCX-XAUS for charts and analytics

Purpose

Retrieve MCX-XAUS daily rates across a date range for charting, quant metrics (volatility, drawdowns), and alert calibration.

HTTP request (curl)

curl -G https://metals-api.com/api/timeseries \
--data-urlencode "access_key=YOUR_ACCESS_KEY" \
--data-urlencode "start_date=2026-09-18" \
--data-urlencode "end_date=2026-09-25" \
--data-urlencode "symbols=MCX-XAUS"

Typical success response

{
"success": true,
"timeseries": true,
"start_date": "2026-09-18",
"end_date": "2026-09-25",
"base": "USD",
"rates": {
"2026-09-18": { "MCX-XAUS": 0.01134 },
"2026-09-20": { "MCX-XAUS": 0.01129 },
"2026-09-25": { "MCX-XAUS": 0.01125 }
},
"unit": "per 10 grams"
}

Field interpretation and usage

• timeseries: Confirms the payload covers a date range.
• start_date, end_date: The inclusive range in YYYY-MM-DD.
• rates: A dictionary keyed by date (UTC) with per-date objects. Each per-date object contains the MCX-XAUS value for that date.
• Sparsity: Some dates may be missing due to weekends/holidays. Decide whether your chart interpolates, holds previous, or skips points.

Practical analytics you can compute immediately

• Daily returns: r_t = (P_t / P_{t-1}) − 1. Use business days only; manage missing dates explicitly.
• Volatility: Annualize from daily standard deviation as sigma_annual ≈ sigma_daily × sqrt(252) (adjust day count for MCX holiday calendar as needed).
• Rolling windows: Compute 7D/30D averages and standard deviations. Cache results so you don’t recompute for static historical periods.
• Drawdowns: Track peaks and troughs to display risk and buying opportunities in dashboards.

Understanding units: per 10 grams, troy ounces, and conversions

MCX-XAUS is quoted per 10 grams. Developers often need per-gram, per-ounce, or per-kilogram conversions. Canonical conversions:

• Per gram = (per 10 grams) / 10
• Per troy ounce ≈ (per gram) × 31.1034768
• Per kilogram = (per gram) × 1000

Keep conversions on the server where you can control precision. In your UI, display with a currency formatter that supports scale, rounding, and trailing zeros for consistency.

Base currency, cross-rates, and conversion strategy

Metals-API returns exchange rates relative to a base currency (commonly USD). If your storefront or P&L is in INR, you can convert:

• Approach A: Get MCX-XAUS with base=USD and also pull USD→INR, then compute MCX-XAUS in INR on your side. Cache both series with timestamps for auditability.
• Approach B: Use the Convert endpoint to request your amount directly from USD to MCX-XAUS or vice versa. See the Metals-API Documentation for parameters and examples.

Choose one approach per workflow and stick to it for consistent rounding and reconciliation across systems.

Sample JSON walkthroughs for real UI needs

Latest → product page repricing

{
"success": true,
"timestamp": 1790295597,
"base": "USD",
"date": "2026-09-25",
"rates": { "MCX-XAUS": 0.01125 },
"unit": "per 10 grams"
}

• Compute per gram: 0.01125 / 10 = 0.001125.
• If displaying in INR and you have USD→INR = X, then price_per_gram_INR = 0.001125 × X.
• Apply your making charges, GST, and margins after converting to your display currency.

Historical → ledger EOD snapshot

{
"success": true,
"timestamp": 1790209197,
"base": "USD",
"date": "2026-09-24",
"rates": { "MCX-XAUS": 0.01132 },
"unit": "per 10 grams"
}

• Store this whole object under a data retention policy (e.g., 7 years) with a checksum.
• Derive per-gram/per-ounce only when exporting to reports to maintain source-of-truth integrity.

Time-series → chart and model

{
"success": true,
"timeseries": true,
"start_date": "2026-09-18",
"end_date": "2026-09-25",
"base": "USD",
"rates": {
"2026-09-18": { "MCX-XAUS": 0.01134 },
"2026-09-20": { "MCX-XAUS": 0.01129 },
"2026-09-25": { "MCX-XAUS": 0.01125 }
},
"unit": "per 10 grams"
}

• Plot date on X-axis, per-10g or per-gram on Y-axis, label unit clearly.
• If dates are missing, show breaks or annotate weekends to avoid misleading continuity.
• Compute rolling 7D average to smooth intra-week noise in widgets.

Caching and rate efficiency: build once, serve many

• Server cache: Cache latest per symbol with TTL matching your subscription update interval (e.g., 10 minutes). Invalidate automatically on a new timestamp.
• Edge/CDN: If you serve many UIs, push a minified JSON to your CDN when a new timestamp arrives. UIs poll your CDN, not the API, reducing latency and cost.
• Mobile clients: Bundle a last-known value for offline mode; refresh on resume with backoff.
• Deduplication: Coalesce concurrent requests on your backend to a single inflight fetch.

Handling weekends, holidays, and off-hours gracefully

• Display as-of labels: “Updated: 2026-09-25 10:30 UTC” avoids user confusion on quiet markets.
• Policy for non-trading days: Either hold last close (with explicit label) or hide dynamic components.
• Alerting: Don’t fire alerts on stale comparisons. Confirm both sides of a threshold comparison use prices with compatible timestamps.

Data validation and sanitization

• Schema checks: Ensure success is true, rates is an object, and rates["MCX-XAUS"] is a finite number.
• Bounds checks: For MCX-XAUS per 10g, define reasonable min/max to catch corrupt inputs (e.g., negative or NaN).
• Timezone labeling: Always store UTC timestamps and derive local time on presentation.
• Unit propagation: Persist “unit” with your stored values to prevent accidental mixing of per 10g and per ounce.

Security and compliance basics

• API key hygiene: Keep access_key on the server. Never embed in client apps without a trusted proxy.
• Secrets rotation: Support hot-rotation of keys. Monitor for spikes that suggest leakage.
• Least privilege: Only expose derived values to untrusted clients. Hide raw keys and internal logs.
• Transport: Use HTTPS only. Reject mixed-content if you embed charts in the browser.
• Audit trails: Log request IDs, timestamps, and payload hashes for compliance and dispute resolution.

Performance and scaling patterns

• Batch symbols: If you later add more MCX metals, fetch them in one request via symbols= param to amortize latency.
• Async pipelines: For time-series backfills, run in batch jobs during off-peak hours and cache results for BI tools.
• Compression: Enable gzip/brotli on your proxy. JSON compresses well.
• Pagination strategy: While the endpoints here return bounded payloads, design your storage with chunking for long historical windows.

Error handling and recovery strategies

• Graceful degradation: On transient errors, serve the last known good value with an “as-of” timestamp and a muted UI color to signal staleness.
• Backoff: Exponential backoff (e.g., 0.5s, 1s, 2s, 4s) with jitter for repeated failures.
• Alerting: Page only if data is stale beyond a business-critical SLO (e.g., 60 minutes). Otherwise, log and continue.
• User messaging: Replace hard errors with contextual info: “Live MCX data delayed—showing last update at 10:30 UTC.”

Observability: know when something is off

• Metrics: Track success rate, median/95th latency, bytes per response, and staleness (now - timestamp).
• Logs: Record the access_key hash, symbol list, and response hashes for deduping and debugging.
• Dashboards: Plot MCX-XAUS price alongside API staleness and request volume to correlate incidents with market quiet or spikes.

Architecture references for common stacks

• Server-rendered web (Node, Python, Ruby): Fetch Latest on the server with a short TTL cache. Inject derived per-gram and per-ounce into templates. Revalidate on navigation or at interval.
• Single-page apps: Expose a read-only endpoint from your backend that returns your cached MCX-XAUS JSON plus derived values and “as-of”. The frontend never touches Metals-API directly.
• Mobile: Warm the cache during app launch. Use a background task to refresh and notify the UI of new timestamps.
• Data warehouses: Land time-series daily snapshots with timestamped partitions; build materialized views for rolling metrics.

Production checklist for MCX-XAUS integration

• Symbol verified against Supported Symbols index.
• Unit handling tested (per 10g, per gram, per ounce) with rounding policies documented.
• Base currency assumptions documented and validated with finance stakeholders.
• Caching TTL aligned with subscription update frequency.
• Staleness banners and fallback flow implemented.
• Precision preserved end-to-end; rounding only at UI render time.
• Observability (metrics/logs/dashboards) in place.
• Security controls: server-only key, rotation plan, secrets scanning.

Innovation: building smarter tools on top of MCX-XAUS

With reliable MCX-XAUS in JSON, teams are delivering:

• Adaptive pricing: Price jewelry in real time, with guardrails that cap volatility passed to customers. Auto-snooze price changes below a threshold to limit catalog churn.
• Digital transformation of procurement: Trigger POs when MCX-XAUS dips below a rolling average minus N standard deviations; attach the JSON snapshot to the order.
• Market insights: Blend MCX-XAUS with foreign exchange and local tax regimes to display fully-loaded landed costs to branch managers in different states.
• Technology integration: Stream MCX-XAUS into your event bus; microservices subscribe to update inventories, hedges, and sales incentives instantly.
• Innovation in price discovery: Use time-series to build fair value models and detect deviations that merit dealer intervention or client advisories.

Compliance, audit, and data governance

• Immutable storage: Store raw JSON responses with timestamps in WORM-compliant buckets for audit trails.
• Lineage: Tag each derived metric (per gram, per ounce) with source timestamp and version to trace back to the raw feed.
• Access control: Restrict who can change pricing parameters and who can override feeds.
• Change management: Test updates to conversion logic and rounding in a staging environment with representative historical snapshots.

Practical pitfalls and how to avoid them

• Mixing units: Never combine per-10g MCX-XAUS with per-ounce benchmarks without normalizing. Store unit explicitly with each rate.
• Implicit timezone shifts: A day in IST is not a day in UTC. Convert dates carefully when computing returns or drawing daily charts.
• Rounding too early: Don’t round in the backend; propagate high precision to the view, then format for display.
• Over-polling: If your plan updates every 10 minutes, polling every 30 seconds just burns quota and adds noise.

Extensibility: beyond the three endpoints

For more specialized workflows—like intraday granularity, OHLC, or bid/ask—you can explore the broader API surface in the Metals-API Documentation. Keep this post’s patterns for unit handling, caching, and staleness logic as you expand.

Call to action: get your key and ship something valuable

Everything here is available now. Grab a free API key from the Metals-API Website, verify the MCX-XAUS symbol on the Supported Symbols page, and wire the Latest and Time-Series endpoints into your pricing page and chart widget. You’ll have a production-ready foundation in an afternoon.

Example end-to-end flow: from feed to final price

1. Fetch Latest for MCX-XAUS; store JSON and timestamp.
2. Compute per-gram; apply USD→local currency conversion if needed.
3. Add making charges, margins, and taxes per SKU or customer tier.
4. Render final price with an “as-of” timestamp.
5. Run a scheduled job nightly to fetch Historical for the day and store it for P&L.
6. Refresh a 30-day Time-Series daily to update charts and volatility bands.

Accessibility and UX notes for financial UIs

• Colorblind-safe deltas: Use patterns or markers in addition to color when showing up/down moves.
• Readable formats: Include thousand separators and fixed decimals appropriate for your currency.
• Tooltips: Put unit and as-of details in hover/tooltips for clarity.
• Responsive charts: Downsample data on mobile, but include a detail-on-demand interaction for exact values.

Additional resources

• Metals-API Documentation for all parameters, endpoint limits, and advanced features.
• Metals-API Supported Symbols to confirm MCX-XAUS availability and unit definitions.
• Metals-API Website to create your account and obtain an access key.
• Official MCX India for general exchange information and calendars.
• Troy weight reference for ounce/gram conversions used in precious metals.

Conclusion

Reliable access to MCX spot gold in JSON enables real-time pricing, disciplined risk, and rich analytics across fintech, trading, jewelry, and manufacturing workflows. In this guide, you integrated three purpose-built endpoints—Latest, Historical, and Time-Series—for MCX-XAUS quoted per 10 grams, learned how to handle units and base currency, and added production-grade caching, staleness, and observability. From here, you can extend to more granular endpoints while preserving the same integration hygiene. Start now: get your free key at the Metals-API Website, verify MCX-XAUS on the Symbols list, and ship a live pricing feature your users can trust.

FAQ

What does MCX-XAUS represent?

It’s the MCX spot gold symbol returned by Metals-API, quoted per 10 grams. Always confirm symbol definitions on the Supported Symbols page.

What unit does MCX-XAUS use?

Per 10 grams. Convert to grams or troy ounces explicitly when needed. Keep unit metadata with stored values to prevent mistakes.

What is the base currency?

Metals-API returns rates relative to a base currency (commonly USD). The number in rates[“MCX-XAUS”] reflects that base. Convert to your display currency via your own FX logic or the Convert endpoint in the docs.

How frequently are Latest rates updated?

Update intervals depend on your subscription plan (for example, every 60 minutes, 10 minutes, or faster). Align your cache TTL and polling cadence to your plan.

How far back does historical data go?

Historical rates are available for most symbols back to 2019. Verify the exact range you need and backfill accordingly.

How do I handle weekends and holidays?

Expect missing dates or stale timestamps during closures. Display an “as-of” timestamp, and choose a business rule: hold last close, annotate non-trading days, or pause certain UX features.

Can I request multiple symbols at once?

Yes. Batch them via the symbols parameter to reduce latency and request volume. For this article, we focused on MCX-XAUS specifically.

Where can I find a complete list of endpoints and parameters?

See the full Metals-API Documentation for detailed parameters, limits, and additional endpoints like intraday or OHLC.

How do I start?

Visit the Metals-API Website to get your free API key, confirm MCX-XAUS on the Supported Symbols page, and integrate the Latest and Time-Series endpoints into your first production use case.