Get Lucknow Gold 22k (LUCK-22k) - Per Gram prices using this API for real-time quotes

If you operate a jewelry storefront, marketplace, or fintech app in Uttar Pradesh, “Lucknow Gold 22k (LUCK-22k) — per gram” is the price that matters for quoting, invoicing, and hedging in real time. In this guide we show exactly how to build a production-grade LUCK-22k per-gram quote from Metals-API data: mapping spot gold to INR, converting troy ounces to grams, adjusting for 22 karat purity, and handling market mechanics like bid/ask spreads, timestamps, caching, and weekend closures. You will leave with a working approach, curl and Python examples, and the operational best practices to ship.

What “LUCK-22k per gram” means and how to derive it from Metals-API

LUCK-22k is a practical, application-level instrument: the retail-trade reference for 22-karat gold per gram in Lucknow, denominated in INR. Metals-API provides the core market inputs you need to construct that quote consistently and transparently:

• Global gold benchmark via the XAU symbol (Gold spot). Metals-API returns exchange rates relative to a base currency and quotes are “per troy ounce.”
• Optional carat-aware data via the Carat endpoint for 22k purity, if enabled in your plan.
• Bid/Ask and OHLC data (depending on plan) to model executable prices and daily ranges.

From there, a deterministic transformation yields LUCK-22k per gram in INR:

1. Select INR as the base currency to remove USD conversion math.
2. Fetch XAU using Metals-API’s latest or bid/ask endpoint. Rates are expressed in “troy ounces of XAU per INR.”
3. Invert to get “INR per troy ounce.”
4. Convert troy ounces to grams (1 troy ounce = 31.1034768 grams).
5. Apply 22-karat purity factor: 22k gold = 22/24 of pure gold by mass ≈ 0.9166667.
6. Optionally apply your business-defined regional fee, making LUCK-22k your display or executable price.

Why not use a city-specific symbol?

Metals-API publishes standardized market symbols. City-specific retail prices (such as for Lucknow) are derived products that typically add tax, logistics, and retail spreads on top of spot or could use the Carat endpoint for purity-aware gold rates. For symbol coverage, visit the up-to-date catalog at Metals-API Supported Symbols. Treat “LUCK-22k” as your application’s SKU mapped from XAU with purity and regional rules.

Endpoints you will use for LUCK-22k

To keep integration tight and production-ready, we focus on three endpoints that matter for this use case. For everything else, see the Metals-API Documentation.

• Latest Rates Endpoint: for real-time spot reference.
• Bid/Ask Endpoint: for executable-style prices and spreads.
• Time-series Endpoint: for charting, regression, and backtesting your Lucknow premium model.

Units, base currency, and purity: the three critical details

• Units: Metals-API quotes XAU “per troy ounce.” You must convert to grams for per-gram retail pricing.
• Base currency: Choose INR for Lucknow workflows. If you use USD base, you’ll add an FX hop.
• Purity: 22k is 22/24 by mass. Multiply the pure-gold per-gram value by 22/24 to get 22k intrinsic value.

1) Latest Rates Endpoint for XAU → LUCK-22k per gram

The Latest endpoint is the simplest way to get current XAU reference. Depending on your plan, updates come every 60 or 10 minutes or faster. Using INR as base reduces FX noise in your code. Below is a complete curl request and a realistic response format.

curl example: Get XAU in INR

curl "https://metals-api.com/api/latest?access_key=YOUR_API_KEY&base=INR&symbols=XAU"

Example JSON response

{
"success": true,
"timestamp": 1789690326,
"base": "INR",
"date": "2026-09-18",
"rates": {
"XAU": 0.00000512
},
"unit": "per troy ounce"
}

How to interpret this:

• rates.XAU is expressed in “troy ounces of XAU per INR.” To get INR per troy ounce, invert it: INR_per_oz = 1 / rates.XAU.
• Convert per ounce to per gram: INR_per_g = INR_per_oz / 31.1034768.
• Apply 22k purity: INR_per_g_22k = INR_per_g × (22 / 24).

Python example: Derive LUCK-22k per gram from the Latest endpoint

import requests

API_KEY = "YOUR_API_KEY"
url = "https://metals-api.com/api/latest"
params = {
"access_key": API_KEY,
"base": "INR",
"symbols": "XAU"
}

resp = requests.get(url, params=params, timeout=10)
data = resp.json()

if not data.get("success"):
raise RuntimeError(f"API error: {data}")

# 1) XAU in troy ounces per INR
xau_per_inr = data["rates"]["XAU"] # ounces per INR

# 2) Invert to get INR per troy ounce
inr_per_oz = 1.0 / xau_per_inr

# 3) Convert to INR per gram
TROY_OUNCE_IN_GRAMS = 31.1034768
inr_per_gram_24k = inr_per_oz / TROY_OUNCE_IN_GRAMS

# 4) Apply 22k purity (22/24)
PURITY_22K = 22.0 / 24.0
inr_per_gram_22k = inr_per_gram_24k * PURITY_22K

# 5) Optional: add regional adjustments for Lucknow (taxes, logistics, margin)
# This is business-specific. For example, add a fixed fee or basis points.
regional_bps = 50 # 0.50% illustrative; replace with your model
lucknow_price_per_gram_22k = inr_per_gram_22k * (1 + regional_bps / 10_000.0)

# Expose in your app as "LUCK-22k"
print({
"instrument": "LUCK-22k",
"base_currency": data["base"],
"date": data["date"],
"timestamp": data["timestamp"],
"price_per_gram_inr": round(lucknow_price_per_gram_22k, 2),
"unit": "per gram (22k)"
})

Fields you will actually use

• base: Your quote currency (INR). Confirms the direction of the rate.
• rates.XAU: Ounces per INR. Invert to get INR per ounce before converting to grams.
• timestamp: Unix epoch for caching and staleness checks. Treat it as UTC.
• date: Calendar date of the rate snapshot. Useful for display and archival indexing.
• unit: Will read “per troy ounce” for XAU; use this as a sanity check in tests.

Beginner gotchas with Latest rates

• Directionality: Metals-API returns metal “per base currency.” Invert to get “price in INR per metal unit.”
• Weight: Convert troy ounces to grams before applying carat. Do not confuse with avoirdupois ounces.
• Purity: Apply the 22/24 factor after unit conversion. Purity is a mass ratio, not a monetary discount.
• Weekends: Expect the same last market rate across Saturday/Sunday; your LUCK-22k output will remain flat unless your business premium changes.
• Caching: Respect timestamp and your plan’s update cadence. Cache until a newer timestamp appears or your SLA requires refresh.

2) Bid/Ask Endpoint for executable-style LUCK-22k

Retail quotes often align closer to the “ask” side when a customer buys from you, and “bid” when you buy from a customer. The Bid/Ask endpoint supports this microstructure. Use it to shape LUCK-22k for actions like “Buy Now” or “We Buy Gold.”

curl example: Get XAU bid/ask in INR

curl "https://metals-api.com/api/bid-ask?access_key=YOUR_API_KEY&base=INR&symbols=XAU"

Example JSON response

{
"success": true,
"timestamp": 1789690326,
"base": "INR",
"date": "2026-09-18",
"rates": {
"XAU": {
"bid": 0.00000510,
"ask": 0.00000514,
"spread": 4.0e-8
}
},
"unit": "per troy ounce"
}

Mapping to per-gram 22k bid/ask:

• INR_per_oz_bid = 1 / bid
• INR_per_oz_ask = 1 / ask
• Then divide both by 31.1034768 and multiply by 22/24.
• Expose “we sell” ≈ ask side; “we buy” ≈ bid side. Add your retail margin as required.

Practical notes:

• Spread sensitivity: On thin days, spreads widen. Your LUCK-22k should reflect this to protect margin.
• Latency: If you maintain a background cache, update bid/ask atomically to avoid crossed markets.
• Auditability: Store the upstream timestamp and endpoint (bid/ask vs latest) with each retail quote for compliance and customer service.

3) Time-series Endpoint for LUCK-22k analytics and charting

To backfill charts or validate your Lucknow regional premium model, use time-series to pull many days of XAU data in a single call, then apply the same transforms you use for live pricing.

curl example: XAU time-series in INR for a week

curl "https://metals-api.com/api/timeseries?access_key=YOUR_API_KEY&base=INR&symbols=XAU&start_date=2026-09-11&end_date=2026-09-18"

Example JSON response

{
"success": true,
"timeseries": true,
"start_date": "2026-09-11",
"end_date": "2026-09-18",
"base": "INR",
"rates": {
"2026-09-11": { "XAU": 0.00000509 },
"2026-09-13": { "XAU": 0.00000513 },
"2026-09-18": { "XAU": 0.00000512 }
},
"unit": "per troy ounce"
}

Transform each daily XAU rate to per-gram 22k exactly as in the Latest flow, then store as LUCK-22k history for:

• Customer-facing price charts (per gram 22k, in INR).
• Backtests for inventory hedging or automated reorder points.
• Volatility-adjusted retail margin rules (e.g., widen margin when 5-day realized vol spikes).

Interpreting fields, timestamps, and units decisively

• timestamp: Unix epoch (UTC). Use to detect staleness and to synchronize caches or downstream job runs.
• date: The ISO date of the snapshot. Useful for keys in data lakes or user-visible labels on charts.
• base: Governs the direction of conversion. With base=INR, “rates.XAU” is ounces per INR.
• unit: It will be “per troy ounce” for XAU. Always confirm this in tests, especially if adding other resources later.
• rates: Either a scalar (Latest, Time-series) or an object with bid/ask (Bid/Ask).

A robust transformation pipeline for LUCK-22k

Implement LUCK-22k as a pure function that consumes a Metals-API payload and yields a per-gram 22k INR number. This makes it testable and auditable.

1. Validation: Assert success == true; assert unit == “per troy ounce”; assert base == “INR”.
2. Direction check: Ensure rates.XAU is present and positive.
3. Invert: INR_per_oz = 1 / rates.XAU (or use bid/ask accordingly).
4. Unit convert: INR_per_g_24k = INR_per_oz / 31.1034768.
5. Purity: INR_per_g_22k = INR_per_g_24k × 22/24.
6. Regional: Apply Lucknow adjustments (taxes, logistics, branch margin) per your policy.
7. Output: instrument=“LUCK-22k”, unit=“per gram (22k)”, currency=INR, timestamp, source endpoint.

Caching, rate strategy, and weekend behavior

• Cache by symbol-base and endpoint: e.g., cache keys like latest:INR:XAU and bidask:INR:XAU.
• Honor the timestamp: If Metals-API updates every 10 minutes on your plan, don’t thrash the endpoint more often unless your SLA demands it.
• Weekend/holidays: Expect flat timestamps; show “last updated at” in UI to avoid confusion.
• Fallback hierarchy: If bid/ask temporarily fails, fall back to latest, then the most recent cached rate within a timebox that matches your risk policy.

Error handling and resilience

• Check the “success” flag and handle structured errors. Fallback to cache or show a “price updating” badge with last good timestamp.
• Timeouts: Use short upstream timeouts and circuit breakers to keep your storefront responsive.
• Input sanitization: Whitelist symbols and bases you actually use (XAU, INR).
• Observability: Log endpoint, base, symbol, timestamp, and transformation steps for each quote.

Security and key management

• Keep your access_key server-side. Never embed it in client apps.
• Rotate keys periodically. Gate internal price feeds behind auth.
• Rate-limit internally to prevent accidental bursts from roller UIs or cron overlaps.

Carat endpoint vs. manual purity math

If your plan includes the Carat endpoint, you can request gold rates by carat directly and skip purity math. This can standardize outputs for retail workflows. If you prefer transparency and control, keep the manual 22/24 conversion in your pipeline. Both approaches are valid; choose the one that aligns with your governance and audit needs. For details on parameters and availability by plan, see the Metals-API Documentation.

Practical UI and UX tips for a Lucknow storefront

• Show “INR per gram (22k)” prominently; hide troy ounce internals from customers.
• Display “Last updated: HH:MM IST (from Metals-API)” with the epoch converted to local time.
• If using bid/ask, label “We sell” and “We buy” to reflect executable context.
• If inventory updates trail live rates, show a banner: “Prices update every 10 minutes.”

Architecture: From Metals-API to production LUCK-22k

• Upstream: Metals-API calls from a stateless backend service (Node, Python, Go, etc.).
• Cache: Memory with TTL keyed by symbol-base-endpoint; optionally Redis for multi-node scale.
• Transform: Idempotent function for XAU→22k per gram. Package as a shared module across services.
• Distribution: GraphQL/REST endpoint that exposes “instrument=LUCK-22k” for frontends and partners.
• Audit store: Append-only log with upstream payload, your output, and parameters (purity, fees).

Testing: Make the math boring

• Golden data fixtures: Save sample Metals-API JSON and assert the exact INR/gram results at 22k.
• Edge cases: Zero or missing XAU; weekend same-timestamp; bid > ask (reject); negative rates (reject).
• Rounding: Decide your display precision (e.g., 2 decimals) and keep internal math at double precision.

Compliance and transparency

• Provenance: Disclose “Gold price data from Metals-API” on receipts and terms.
• Reproducibility: Given a timestamp and your margin rules, you should be able to regenerate any displayed price.

Key references and where to get help

• Get your API key and start integrating: Metals-API Website
• Parameters, endpoints, and plan features: Metals-API Documentation
• Check available symbols and metadata: Metals-API Supported Symbols
• Additional context on gold benchmarks and pricing mechanics: LBMA Prices and Data (for background only; integrate via Metals-API for your app)

End-to-end example: Building a Lucknow product card

Suppose your product service fetches INR-based XAU bid/ask every 10 minutes and caches it for 9 minutes. Your storefront calls your internal “/prices/LUCK-22k” endpoint, and you respond with:

{
"instrument": "LUCK-22k",
"base_currency": "INR",
"unit": "per gram (22k)",
"timestamp_utc": 1789690326,
"source_endpoint": "bid-ask",
"buy_from_us": 6460.75,
"sell_to_us": 6338.30,
"last_updated_local": "2026-09-18T16:05:26+05:30",
"notes": "Derived from XAU bid/ask via Metals-API; includes 0.50% local adj."
}

That payload is minimal, auditable, and useful to a React or Flutter front end without exposing any upstream key. You can add optional fields like “spot_reference_24k_per_gram” or “regional_adjustment_bps” if you want customers to see how the number is built.

Performance tips

• Batching: If you price multiple karats (18k, 20k, 22k), fetch once and transform locally.
• Warmup: On cold start, prefetch the latest before serving traffic to avoid blocking first render.
• SLO-aware refresh: Refresh more aggressively when you detect large intraday moves; otherwise rely on TTL.

Common pitfalls to avoid

• Mixing ounce systems: Always use troy ounces for precious metals. 1 troy ounce = 31.1034768 grams.
• Forgetting inversion: rates.XAU is ounces per INR; you must invert to get INR per ounce.
• Double-applying purity: Only apply 22/24 once, after converting to grams.
• Ignoring timestamps: Don’t assume “now.” Surface last update time clearly.

Innovation themes: Turning gold data into digital products

Gold (XAU) is a centuries-old asset, but digital transformation is reshaping how it’s quoted, sold, and hedged. With Metals-API, you can embed real-time price discovery into e-commerce carts, mobile apps for jewelers, and ERP reorder flows. Data analytics—from time-series volatility to carat-specific demand trends—can inform dynamic margins, promotional timing, and omnichannel inventory balancing. Integrations with your CRM and checkout stack turn price intelligence into conversion lift and tighter risk control, enabling next-generation retail experiences without sacrificing rigor.

Get started

Spin up your first LUCK-22k quote in under an hour:

1. Sign up and get a free API key at the Metals-API Website.
2. Check symbol coverage and metadata on the Supported Symbols page.
3. Implement the Latest and Bid/Ask flows using the API Documentation, then wire up the 22k-per-gram transformation.

FAQ

Does Metals-API provide a “LUCK-22k” symbol directly?
No. Treat LUCK-22k as your internal instrument derived from XAU using INR base, troy-ounce-to-gram conversion, 22/24 purity, and any regional adjustments. Check available upstream symbols at the Metals-API Supported Symbols.

Which endpoint should I rely on for retail pricing?
Use Bid/Ask if you want executable-style quotes; use Latest for a single reference price. Both can power LUCK-22k; pick the one that matches your business logic.

How often do rates update?
Update frequency depends on your plan tier. Always rely on the returned timestamp to manage cache and UI freshness. See details in the Metals-API Documentation.

How do I handle weekends and holidays?
Expect no new timestamps during closures. Keep your last good quote, show “Last updated,” and resume when new data arrives.

Can I skip purity math using the Carat endpoint?
If your plan includes the Carat endpoint, you may request gold rates by carat. Otherwise, compute 22k via 22/24 after converting to grams.

Is the API response in local time?
Timestamps are UTC. Convert to IST (or user locale) for display. Store UTC for audit consistency.

Where do I get an API key?
Register at the Metals-API Website to get a free API key and start integrating today.