How to Get Real-Time Mumbai Gold 18k (MUMB-18k) Prices Using Python and Metals-API

Building a real-time Mumbai gold 18k pricing workflow with Python and Metals-API starts with one practical goal: show the user exactly what an 18-karat gold gram costs right now in INR, and keep that value updated for quotes, cart totals, hedging, and risk dashboards. In this guide, we’ll use Metals-API’s real-time metals data to get the latest Gold (XAU) market price, convert it into a locally meaningful 18k per-gram INR value for Mumbai, and then extend the workflow with intraday updates, spreads, OHLC candles, historical backfills, and day-to-day fluctuation analysis. We’ll implement the core pipeline in Python, explain how to interpret the JSON responses you’ll use, and cover practical issues developers care about: troy ounces vs grams, base currency, timestamps and timezones, caching, and handling weekends and market closures.

Turn raw XAU into Mumbai 18k per gram in INR

Metals-API provides real-time Gold (XAU) prices referenced to a base currency (commonly USD). Gold spot is quoted per troy ounce, while jewelry and fabrication workflows in Mumbai need 18k gold per gram prices in INR. Here’s the exact mapping you will implement:

• Start with XAU quoted per troy ounce (spot) relative to a base currency (often USD).
• Convert the base currency to INR (if your Metals-API response isn’t already INR as base).
• Convert troy ounces to grams (1 troy ounce = 31.1034768 grams).
• Convert 24k to 18k purity (18k is 75% pure gold: 18 ÷ 24 = 0.75).
• Optionally add local fees (making charges, logistics) outside the scope of market price.

Metals-API gives you the market price. You can calculate 18k per gram using the purity ratio and unit conversion locally. If your plan supports the Carat Endpoint, you can also retrieve rate information by carat directly; if not, the formula above is the standard approach many teams use operationally.

Why digital gold data matters for Mumbai workflows

The convergence of digitized price discovery and precision data pipelines has transformed precious metals operations. With Metals-API, developers wire real-time XAU into:

• Retail jewelry e-commerce that reprices 18k items in INR as spot moves.
• Trading tools that blend L1 spot with bid/ask spreads and intraday bars.
• ERP and MRP systems that roll daily spot into production cost models.
• Fintech and wealth apps showing fractional gold holdings with live NAV.
• Quant research platforms backfilling historical pricing and risk factors.

Gold (XAU) sits at the intersection of macro hedging, manufacturing costs, and consumer pricing. Real-time metal prices as JSON are the connective tissue that keeps Mumbai pricing accurate and auditable.

Get started: endpoints you’ll actually use

We’ll focus on the endpoints you’ll need to go from XAU spot to 18k INR per gram, plus enhancements for intraday, bid/ask, OHLC, and day-to-day deltas. Full reference details live in the Metals-API Documentation, and you can confirm symbol support and availability on the Metals-API Supported Symbols page.

• Latest Rates: get current XAU rates (and other metals) in near real time.
• Convert: convert from one symbol to another (e.g., USD to XAU, USD to fiat, metal to metal).
• Time-series: backfill multi-day time windows for charts and analytics.
• Fluctuation: compute start-to-end change and percent change for a period.
• OHLC: get open, high, low, and close data for granular analytics.
• Bid/Ask: retrieve bid and ask prices for spreads and execution logic.
• Carat: obtain gold by carat if your plan includes the carat endpoint.

Metals-API returns data in a consistent JSON structure, with default units per troy ounce and a configurable base currency. Unless you request otherwise, the base often defaults to USD. Timestamps are provided to anchor the response to a precise moment—critical for reconciliation and audit.

Step-by-step: fetch XAU and compute MUMB 18k per gram

1) Fetch the latest XAU rate

Request the latest metal rates from Metals-API. The API can return many symbols at once; we’ll focus on XAU initially and keep other symbols handy for expansion.

curl -s "https://metals-api.com/api/latest?access_key=YOUR_API_KEY&symbols=XAU,XAG,XPT"

Example JSON (realistic structure and fields):

{
"success": true,
"timestamp": 1789606554,
"base": "USD",
"date": "2026-09-17",
"rates": {
"XAU": 0.000482,
"XAG": 0.03815,
"XPT": 0.000912,
"XPD": 0.000744,
"XCU": 0.294118,
"XAL": 0.434783,
"XNI": 0.142857,
"XZN": 0.344828
},
"unit": "per troy ounce"
}

How to read what you’ll actually use:

• success: boolean; verify before using the payload downstream.
• timestamp: Unix epoch seconds; store alongside your cached rate for audit and charting.
• base: the base currency used to quote the metals. Here, “USD”.
• rates.XAU: amount of XAU per 1 base currency unit (XAU per USD in this example). To find USD per troy ounce, invert: USD_per_oz = 1 / rates.XAU.
• unit: metals are per troy ounce by default. You’ll convert to grams.

2) Convert the base currency to INR

Your Mumbai workflow needs INR. You can either request the latest rates with INR as base (depending on your plan and parameters) or use the Convert endpoint to translate currency amounts. The Convert endpoint supports converting any amount from one symbol to another, which includes fiat and metals.

Convert endpoint example JSON structure (illustrative):

{
"success": true,
"query": {
"from": "USD",
"to": "XAU",
"amount": 1000
},
"info": {
"timestamp": 1789606554,
"rate": 0.000482
},
"result": 0.482,
"unit": "troy ounces"
}

How to apply this pattern to INR:

• To get INR per USD, set from="USD", to="INR", amount=1. The result is how many INR equal 1 USD at the current timestamp.
• Alternatively, request latest rates with base=INR and interpret rates.XAU as XAU per INR, then invert to get INR per troy ounce.

Either approach yields a precise INR conversion you can combine with the XAU spot to price 18k per gram in Mumbai.

3) Convert troy ounces to grams, then 24k to 18k

• 1 troy ounce = 31.1034768 grams.
• 18k purity = 18/24 = 0.75 of pure gold content.

Once you have INR per troy ounce for 24k, divide by 31.1034768 to get INR per gram (24k), then multiply by 0.75 to get INR per gram for 18k. Apply local making charges, taxes, and logistics in your own application layer as needed—they’re not part of raw market data.

4) Python example: end-to-end MUMB 18k per gram

This snippet shows the core calculation using Metals-API data. Adjust the error handling, logging, and caching strategy for production.

import os
import math
import requests

API_BASE = "https://metals-api.com/api"
API_KEY = os.getenv("METALS_API_KEY") # Get a free key: https://metals-api.com

TROY_OUNCE_TO_GRAM = 31.1034768
K18_PURITY = 18.0 / 24.0

def latest_xau_per_usd():
# Fetch latest metals; base defaults to USD in most setups
url = f"{API_BASE}/latest"
params = {
"access_key": API_KEY,
"symbols": "XAU"
}
r = requests.get(url, params=params, timeout=10)
r.raise_for_status()
data = r.json()
if not data.get("success"):
raise RuntimeError(f"Metals-API error: {data}")
# XAU per USD
xau_per_usd = data["rates"]["XAU"]
ts = data["timestamp"]
return xau_per_usd, ts

def usd_to_inr_rate():
# Use convert endpoint for a 1 USD to INR conversion
url = f"{API_BASE}/convert"
params = {
"access_key": API_KEY,
"from": "USD",
"to": "INR",
"amount": 1
}
r = requests.get(url, params=params, timeout=10)
r.raise_for_status()
data = r.json()
if not data.get("success"):
raise RuntimeError(f"Metals-API error: {data}")
# Result is INR per 1 USD
inr_per_usd = data["result"]
ts = data["info"]["timestamp"]
return inr_per_usd, ts

def compute_mumbai_18k_inr_per_gram():
xau_per_usd, ts1 = latest_xau_per_usd()
inr_per_usd, ts2 = usd_to_inr_rate()

# USD per troy ounce for 24k = 1 / (XAU per USD)
usd_per_oz_24k = 1.0 / xau_per_usd

# INR per troy ounce for 24k
inr_per_oz_24k = usd_per_oz_24k * inr_per_usd

# INR per gram (24k)
inr_per_gram_24k = inr_per_oz_24k / TROY_OUNCE_TO_GRAM

# INR per gram (18k)
inr_per_gram_18k = inr_per_gram_24k * K18_PURITY

# Timestamp to use: choose the fresher of the two
ts = max(ts1, ts2)
return inr_per_gram_18k, ts

if __name__ == "__main__":
price_inr_g_18k, ts = compute_mumbai_18k_inr_per_gram()
print(f"Mumbai 18k price: {price_inr_g_18k:.2f} INR/gram (timestamp: {ts})")

Notes for production:

• Cache both responses so you’re not making redundant requests intra-minute (or within your plan’s update interval). Keep the timestamp with the cached value for audit and backtesting.
• If your plan supports the Carat Endpoint, you can directly retrieve gold rates by carat. Otherwise, the purity conversion shown here aligns with the standard 24k → 18k mapping many retailers use under the hood.
• If your plan supports base=INR on the latest endpoint, you can reduce requests by asking for INR-based XAU in one call, then applying unit and purity conversions in-app.

Drilling into endpoint responses you’ll use repeatedly

Latest rates: real-time backbone for Mumbai 18k repricing

In most integrations, the Latest Rates endpoint is your primary data feed. Depending on your subscription plan, updates arrive every 60 minutes, every 10 minutes, or at faster intervals. You’ll map the latest XAU into INR 18k per gram and push it into downstream systems (e-commerce price labels, quotes, ERP cost sheets, etc.).

Example response and interpretation recap:

{
"success": true,
"timestamp": 1789606554,
"base": "USD",
"date": "2026-09-17",
"rates": {
"XAU": 0.000482,
"XAG": 0.03815,
"XPT": 0.000912
},
"unit": "per troy ounce"
}

• Use success to guard your parsing; if false, don’t update live prices.
• Use timestamp and date for display and record-keeping; always store the timestamp with your cached rate.
• Use rates.XAU to compute per-ounce and per-gram pricing; invert to get the base currency per ounce.
• Use unit to confirm you’re doing the correct unit conversion to grams.

Best practices:

• Minimize payload: include only needed symbols (e.g., XAU) to reduce bandwidth and latency.
• Cache conservatively: if your plan’s real-time granularity is, for example, every 10 minutes, avoid calling more often than the data updates unless your architecture needs confirmation.
• Fallback logic: if Latest is temporarily unavailable, you can fall back to the most recent successful cached rate until the next refresh window.

Convert: the glue for INR localization and cross-symbol math

Use Convert to translate amounts across fiat and metals. For Mumbai, two frequent patterns are:

• Get INR per USD (amount=1), then combine with XAU spot.
• Use INR as base for Latest (when supported) to avoid separate conversion calls.

Convert example JSON structure (illustrative of fields you will receive):

{
"success": true,
"query": {
"from": "USD",
"to": "XAU",
"amount": 1000
},
"info": {
"timestamp": 1789606554,
"rate": 0.000482
},
"result": 0.482,
"unit": "troy ounces"
}

• query: echoes your from/to/amount; log it for traceability.
• info.rate: the applied conversion rate; often what you want to persist if you need to replay calculations.
• result: the converted amount; in this example, USD → XAU returns troy ounces.
• unit: unit of the result; keep this to avoid accidental double conversions.

Optimization tip: If multiple services need INR, centralize Convert usage so you don’t repeat requests across services. For example, publish an internal INR reference rate to a message bus and let downstream consumers subscribe.

OHLC: open, high, low, close for trading and analytics

When you need intraday analytics, the Open/High/Low/Close endpoint provides a richer snapshot than a single latest tick. This is particularly useful for volatility-aware repricing rules (e.g., if intraday high-low range exceeds X%, widen retail markup).

Example response:

{
"success": true,
"timestamp": 1789606554,
"base": "USD",
"date": "2026-09-17",
"rates": {
"XAU": {
"open": 0.000485,
"high": 0.000487,
"low": 0.000481,
"close": 0.000482
},
"XAG": {
"open": 0.03825,
"high": 0.0383,
"low": 0.0381,
"close": 0.03815
},
"XPT": {
"open": 0.000915,
"high": 0.000918,
"low": 0.00091,
"close": 0.000912
}
},
"unit": "per troy ounce"
}

Usage ideas:

• Compute day range: high − low, and range% relative to open or close.
• Compute close-to-close change for summary reports.
• Plug close into your 18k-INR pipeline for “official daily close” pricing vs. “live” quotes.

Bid/Ask: spreads for execution, quotes, and slippage buffers

When you or your counterparties transact near spot, the spread between bid and ask matters. Mumbai pricing engines often add a buffer relative to midprice or ask to avoid negative slippage in fast markets.

Example response:

{
"success": true,
"timestamp": 1789606554,
"base": "USD",
"date": "2026-09-17",
"rates": {
"XAU": {
"bid": 0.000481,
"ask": 0.000483,
"spread": 2.0e-6
},
"XAG": {
"bid": 0.0381,
"ask": 0.0382,
"spread": 0.0001
},
"XPT": {
"bid": 0.000911,
"ask": 0.000913,
"spread": 2.0e-6
}
},
"unit": "per troy ounce"
}

Field meanings:

• bid, ask: quoted as XAU per USD (when base=USD) per troy ounce. Compute mid = (bid+ask)/2 if needed.
• spread: convenience field, often ask − bid.

Pricing policy example: Use ask for customer buy quotes and bid for customer sell quotes, then convert to 18k INR per gram as shown earlier. If using mid, add a configurable buffer based on recent volatility regime.

Time-series: backfill for charts and analytics

To render a historical price chart or power analytics like moving averages, use Time-series. You’ll get daily historical rates between a chosen start_date and end_date. This is essential for dashboards where Mumbai stakeholders want to visualize 18k-INR trends.

Example response:

{
"success": true,
"timeseries": true,
"start_date": "2026-09-10",
"end_date": "2026-09-17",
"base": "USD",
"rates": {
"2026-09-10": {
"XAU": 0.000485,
"XAG": 0.03825,
"XPT": 0.000915
},
"2026-09-12": {
"XAU": 0.000483,
"XAG": 0.0382,
"XPT": 0.000913
},
"2026-09-17": {
"XAU": 0.000482,
"XAG": 0.03815,
"XPT": 0.000912
}
},
"unit": "per troy ounce"
}

Common pattern: For each date, invert the XAU-per-USD to USD-per-oz, convert to INR using the historical USD→INR for the same date (via Convert or a historical currency rate), then map to per-gram and 18k. Cache results for fast chart rendering.

Fluctuation: day-to-day move summary

To quickly summarize how much gold moved over a period, use Fluctuation. This is useful for explaining retail price changes in-app (e.g., “Gold 18k moved +0.6% this week”).

Example response:

{
"success": true,
"fluctuation": true,
"start_date": "2026-09-10",
"end_date": "2026-09-17",
"base": "USD",
"rates": {
"XAU": {
"start_rate": 0.000485,
"end_rate": 0.000482,
"change": -3.0e-6,
"change_pct": -0.62
},
"XAG": {
"start_rate": 0.03825,
"end_rate": 0.03815,
"change": -0.0001,
"change_pct": -0.26
},
"XPT": {
"start_rate": 0.000915,
"end_rate": 0.000912,
"change": -3.0e-6,
"change_pct": -0.33
}
},
"unit": "per troy ounce"
}

Interpretation:

• start_rate and end_rate: same structure as Latest, i.e., metals per base currency per troy ounce.
• change and change_pct: already computed for you; translate to your 18k INR domain if you want to display localized deltas.

Historical rates: precise snapshots for any given date

For audits, backtesting, or end-of-day valuation, query the Historical Rates endpoint by appending a date. Historical rates are available dating back to 2019 (check documentation for specifics and plan limits).

Example response:

{
"success": true,
"timestamp": 1789520154,
"base": "USD",
"date": "2026-09-16",
"rates": {
"XAU": 0.000485,
"XAG": 0.03825,
"XPT": 0.000915,
"XPD": 0.000748
},
"unit": "per troy ounce"
}

Combine with historical currency conversion (e.g., USD to INR) to reconstruct INR 18k per gram for that exact date. This is particularly important for financial reporting, where you must not mix today’s INR with yesterday’s XAU.

Intraday and LME: advanced use cases

Depending on your plan and use case:

• Intraday: pull intraday exchange rate data for a single symbol to power minute-level dashboards or short-horizon alerting.
• Historical LME: for industrial metals with LME symbols, access data dating back to 2008. If you price lines that use copper or aluminum alongside gold, this gives you a consistent API surface across assets.

Carat Endpoint: direct 18k query (when available)

Metals-API includes a Carat Endpoint to retrieve gold rates by carat. If your plan includes this feature, you can streamline Mumbai workflows by calling for 18k directly, removing the need for the 24k-to-18k conversion logic. If you don’t have access to Carat, the mathematical conversion demonstrated above is standard and reliable.

Practical implementation guidance for Mumbai pricing

Units: troy ounces vs grams

• Metals-API uses per troy ounce for gold by default. 1 troy ounce = 31.1034768 grams.
• Do not confuse with avoirdupois ounces (28.3495 grams). Using the wrong ounce type will skew prices by nearly 10%.
• For display and invoicing in India, normalize to INR per gram and per 10 grams as needed by your UI/UX.

Base currency and inversion

• When base is USD, rates.XAU means XAU per 1 USD. Invert to get USD per troy ounce.
• To localize to INR, either request base=INR where supported or convert USD→INR via the Convert endpoint.
• Keep all math explicitly labeled in code to avoid accidental double inversions.

Timestamps and timezone

• Responses include timestamp (Unix epoch seconds). Store it with the price for audit and reconciliation.
• If your UI shows “as of” time, convert the timestamp to Asia/Kolkata for Mumbai-facing users.
• If you aggregate across endpoints (Latest + Convert), choose a single authoritative timestamp (e.g., the max of the two) and record both in logs for traceability.

Caching to save requests and stabilize UX

• Respect the update cadence of your plan (e.g., every 10 or 60 minutes). Cache within that window.
• Build a small in-memory cache with TTL equal to your update frequency; refresh asynchronously.
• On API errors, continue serving the last known good price and annotate the timestamp in the UI.

Handling weekends and market closures

• Gold trades around the clock during weekdays with gaps across weekends and holidays. Expect flat updates over closures.
• Design your charts and backfills to handle missing dates gracefully (no spikes due to division by zero or nulls).
• Explain stable weekend prices to users if your UI exposes intraday movements.

Validation, security, and error handling

Authentication and authorization

• Your API key is passed via the access_key parameter. Keep it server-side; don’t embed in client apps.
• Rotate keys periodically. Store them in secret managers rather than environment variables in CI logs.
• Limit access in staging environments and sanitize logs to avoid leaking keys.

Error handling strategies

• Always check success in the JSON. If false, inspect the payload for error information and skip updating live prices.
• Implement retries with jittered backoff. Cap retries to avoid thundering herds.
• Use circuit breakers to prevent cascading failures in dependent services.

Data validation and sanitization

• Validate that rates.XAU is present and numeric. If not, reject the update.
• Sanity-check changes: if your computed INR/gram 18k price jumps more than a defined threshold between updates, hold the change for review or fetch a confirmatory sample.
• Log the entire transformation chain: XAU per USD → USD per oz → INR per oz → INR per gram → 18k INR per gram.

Security best practices

• Use HTTPS for all requests. Do not disable TLS verification.
• Keep API keys out of client JavaScript and mobile binaries to prevent scraping/abuse.
• Restrict outbound IPs in your infrastructure if possible, and monitor egress to detect anomalies.

Designing for performance and scale

Architectural considerations

• Central pricing service: create a single microservice that calls Metals-API, computes INR 18k per gram, and publishes to Redis or a message bus for consumption by web, mobile, ERP, and billing.
• Fan-out via pub/sub: downstream services subscribe to the latest price topic instead of each calling the API.
• Snapshot storage: write each update with its timestamp to a time-series database for analytics and audit.

Request optimization

• Batch needed symbols in one Latest call when possible.
• For INR localization, prefer a single call that returns INR-based XAU pricing if supported by your plan; otherwise, use one Convert call per refresh interval.
• Compression and minified JSON parsing reduce bandwidth and CPU in high-throughput systems.

Resilience

• Async refresh loop: refresh in the background and update an atomic cache object to prevent partial reads mid-update.
• Graceful degradation: if Bid/Ask is temporarily unavailable, fall back to Latest midprice or the previous cached spread regime.
• Alerting: trigger alerts if no successful refresh occurs within 2× your expected update interval.

Data analytics and market insights built on XAU

Once you have a robust Mumbai 18k INR price stream, you can unlock additional value:

• Volatility-aware pricing: widen/contract markups based on intraday OHLC ranges.
• Event tagging: annotate time-series data with RBI announcements, USD/INR moves, or global macro events for post-mortem analysis.
• Factor models: blend XAU with currency factors (e.g., DXY proxies) to explain INR 18k moves to stakeholders.
• Customer analytics: track how price changes influence conversion rates in your e-commerce funnel.

Carat-specific notes for Mumbai workflows

If your plan includes the Carat Endpoint, it can return gold rates by carat directly. This can simplify your pipeline:

• Directly request 18k gold data instead of applying purity multipliers client-side.
• Keep your pricing code cleaner and reduce room for unit/purity mistakes.
• Still, validate and log unit and timestamp for audit and compliance.

When Carat is unavailable in your plan, client-side purity conversion remains straightforward and reliable as long as you keep unit conversions explicit and tested.

Extended endpoint walkthroughs with scenarios and tips

Latest rates: additional scenarios and pitfalls

• Scenario: Your base must be INR across the stack. If your plan supports base selection for Latest, set base=INR to avoid a separate Convert call. Then, invert rates.XAU to get INR per oz and proceed to grams and 18k.
• Pitfall: Double inversion. If you already set base=INR, don’t invert twice. Always log base and unit to prevent confusion.
• Performance: If multiple services poll Latest, centralize the poll and distribute internally.

Historical rates and Time-series: backfill safely

• Scenario: Backfill the last 90 days of 18k INR prices. Pull Time-series for XAU; for each day, use a matching historical currency rate to avoid today’s INR skewing yesterday’s gold price.
• Pitfall: Weekends/holidays. Expect missing days or flatlines. Render charts with gaps or step lines appropriately.
• Performance: Cache historical results on disk or in object storage; they don’t change post-facto.

Fluctuation and OHLC: present concise insights

• Scenario: Show “This week: −0.62%” in your app’s header for 18k INR. You can compute deltas after localization, or display the XAU delta directly and then add a note that currency effects may differ in INR.
• Pitfall: Mixing local and base calculations. Be clear if a displayed percentage is in base=USD or in INR terms (which also reflects FX moves).
• Performance: Pre-compute and cache weekly summaries for dashboards to avoid recomputation at page load.

Bid/Ask: quoting rules and customer transparency

• Scenario: For buy orders, use ask; for sell orders, use bid. Convert to INR 18k per gram for final quotes.
• Pitfall: Quoting mid but executing at ask leads to negative P&L. Align display prices and execution logic.
• Performance: If spreads are stable, you can sample Bid/Ask less frequently than Latest, with fallback to previous spreads during brief outages.

Putting it all together: a Mumbai 18k pricing blueprint

• Ingest: pull Latest XAU and either use base=INR or Convert USD→INR periodically.
• Transform: compute INR per oz → INR per gram → INR per gram 18k.
• Augment: integrate Bid/Ask or OHLC where needed for quotes and analytics.
• Publish: expose a pricing endpoint internally that returns the current 18k INR per gram with timestamp and inputs used.
• Persist: write each update with timestamp to a time-series store for charts and compliance.
• Monitor: alert on stale prices, excessive volatility, or parsing errors.

Example: interpreting realistic JSON responses end-to-end

These examples match the structure you’ll receive from Metals-API and illustrate how to extract fields you will rely on in code and operations.

Latest (XAU only) → USD per oz

{
"success": true,
"timestamp": 1789606554,
"base": "USD",
"date": "2026-09-17",
"rates": {
"XAU": 0.000482
},
"unit": "per troy ounce"
}

• Compute USD per oz = 1 / 0.000482
• Keep timestamp 1789606554 for audit.

Convert (pattern for currency) → INR per USD

{
"success": true,
"query": {
"from": "USD",
"to": "XAU",
"amount": 1000
},
"info": {
"timestamp": 1789606554,
"rate": 0.000482
},
"result": 0.482,
"unit": "troy ounces"
}

• Use this structure as a guide; when converting USD→INR with amount=1, “result” becomes INR per USD, and you will use it as a multiplier on USD prices.
• Use info.timestamp to reconcile with Latest timestamps.

OHLC (for intraday analytics)

{
"success": true,
"timestamp": 1789606554,
"base": "USD",
"date": "2026-09-17",
"rates": {
"XAU": {
"open": 0.000485,
"high": 0.000487,
"low": 0.000481,
"close": 0.000482
}
},
"unit": "per troy ounce"
}

• Compute day range and volatility proxies; feed into dynamic markup logic.
• Use close for end-of-day INR 18k snapshot if you publish daily marks.

Bid/Ask (for spreads and execution)

{
"success": true,
"timestamp": 1789606554,
"base": "USD",
"date": "2026-09-17",
"rates": {
"XAU": {
"bid": 0.000481,
"ask": 0.000483,
"spread": 2.0e-6
}
},
"unit": "per troy ounce"
}

• Convert bid and ask separately to INR 18k per gram and display both in B2B dashboards.

Time-series (for multi-day charts)

{
"success": true,
"timeseries": true,
"start_date": "2026-09-10",
"end_date": "2026-09-17",
"base": "USD",
"rates": {
"2026-09-10": { "XAU": 0.000485 },
"2026-09-12": { "XAU": 0.000483 },
"2026-09-17": { "XAU": 0.000482 }
},
"unit": "per troy ounce"
}

• For each date: invert to USD per oz → convert to INR per oz (with that date’s currency rate) → grams → 18k.

Fluctuation (for summary deltas)

{
"success": true,
"fluctuation": true,
"start_date": "2026-09-10",
"end_date": "2026-09-17",
"base": "USD",
"rates": {
"XAU": {
"start_rate": 0.000485,
"end_rate": 0.000482,
"change": -3.0e-6,
"change_pct": -0.62
}
},
"unit": "per troy ounce"
}

• Use change_pct for UX-friendly summaries. If you need INR-localized change, compute after INR conversion.

Troubleshooting and common pitfalls

• Incorrect unit conversion: Mixing troy ounce and avoirdupois ounce will skew INR/gram by a material amount. Write a unit test that asserts the 24k-per-gram calculation from a known USD-per-oz input.
• Double conversion: If you set base=INR on Latest, do not also apply a separate USD→INR conversion.
• Missing fields: Always check success and the presence of rates.XAU. If absent, skip updating and raise an alert.
• Stale cache: Ensure cache TTL matches your plan’s update interval. If TTL is too long, you’ll serve stale prices; too short, you’ll create unnecessary load.
• Mixed timestamps: If Latest and Convert timestamps differ, choose a consistent policy (e.g., use the most recent or enforce synchronized updates) and document it.

Innovation in price discovery and digital integration

Gold (XAU) data has progressed from static bulletin boards to streaming APIs integrated into cloud-native architectures. For Mumbai’s jewelry and manufacturing ecosystems, this means:

• Digital transformation: Real-time INR 18k prices can propagate instantly from trading desks to web stores and factory floors.
• Market insights: Quant teams can layer factor models over OHLC and fluctuation data to explain price dynamics to executives and customers.
• Technology integration: Uniform JSON across metals and currencies streamlines microservice communication and speeds development cycles.
• Innovation in price discovery: Bid/Ask and intraday data support algorithmic pricing policies (e.g., dynamic buffers, volatility-aware markups).
• Digital asset solutions: Fintech apps can update gold-backed balances with precise timestamps, improving NAV accuracy and trust.

Compliance, audit, and reproducibility

• Store source timestamps: Always keep timestamped snapshots of the raw responses you used to generate each published 18k INR price.
• Deterministic transforms: Document the exact functions used for inversion, unit conversion, and purity mapping.
• Immutable history: Persist your daily marks and intraday updates for audits and customer service inquiries.

Next steps

• Explore the full API surface and usage notes in the Metals-API Documentation.
• Verify symbol availability and naming via the Metals-API Supported Symbols directory.
• Get your API key and start integrating today at the Metals-API Website.

Additional resources

• Get a free Metals-API key to prototype your Mumbai 18k pipeline.
• Bureau of Indian Standards (BIS) for hallmarking and karatage references.
• Reserve Bank of India for policy context that can affect INR and gold markets.

Example UI context

Below is a conceptual chart illustration you might include in your app. Note: replace with your own charts and branding.

Conclusion

You can build a reliable, auditable, and fast Mumbai 18k pricing engine in Python using Metals-API by following a simple, testable pipeline: fetch real-time XAU, localize to INR, convert per troy ounce to per gram, and apply 18k purity. From there, upgrade your integration with Bid/Ask spreads for execution-aware quotes, OHLC for intraday analytics, Time-series and Historical Rates for charts and EOD valuation, and Fluctuation for clean move summaries. Preserve timestamps and units end-to-end, cache smartly to match your plan’s update cadence, and expose a single internal pricing service for all consuming apps. Ready to try it? Visit the Metals-API Website and the Metals-API Documentation, and check supported tickers at Metals-API Supported Symbols.

FAQ

• Q: Can I get 18k prices directly instead of converting from 24k?
  A: Yes, if your plan includes the Carat Endpoint. Otherwise, multiply the 24k per-gram price by 0.75 to obtain 18k.
• Q: How do I ensure INR values are accurate historically?
  A: Pair historical XAU with the corresponding historical USD→INR rate for that date. Do not use today’s INR for yesterday’s gold spot.
• Q: What is the unit in Metals-API responses?
  A: Metals are quoted per troy ounce by default. Convert to grams (1 troy ounce = 31.1034768 grams) for Mumbai retail contexts.
• Q: How often should I poll the API?
  A: Match your plan’s update cadence (e.g., every 10 or 60 minutes). Cache in between and refresh asynchronously.
• Q: How do I handle bid/ask vs mid?
  A: Use ask for customer buy quotes and bid for customer sell quotes if you want execution-aware pricing. Midprice is fine for displays but can cause slippage if used for executable quotes.
• Q: Where do I find the official list of supported symbols?
  A: See the Metals-API Supported Symbols page.
• Q: How do I start?
  A: Get an API key at the Metals-API Website, read the Metals-API Documentation, and implement the latest→convert→unit→carat pipeline shown above.