Access Saudi Riyal (SAR) Exchange Rates in JSON Format — using a REST API endpoint and query examples

When you need Saudi Riyal (SAR) exchange rates in JSON to power an e-commerce price in Riyals, reconcile a commodities P&L, or convert a metal quote into local currency for a Saudi customer, Metals-API gives you straightforward endpoints and predictable payloads that you can integrate in minutes. In this guide, we’ll walk through obtaining SAR-denominated rates, converting metal prices to SAR, and using historical, fluctuation, and OHLC datasets to build charts, alerts, and risk dashboards—all via a simple REST API returning JSON.

Why SAR exchange rates matter in commodity and fintech workflows

Developers and product teams working in Saudi markets frequently need to:

• Price jewelry SKUs in SAR while sourcing raw metals in USD.
• Mark-to-market hedges on precious or industrial metals with SAR reporting currency.
• Provide real-time checkout conversions from USD-based spot metals to final SAR amounts.
• Standardize ERP costs and manufacturing inputs (e.g., copper, aluminum) to SAR for local ledger compliance.
• Surface analytics for day-over-day currency fluctuation impacts on BOM costs and invoice settlements.

Metals-API addresses these needs by returning metal and currency rates in compact JSON across endpoints for latest, historical, time-series, fluctuation, conversion, OHLC, bid/ask, intraday (where available), and more. Begin with the Metals-API Website to explore plans and features, then consult the Metals-API Documentation for full request and response details. To verify availability of SAR and metal tickers, see the live Metals-API Supported Symbols.

SAR exchange rates in JSON: the core workflow

At a high level, your integration will:

1. Request exchange rates with SAR included in the symbols list, or specify SAR as the base currency, depending on your calculation direction.
2. Use conversion and time-series endpoints to translate between currencies (USD, SAR) and metal symbols (e.g., XAU, XAG, XCU).
3. Normalize units (e.g., troy ounce to grams) so your upstream pricing logic stays consistent for SKUs and BOMs.
4. Cache results to minimize API calls and latency, accounting for update frequencies and market closure rules.
5. Handle failures gracefully with retry logic and use historical endpoints for backfilling missing data.

Important implementation notes up front

• Base currency: By default, API responses are relative to USD. If you require SAR as the reporting currency, use base or conversion workflows accordingly.
• Units: Precious metals are per troy ounce by default in responses. Convert to grams or kilograms where needed for product math.
• Timestamps and timezone: Use the timestamp field and date string in responses to anchor time. Normalize to UTC in storage/analytics.
• Weekends/closures: Metals and FX liquidity vary by day/time. Use historical data to fill gaps and avoid assuming a linear intraday feed on closed markets.
• Symbols: Always validate symbols against the live list. SAR is typically available as a currency code; metals use X-prefix ISO codes (e.g., XAU, XAG).

Quick start: request SAR along with metals

To incorporate Riyal exchange rates into your metals workflow, request the latest rates with SAR in your symbol filter. This lets you compute cross rates (e.g., USD → SAR) and marry them with metal quotations in the same response cycle.

Sample curl request for latest rates including SAR

The following example demonstrates the structure of a request that includes SAR. Replace YOUR_KEY with your actual access key from the Metals-API Website (sign up to get a free API key):

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

While the exact numeric values in the payload will vary with market conditions and your plan’s update frequency, your application will parse the JSON fields described below. For a realistic metals-only example payload (format and fields), refer to this sample returned by the Latest Rates endpoint:

{
"success": true,
"timestamp": 1789435136,
"base": "USD",
"date": "2026-09-15",
"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"
}

Key fields to use:

• success: Boolean to confirm a valid result.
• timestamp: Unix epoch for the data snapshot; use for versioning and time alignment.
• base: Defaults to USD; affects interpretation of rate values.
• date: Human-readable date corresponding to the snapshot.
• rates: Map of symbol to rate. With SAR included, parse rates.SAR for the currency cross; for metals, use symbols like XAU, XAG.
• unit: For metals, signals “per troy ounce,” essential for any weight conversion you perform after retrieval.

Minimal JavaScript fetch example for SAR conversion

This JavaScript snippet demonstrates calling the Convert endpoint to turn a USD amount into a metal unit or currency. Replace YOUR_KEY with your key. This is a simple pattern you can adapt for USD↔SAR or XAU↔SAR conversions depending on your base.

// Example: Convert an amount from USD to XAU (structure identical for SAR conversions)
async function convertAmount(from, to, amount) {
const url = `https://metals-api.com/api/convert?access_key=YOUR_KEY&from=${encodeURIComponent(from)}&to=${encodeURIComponent(to)}&amount=${encodeURIComponent(amount)}`;
const res = await fetch(url);
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const data = await res.json();
if (!data.success) throw new Error("API error: " + JSON.stringify(data));
// data.result will contain the converted amount; data.info.rate is the applied rate
return data;
}

// Example invocation:
// convertAmount("USD", "SAR", 1000) - convert USD to SAR
// convertAmount("XAU", "SAR", 1.5) - convert 1.5 troy ounces of gold to SAR value

Typical Convert response structure (metals example):

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

Fields to use:

• query: Echoes your input; persist for audit trails.
• info.rate: Applied rate for the conversion; store if you need to reconcile later.
• result: Converted quantity. When “to” is a currency (e.g., SAR), this will be a monetary value; when “to” is a metal symbol (e.g., XAU), this will be a number of troy ounces.
• unit: Confirms if the result is given in monetary terms or metal units; for metals, expect “troy ounces.”

Deep dive: building SAR-denominated pricing and analytics

SAR integration patterns commonly fall into three categories:

1. USD base with SAR as a reporting currency: Pull USD-based metal rates and an FX cross (USD→SAR) and compute SAR values in your application layer.
2. SAR base pricing: Request rates with base=SAR so metal rates are already expressed relative to Riyals.
3. Direct conversions with Convert: Invoke Convert to transform arbitrary amounts between USD, SAR, and metals, which is useful in checkout flows or ERP integrations.

Pattern 1: USD base + SAR cross for flexible analytics

Pros:

• Consistent internal unit pricing anchored to USD, which is common for metals.
• Easy to pivot to other currencies (AED, EUR, etc.) using the same internal logic.

Considerations:

• Ensure atomicity: fetch metal quotes and SAR cross in the same polling cycle to avoid mismatches.
• Backfill gaps with historical endpoints to avoid missing points in charts.

Pattern 2: SAR base for direct customer pricing

Pros:

• Reduces per-transaction math. Prices are already in SAR terms.
• Decreases rounding errors and simplifies price displays and invoicing.

Considerations:

• Switching bases may change your exposure modeling; maintain a documented conversion policy.
• Cache base=SAR responses thoughtfully to match your UI refresh cadence.

Pattern 3: Conversion endpoint for transactional use cases

Pros:

• Explicit, auditable conversion operation tied to a single timestamp and rate.
• Ideal for checkout, invoice, and back-office calculations.

Considerations:

• Use idempotency at your application tier to prevent duplicate charges/orders if retries occur.
• Persist the info.rate with transaction records for future reconciliation.

Historical rates and time-series for SAR reporting

Metals-API includes historical endpoints to retrieve specific dates and time-series windows. Use them for chart backfills, performance reporting, and to compute realized and unrealized FX and metal P&L in SAR.

Historical rates (single date)

Pull a snapshot from a prior date to recompute valuations or audit changes. Payload format (metals example):

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

How to use for SAR:

• Request historical date with symbols including SAR to derive USD↔SAR for that date.
• Recompute SKU values or inventory marks as-of the business day of interest.

Time-series (multi-day windows)

Extract spans for backtesting, exposure analysis, or charts. Example format:

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

With SAR included in symbols and/or with base=SAR, you can compute:

• Daily SAR price trajectories for each metal.
• Volatility and drawdowns for risk models.
• Aggregations like monthly averages or weighted costs for BOM rollups.

Fluctuation endpoint (change over a range)

For dashboards and alerting, use fluctuation to get net change and percent change between two dates in one call:

{
"success": true,
"fluctuation": true,
"start_date": "2026-09-08",
"end_date": "2026-09-15",
"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"
}

Apply the same pattern with SAR in the symbols list or with base=SAR to present localized performance. For example, show “Gold fell 0.62% in SAR terms this week.”

Intraday, OHLC, and Bid/Ask for trading systems

For trading or analytics that need higher frequency perspective, Metals-API includes intraday, OHLC, and bid/ask data (availability may depend on subscription tier).

OHLC for daily bars

{
"success": true,
"timestamp": 1789435136,
"base": "USD",
"date": "2026-09-15",
"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"
}

Use base=SAR to get OHLC in Riyal terms for end-of-day calculations, or combine USD metal OHLC with SAR FX for derived OHLC series in your application.

Bid/Ask for trading spreads

{
"success": true,
"timestamp": 1789435136,
"base": "USD",
"date": "2026-09-15",
"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"
}

When quoting to customers in SAR, use bid/ask appropriately to avoid quoting at mid if your business model requires spread coverage. Convert the side you’re quoting through SAR using the Convert endpoint or by applying the SAR cross to USD-based quotes.

Intraday and data freshness

The intraday endpoint targets single-symbol high-frequency snapshots (subject to plan update intervals). When displaying intraday charts or providing “tick” indicators, cache intraday responses aggressively and merge them with daily OHLC for stability. Remember to check the timestamp and surface data freshness in your UI (e.g., “updated 3 minutes ago”).

LME historical data for industrial planning

For long-run procurement analysis of industrial metals linked to LME benchmarks, use the historical LME endpoint (availability and instruments vary). Obtain multi-year data series (dating back to 2008 per the capability description) to estimate long-term SAR-denominated cost curves and to set strategic hedging triggers. Combine with the time-series endpoint for rolling metrics and trend detection.

Data modeling: units, weights, and conversions

Metals-API reports precious metal rates per troy ounce by default. Common conversions you may need:

• Troy ounce to gram: 1 troy oz = 31.1034768 grams.
• Troy ounce to kilogram: 1 troy oz ≈ 0.0311034768 kg.
• Carat-specific gold pricing: If you price jewelry by carat, use the Carat endpoint to request rates by carat, then convert to SAR.

Example flow for SAR-priced jewelry SKU:

1. Request carat-specific gold rate or XAU base rate.
2. Convert per troy ounce to per gram using the factor above.
3. Apply making charges, VAT, and margins.
4. Convert the USD-based figure to SAR using Convert or by applying the USD→SAR rate retrieved alongside the metal rate.

Carat endpoint for gold retail pricing in SAR

If you sell gold jewelry in Saudi Arabia, quoting by carat streamlines UX and internal math. The Carat endpoint returns gold rates by carat; append your preferred base (consider SAR for immediate localization) and calculate SKU prices accordingly. Use consistent rounding rules for checkout and display fidelity. Always store the timestamp and applied rate for later audit.

Designing robust SAR integrations: performance and reliability

Caching strategies

• Edge cache by (endpoint, base, symbols, date window). Respect update intervals to avoid stale quotes while minimizing calls.
• Separate caches for “latest” vs “historical.” Historical responses are immutable; cache with long TTL.
• Use local in-memory cache (e.g., LRU) for hot symbols (SAR, XAU, XAG) and a persistent cache (Redis) for broader symbol sets.

Batching and field selection

• Request only needed symbols (e.g., SAR plus the metals you actually quote) to reduce payload size.
• Consolidate requests by coordinating polling intervals among services that share rate data.

Retries and backoff

• Retry on network timeouts or 5xx with exponential backoff and jitter.
• Don’t retry on 4xx without changing input; log and surface validation errors.

Weekend and holiday handling

• Expect fewer or no updates on weekends/holidays; UI should label “last updated” timestamp prominently.
• For charts, use the time-series endpoint to fill business days only and avoid plotting flat weekends if irrelevant to your users.

Security and compliance

• API key handling: Store keys server-side only; never expose them in client apps or public repos. Use environment variables and secrets managers.
• Rate governance: Implement quotas and alerts at your gateway to avoid soft outages from unexpected spikes.
• Data integrity: Validate symbols against the Metals-API Supported Symbols on deploy and periodically at runtime to catch list updates.
• Audit: Persist raw response snapshots (timestamp, base, symbols, rates) with checksums for financial reconciliation and dispute resolution.

Error handling and troubleshooting

Common pitfalls

• Mismatch between base currency and in-app assumptions: Always read base and document your conversion chain.
• Unit confusion: “per troy ounce” vs “per gram” is a frequent source of pricing errors; centralize conversion utilities.
• Symbol typos: Validate SAR and metal symbols; treat any unknown symbol as a hard error.

Detecting and responding to errors

• Check success boolean before using payload.
• Log both HTTP status and body; errors often include diagnostic fields.
• Fallback to last-known-good rates for read paths if your risk policy permits; tag outputs as “stale.”

Designing analytics and dashboards in SAR

For data teams, the combination of time-series, fluctuation, and OHLC supports robust analytics. Typical metrics:

• Rolling volatility (e.g., 20D, 60D) of SAR-denominated metal prices.
• Drawdowns and recovery times.
• Correlation matrices among metals and SAR FX to inform hedging.
• Cost index for BOMs normalized to SAR by category (precious vs industrial).

Architect your pipeline to compute these metrics incrementally as new latest/ intraday data arrives, backstopping with historical endpoints during restarts.

Working example: seamless SAR checkout for gold products

1. Server cron fetches latest with symbols: XAU and SAR (base=USD). Cache for 1–10 minutes depending on plan frequency and UX requirements.
2. Convert spot per troy ounce XAU to per gram for SKU weight math.
3. Add making charges, VAT, and margin to compute pre-conversion unit price in USD or directly compute in SAR using base=SAR.
4. Expose to frontend via a read-only endpoint serving only the computed price, never your Metals-API key.
5. At purchase, call Convert to lock price in SAR and persist info.rate and timestamp with the order.

Neodymium (ND) and digital transformation in industrial supply chains

Neodymium (often referenced in green tech for high-performance magnets) exemplifies how real-time metals data and analytics transform planning. With increased EV and wind turbine demand, ND pricing feeds into advanced procurement and risk systems:

• Technological innovation: Integrate ND price signals into IoT-enabled inventory systems to trigger SAR-denominated reorder thresholds.
• Data analytics: Model ND cost sensitivity in SAR across scenarios using the time-series and fluctuation endpoints.
• Smart technology integration: Embed ND price widgets in manufacturing MES dashboards for on-the-floor awareness of cost dynamics.
• Future trends: Use historical LME proxies and OHLC structures to forecast volatility regimes, informing SAR hedging strategies.

This end-to-end digitization—from Metals-API ingestion to SAR-normalized analytics—lets industrial firms act decisively amid volatile rare earth markets.

Advanced integration techniques

Server-side composition patterns

• Aggregator service: Centralize all Metals-API calls into a single internal microservice that exposes normalized SAR-priced data to downstream consumers.
• Event streaming: Publish new rates to a message bus (e.g., Kafka) tagged with timestamp, base, and symbols for consumers to subscribe by instrument.
• Materialized views: Precompute SAR conversions for hot paths (XAU, XAG, XPT) and persist in a low-latency store for UIs.

Data quality safeguards

• Outlier detection: Flag rates deviating by N standard deviations from rolling means to catch upstream anomalies.
• Dual-source checks: Optionally compare headline FX crosses (e.g., USD/SAR) with a secondary reference for monitoring only. Do not mix sources for official pricing to prevent inconsistencies.
• Versioning: Include timestamp and a hash of the response in your records to reproduce historical computations.

Performance tuning

• Minimize symbol lists to reduce payload size and processing time.
• Exploit immutable historical responses with very long TTL caches.
• Align polling to your subscription’s update cadence to avoid redundant calls.

Comprehensive examples: interpreting JSON fields that matter

Latest rates JSON: what to persist and why

• timestamp: Use for de-duplication; store as bigint.
• base: Critical for transformations; store alongside data.
• rates: Persist as a sparse map keyed by symbol; consider columnar storage for analytics.
• unit: Needed to determine downstream conversions (troy ounce to grams).

Time-series JSON: building SAR charts

• start_date, end_date: Document the range requested; keep for chart provenance.
• rates[date][symbol]: Parse into a time-indexed structure; avoid floating-point drift by using decimals in your storage where applicable.

Fluctuation JSON: powering alerts

• change_pct: Primary field for thresholds (e.g., alert me if XAU in SAR moves more than 1% day-over-day).
• start_rate, end_rate: Display alongside alert details for transparency.

OHLC JSON: candlestick construction

• open/high/low/close: Use directly in chart libraries; label base and unit explicitly in legends.
• date: Anchor EOD bars to your reporting timezone; UTC storage recommended.

Bid/Ask JSON: transaction quoting

• bid, ask, spread: Store both sides if you need P&L that reflects the side you transacted on.
• Combine with SAR conversion logic for customer-facing quotes in Riyals.

Authentication, quotas, and governance

• Authentication: Pass your access key as the access_key parameter in the query string. Keep keys server-side and rotate periodically.
• Quota management: Centralize API calls in a gateway. Implement request budgeting per service to prevent noisy neighbor issues.
• Observability: Instrument calls with metrics (latency, error rate, cache hit rate) and traces. Alert when freshness exceeds thresholds.

Full request/response gallery for reference

Latest rates (metals example)

{
"success": true,
"timestamp": 1789435136,
"base": "USD",
"date": "2026-09-15",
"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"
}

Historical (single day, metals example)

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

Time-series (metals example)

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

Fluctuation (metals example)

{
"success": true,
"fluctuation": true,
"start_date": "2026-09-08",
"end_date": "2026-09-15",
"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"
}

OHLC (metals example)

{
"success": true,
"timestamp": 1789435136,
"base": "USD",
"date": "2026-09-15",
"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"
}

Bid/Ask (metals example)

{
"success": true,
"timestamp": 1789435136,
"base": "USD",
"date": "2026-09-15",
"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"
}

Validation and sanitization

• Input sanitize: Whitelist symbols (including SAR and metals) from the official list; reject unknowns early.
• Numeric handling: Prefer decimal libraries for currency math; avoid binary float rounding for finance-grade totals.
• Date validation: Enforce ISO date strings, ensure start_date ≤ end_date, and align with your business calendar.

Observability and SLOs

• Freshness SLO: e.g., 95th percentile “latest” age <= 3 minutes (depending on plan). Expose a freshness badge in your UI.
• Latency SLO: Track p50/p95 per endpoint; pre-warm caches for high-traffic intervals.
• Error budgets: Define acceptable error rates and automatic fallbacks (cached data or “data delayed” labels).

Where to find what you need

• Capabilities overview, plans, and features: Metals-API Website
• Endpoint behaviors, parameters, and examples: Metals-API Documentation
• Symbols and codes for metals and currencies (including SAR): Metals-API Supported Symbols

Additional reference resources for SAR context and monetary policy updates include the Saudi Central Bank (SAMA) and cross-border transaction compliance references from Bank for International Settlements.

Action plan: go live with SAR in hours

1. Create your key at the Metals-API Website and start with a free tier to prototype.
2. Validate SAR and your target metals on the Supported Symbols page.
3. Build a server-side fetcher for latest + fluctuation, request SAR and the metals you need, and implement a short-term cache.
4. Add Convert for transactional operations to lock in SAR values per order.
5. Backfill charts and reports with historical and time-series endpoints.
6. Instrument monitoring, add retries with backoff, and publish price freshness to your UI.

Ready to integrate SAR exchange rates and metals data? Visit the Metals-API Website and get your free API key to start building today. For endpoint specifics and advanced features, the Metals-API Documentation has end-to-end details.

FAQ

Can I receive all quotes directly in SAR?

Yes. Request with base=SAR to have metals priced relative to SAR. Alternatively, keep USD as base for internal consistency and convert to SAR on the fly.

How often are rates updated?

Update cadence depends on your subscription plan. The latest endpoint is updated at intervals such as every 60 or 10 minutes depending on plan level. Always check timestamp for freshness.

How do I handle weekends and holidays?

Expect reduced or no updates on closures. Use historical data for previous business day values and label the UI with an accurate “last updated” timestamp.

Which symbols should I use?

Use SAR for Saudi Riyal, and metal symbols like XAU (gold), XAG (silver), XPT (platinum), XPD (palladium), XCU (copper), XAL (aluminum), XNI (nickel), XZN (zinc). Confirm availability on the Metals-API Supported Symbols page.

What unit are metal prices returned in?

By default, metal rates are per troy ounce. Convert to grams or kilograms if needed for your products or BOMs.

Can I get bid/ask and OHLC in SAR?

Yes. Either set base=SAR or combine USD-based bid/ask or OHLC with the SAR FX rate to derive SAR-denominated series.

How do I secure my API key?

Store keys on the server side, use env vars or a secrets manager, and never expose your key to browsers or mobile apps. Rotate keys periodically.

What’s the best way to minimize API calls?

Cache immutable historical responses with long TTL, align latest polling to your plan’s update frequency, and fetch only the symbols you need (e.g., SAR and your target metals).

How do I audit an order priced in SAR?

Persist the Convert response including info.rate and timestamp. Store input parameters (from, to, amount) along with your final price and any fees.