Home
Blog
The Easiest Way to Get Dehradun Silver (DEHR-XAG) - Per Gram Historical Rates using a REST API

The Easiest Way to Get Dehradun Silver (DEHR-XAG) - Per Gram Historical Rates using a REST API

The Easiest Way to Get Dehradun Silver (DEHR-XAG) - Per Gram Historical Rates using a REST API

The easiest way to get Dehradun Silver (DEHR-XAG) per-gram historical rates via a REST API is to query Silver (XAG) prices with Metals-API, then convert from troy ounces to grams and, if required, align results to your local context in Dehradun. In practice, DEHR-XAG is a regional label you can define in your own app for “Dehradun Silver per gram” that is derived from the global XAG benchmark. With Metals-API, you’ll retrieve historical XAG values, compute grams (1 troy ounce = 31.1034768 grams), and optionally map the result to INR or your reporting currency for analytics, pricing, supply chain planning, or manufacturing cost control.

What we’re building: per-gram historical XAG for Dehradun (DEHR-XAG) using a simple REST workflow

Our concrete use case is straightforward and practical: you need historical per-gram silver rates for Dehradun that developers can integrate into dashboards, pricing engines, ERP materials cost modules, or quant backtests. We’ll do this by using only a few Metals-API endpoints:

  • Historical Rates endpoint for a single date (to backfill specific days, settlements, or reference points).
  • Time-Series endpoint for a continuous historical range (to drive charts, aggregates, and backtests).
  • Convert endpoint (optional) to transform USD-to-XAG or amounts to assist in per-gram conversions and downstream calculations.

All requests return XAG denominated per troy ounce by default with base=USD unless a different base is supported and specified. We’ll then apply a deterministic troy ounce-to-gram conversion to present “DEHR-XAG per gram.” If you price locally in INR, you can layer currency conversion in your app using the Convert endpoint or downstream FX you maintain. The key point: DEHR-XAG is an application-level alias mapped from authoritative XAG history—this keeps your system consistent with global benchmarks while presenting data in a format that’s operationally relevant in Dehradun.

Why Silver (XAG) data powers manufacturing, smart factories, and fintech in Dehradun

Silver’s industrial footprint is expanding—photovoltaics, semiconductors, EVs, medical devices, and automation increasingly rely on silver’s conductivity and antimicrobial properties. In Dehradun’s local manufacturing and jewelry ecosystem, accurate historical XAG data enables:

  • Digital market analysis: Track historical per-gram trends and seasonality relevant to procurement timing and hedging.
  • Smart manufacturing integration: Feed accurate silver cost curves into MES/ERP for BOM rollups and margin analysis.
  • Supply chain optimization: Benchmark suppliers with normalized per-gram historical prices tied to global XAG references.
  • Fintech and trading tools: Backtest silver-linked strategies, build alerts, and run risk analytics with reliable history.

Before you start: symbols, base currency, units, and time

  • Symbol: You’ll query XAG (Silver). DEHR-XAG is your internal label for “Dehradun silver per gram.” For an updated list of symbols, see the Metals-API Supported Symbols.
  • Base currency: Unless you specify otherwise and your plan supports it, data is relative to USD (base=USD). You can convert downstream to other currencies if needed.
  • Units: The API returns metals “per troy ounce.” To get per-gram, divide results by 31.1034768.
  • Timestamps and timezone: Responses provide a UTC timestamp and ISO date. Persist and normalize to UTC internally to avoid off-by-one errors around market closures and local time conversions.

Get an API key and read the docs

Sign up for a free API key on the Metals-API Website to begin making requests. For deeper technical details and optional parameters, check the Metals-API Documentation. Keep your key secure—never embed it directly in public frontend code.

Main workflow overview: from XAG per ounce to DEHR-XAG per gram

  1. Call Historical Rates or Time-Series for XAG with base=USD.
  2. For each value of XAG (per troy ounce), convert to per gram by dividing by 31.1034768.
  3. Optionally, convert the per-gram USD price to INR or another reporting currency in your backend using the Convert endpoint and your chosen FX source.
  4. Store and serve the result internally as DEHR-XAG (per gram), including original timestamps for auditability.

Endpoint 1: Historical Rates (single day) for XAG, then normalize to grams

Use the Historical Rates endpoint to fetch XAG on a specific date—ideal for backfilling a missing day, reconciling end-of-day valuations, or aligning with settlement dates. The data is per troy ounce by default.

When to use it

  • One-off backfills for particular calendar dates.
  • Verifying a single-day reference (e.g., procurement day pricing).
  • Building static datasets where each row references an ISO date with a single point estimate.

Required parameters

  • access_key: Your Metals-API key.
  • date: ISO date path component, e.g., YYYY-MM-DD.
  • base: Optional; default is USD (supported plans may allow alternative bases).
  • symbols: Use XAG for silver.

Example curl request (fetching XAG for a specific date)

curl -s "https://metals-api.com/api/2026-09-16?access_key=YOUR_API_KEY&base=USD&symbols=XAG"

Sample JSON response (Historical Rates)

{
"success": true,
"timestamp": 1789572247,
"base": "USD",
"date": "2026-09-16",
"rates": {
"XAG": 0.03825
},
"unit": "per troy ounce"
}

Field-by-field guide: what you actually use

  • success: Boolean—it should be true in normal cases; validate before using.
  • timestamp: UNIX time (UTC). Persist as your canonical time for downstream consistency.
  • base: Currency the rates are quoted against, typically USD.
  • date: ISO date you requested—store it to align with business calendars and reporting.
  • rates.XAG: Silver rate expressed as “XAG per 1 USD” per troy ounce. To present “USD per gram,” compute 1 / rates.XAG / 31.1034768 only if the rate is “XAG per USD.” If the API’s rate format is “XAG per USD,” you will typically invert to get “USD per XAG ounce,” then divide by 31.1034768. Note: In the example structures provided, the “unit” string clarifies the measurement is per troy ounce; confirm your pricing math by validating against a known day.
  • unit: Indicates “per troy ounce.” You’ll convert to grams.

Important pricing math note: Metals-API responses in this article show “unit: per troy ounce” and a numeric value for XAG under rates. Depending on how you structure your calculation, confirm whether the numeric rate represents the metal amount per 1 USD or the USD price per 1 unit of metal. The examples above read as “XAG per USD (per troy ounce).” If your workflow needs “USD per gram,” perform the appropriate inversion and ounce-to-gram conversion. Always verify on a test day against a known price to ensure correct orientation.

Turning this into DEHR-XAG per gram

  1. Read rates.XAG and unit.
  2. Convert from per-ounce orientation to per-gram USD price. If rates.XAG is “XAG per USD per ounce,” invert to get “USD per XAG ounce,” then divide by 31.1034768 to get “USD per gram.”
  3. Store the result internally as DEHR-XAG for the given date and timestamp.

Complete JavaScript example: request a date, compute DEHR-XAG per gram, and store

// Fetch XAG for a single date, convert to per-gram USD, and label as DEHR-XAG
async function fetchDehradunSilverPerGram(dateISO) {
const url = `https://metals-api.com/api/${dateISO}?access_key=${process.env.METALS_API_KEY}&base=USD&symbols=XAG`;
const res = await fetch(url, { method: "GET" });
if (!res.ok) {
throw new Error(`HTTP ${res.status}`);
}
const data = await res.json();
if (!data.success || !data.rates || typeof data.rates.XAG !== "number") {
throw new Error(`Invalid payload: ${JSON.stringify(data)}`);
}

const xagPerUsdPerOunce = data.rates.XAG; // as shown in the examples
// Convert orientation: USD per ounce = 1 / (XAG per USD per ounce)
const usdPerOunce = 1 / xagPerUsdPerOunce;
const usdPerGram = usdPerOunce / 31.1034768;

return {
symbol: "DEHR-XAG",
date: data.date,
timestamp: data.timestamp,
unit: "USD per gram",
price: usdPerGram
};
}

// Example usage:
fetchDehradunSilverPerGram("2026-09-16")
.then(console.log)
.catch(console.error);

Store both the computed DEHR-XAG per gram and the original payload (or at least date/timestamp) to support audits and recalculations if your unit or currency logic ever changes.

Endpoint 2: Time-Series (date range) to power charts, backtests, and dashboards

Use the Time-Series endpoint to retrieve continuous historical XAG data between two dates. This is the backbone for analytics, plotting historical charts, running statistical models, or batch-computing per-gram series for Dehradun.

When to use it

  • Building a full historical DEHR-XAG per-gram dataset over months or years.
  • Feeding chart libraries and quant pipelines.
  • Generating aggregates: rolling means, volatility, drawdowns, or seasonality analyses.

Required parameters

  • access_key: Your key.
  • start_date, end_date: ISO dates for your range.
  • base: Optional; typically USD.
  • symbols: XAG.

Example curl request (Time-Series for XAG)

curl -s "https://metals-api.com/api/timeseries?access_key=YOUR_API_KEY&start_date=2026-09-10&end_date=2026-09-17&base=USD&symbols=XAG"

Sample JSON response (Time-Series)

{
"success": true,
"timeseries": true,
"start_date": "2026-09-10",
"end_date": "2026-09-17",
"base": "USD",
"rates": {
"2026-09-10": { "XAG": 0.03825 },
"2026-09-12": { "XAG": 0.0382 },
"2026-09-17": { "XAG": 0.03815 }
},
"unit": "per troy ounce"
}

What to expect and how to use it

  • timeseries: true flag confirms you queried a range.
  • rates: A mapping from ISO date to XAG rate objects.
  • Irregular calendars: Some dates may be absent due to weekends or market/fix schedules. Don’t assume a value for every day.

Turning the time-series into DEHR-XAG per gram

  1. Iterate over each date in data.rates.
  2. For each date, apply the same inversion and ounce-to-gram conversion described earlier.
  3. Persist a normalized structure like: { date, price_per_gram_usd, symbol: "DEHR-XAG", timestamp }.

JavaScript: batch-download a time series and normalize to DEHR-XAG per gram

async function fetchDehradunSilverPerGramTimeseries(startISO, endISO) {
const url = `https://metals-api.com/api/timeseries?access_key=${process.env.METALS_API_KEY}&start_date=${startISO}&end_date=${endISO}&base=USD&symbols=XAG`;
const res = await fetch(url);
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const data = await res.json();
if (!data.success || !data.timeseries || !data.rates) {
throw new Error(`Invalid timeseries payload: ${JSON.stringify(data)}`);
}

const out = [];
for (const [date, obj] of Object.entries(data.rates)) {
if (!obj || typeof obj.XAG !== "number") continue;
const xagPerUsdPerOunce = obj.XAG;
const usdPerOunce = 1 / xagPerUsdPerOunce;
const usdPerGram = usdPerOunce / 31.1034768;
out.push({
symbol: "DEHR-XAG",
date,
unit: "USD per gram",
price: usdPerGram
});
}
return out.sort((a, b) => (a.date < b.date ? -1 : 1));
}

Handling missing dates and market closures

  • Sparse dates: Weekend/holiday closures can result in fewer keys in rates. Your code should not assume daily continuity.
  • Forward/backward fill: For business dashboards, you may choose to carry forward the last observation for non-trading days, but always tag imputed values distinctly.
  • Backtesting: For strict financial modeling, use only observed dates to avoid look-ahead bias and false assumptions about liquidity.

Endpoint 3: Convert (optional) for currency transitions and calculations

The Convert endpoint is helpful when you need to transform amounts across metals/currencies. For example, after obtaining USD-based XAG rates, you may want to programmatically verify a unit conversion, or you may later translate the per-gram USD price into INR in your backend. Depending on your plan and data needs, you can also maintain your own FX conversion layer. The key is to ensure all operations are transparent and auditable.

Example JSON response (Convert)

{
"success": true,
"query": {
"from": "USD",
"to": "XAG",
"amount": 1000
},
"info": {
"timestamp": 1789658647,
"rate": 0.03815
},
"result": 38.15,
"unit": "troy ounces"
}

How this helps DEHR-XAG per gram workflows

  • Sanity checks: Confirm orientation of rates by converting a known USD amount into XAG ounces and back.
  • Currency presentation: If you report DEHR-XAG in a non-USD currency, combine Convert with your USD-per-gram computations in a backend pipeline.
  • Amount pipelines: For procurement tools, convert notional budgets into estimated grams as of a historical date for BOM planning.

Interpreting fields

  • query.from, query.to: Source and target units (here USD to XAG).
  • info.rate: The conversion rate used—store it for audit trails alongside timestamp.
  • result: The numeric outcome; in this example, estimated troy ounces for the provided USD amount.

Response formats you’ll use in practice (summary)

  • timestamp (UNIX UTC): Use for cache keys and ordering results.
  • date (YYYY-MM-DD): For human interfaces, business alignment, and grouping.
  • rates.XAG: The core value you transform to per gram. Verify direction (XAG per USD vs USD per XAG) and document your math.
  • unit: Declares per-troy-ounce context. Always convert to grams to support DEHR-XAG per-gram outputs.

Caching, batching, and scheduling best practices

  • Cache immutable history: Historical responses for past dates won’t change; cache them aggressively.
  • Time-series batching: Prefer a single range call over many single-day calls—fewer HTTP requests, easier retry logic, faster ETL.
  • Staggered updates: For near-real-time updates, align your polling with your plan’s update cadence. Avoid querying more frequently than the update interval.
  • Weekend/holiday guards: If your app expects daily values, implement a calendar module to explain gaps, rather than assuming errors.
  • ETL checkpoints: Store the raw JSON payload alongside normalized DEHR-XAG per-gram results for reproducibility and audits.

Security and key management

  • Environment variables: Load keys from env vars; don’t hardcode in repos.
  • Server-side proxy: If you have a browser UI, proxy API calls through your backend to protect the key.
  • Access control: Restrict who can read environment variables in CI/CD and production.
  • Rotation: Rotate keys periodically and on any staffing or infrastructure changes.
  • Monitoring: Alert on unusual traffic patterns suggesting a leaked key.

Error handling and resilience

  • Check success flags: Always test success === true before using data.
  • HTTP failures: Implement retries with exponential backoff and jitter. Fail fast on client errors (4xx) and retry server/transient errors (5xx/429) within reason.
  • Partial data: If time-series responses miss some dates, process what’s present and log gaps for investigation or imputation.
  • Data validation: Ensure rates.XAG is numeric and unit is “per troy ounce.” Log unexpected units or structures for manual review.
  • Idempotent ETL: Design jobs so re-running won’t create duplicates—use unique keys such as {date, symbol, unit}.

Performance considerations for large historical pulls

  • Windowed ingestion: Ingest by smaller date windows (e.g., monthly) if your ranges are very large to reduce memory spikes.
  • Stream processing: Convert to per-gram values as you stream the JSON rather than loading everything into memory first.
  • Compression and storage: Store normalized series in columnar or compressed formats suited to analytics (e.g., Parquet), and index by date and symbol.
  • Pre-aggregation: If dashboards need daily, weekly, and monthly data, compute and cache aggregates in your warehouse to reduce query load.

Auditing, reproducibility, and unit integrity

  • Keep a units ledger: Always record the from/to unit steps (ounce to gram, currency, etc.).
  • Store source payloads: Persist original JSON or at least the critical fields (timestamp, date, base, rates.XAG, unit).
  • Deterministic conversion: Use a constant for 1 troy ounce = 31.1034768 grams across your entire system.
  • Versioning: If you change your conversion logic or currency presentation, version your DEHR-XAG series and retain historical versions.

Use cases beyond charts: practical DEHR-XAG integrations

  • Procurement optimization: Build a rule that schedules bulk silver purchases when DEHR-XAG per gram dips below a rolling percentile threshold.
  • BOM cost rollups: Translate historical DEHR-XAG per gram into per-part silver content costs for margin analysis.
  • Price elasticity tests: For jewelry SKUs in Dehradun, simulate pricing policies against historical DEHR-XAG evolution to find resilient thresholds.
  • Risk management: Backtest hedging strategies referencing normalized DEHR-XAG rather than ounces, to match retail unit economics.

Data model: representing DEHR-XAG cleanly

Model your normalized series with explicit metadata so it’s unambiguous in analytics tools:

  • symbol: “DEHR-XAG” (your internal alias)
  • source_symbol: “XAG”
  • unit: “USD per gram” (or your chosen currency per gram)
  • date (ISO) and timestamp (UTC UNIX)
  • price: numeric
  • base_currency: “USD”
  • conversion_notes: “Inverted ounce-based rate; 1 ozt = 31.1034768 g”

Advanced techniques: seasonality, volatility, and anomaly detection

  • Seasonality: Compute monthly/weekly averages of DEHR-XAG per gram, and compare current levels to multi-year baselines.
  • Volatility bands: Construct rolling standard deviations and create procurement alerts when price pierces +/- n sigma bands.
  • Structural breaks: Apply changepoint detection on DEHR-XAG to identify regime shifts driven by industrial demand surges.
  • Inventory hedging: If you carry silver inventory, simulate P&L under different rebalancing or hedging strategies driven by the normalized series.

Working with units: troy ounces, grams, and communication

Silver is quoted per troy ounce globally; local end users frequently think in grams. Your best practice is to store both the raw ounce-based XAG series and the computed DEHR-XAG per-gram series. For clarity in UIs:

  • Always display the unit explicitly: “USD/g” or “INR/g.”
  • Offer drilldown: Let users view the raw ounce-based benchmark for auditability.
  • Disclose conversion: Note “1 ozt = 31.1034768 g” in tooltips or documentation.

Common pitfalls and how to avoid them

  • Orientation mistakes: Misinterpreting “XAG per USD per ounce” vs “USD per XAG ounce.” Validate your arithmetic against a known day.
  • Time zone errors: Conflating UTC with local time yields day-boundary mistakes. Normalize to UTC internally, convert only at the UI layer.
  • Assuming continuous dates: Historical metals data often skips weekends—never fill absent dates blindly without labeling as imputed.
  • Key leakage: Don’t expose your API key in frontends; use a backend proxy and environment variables.
  • Over-polling: Respect update frequencies; cache and schedule wisely.

Sample success and error payloads to test your handlers

Success: historical single-day XAG

{
"success": true,
"timestamp": 1789572247,
"base": "USD",
"date": "2026-09-16",
"rates": { "XAG": 0.03825 },
"unit": "per troy ounce"
}

Success: time-series XAG with sparse dates

{
"success": true,
"timeseries": true,
"start_date": "2026-09-10",
"end_date": "2026-09-17",
"base": "USD",
"rates": {
"2026-09-10": { "XAG": 0.03825 },
"2026-09-12": { "XAG": 0.0382 },
"2026-09-17": { "XAG": 0.03815 }
},
"unit": "per troy ounce"
}

Representative failure (illustrative structure—check docs for specifics)

{
"success": false,
"error": {
"code": 101,
"type": "invalid_access_key",
"info": "You have not supplied a valid API Access Key."
}
}

Handle errors gracefully: bubble up a human-readable message for admins, but keep raw error payloads in logs for diagnosis. For all error types (invalid key, quota exceeded, invalid date), write deterministic remediation steps into runbooks.

Bringing it to life: an end-to-end DEHR-XAG per-gram data pipeline

  1. Scheduler triggers a daily ETL job after market close.
  2. Job queries the Historical Rates endpoint for the prior business day (XAG, base=USD).
  3. System validates payload, converts to USD per gram, and tags as DEHR-XAG.
  4. Warehouse loads: Append to a fact table keyed by date and symbol, plus any aggregates for dashboards.
  5. APIs and UIs: Expose endpoints or views that return DEHR-XAG per gram for charts and pricing models.
  6. Alerts: Optional monitors compare new values to thresholds and notify procurement or risk teams.

Integration patterns

  • ERP integration: Populate a materials cost table keyed by component and effective date. Update supplier negotiations using DEHR-XAG trends.
  • Trading backtests: Join DEHR-XAG to other signals (momentum, macro proxies) to evaluate strategy robustness in gram-based terms.
  • E-commerce: If you price silver jewelry dynamically, map SKU metal weight (grams) to DEHR-XAG per gram, then add fabrication and margin layers.

Practical guidance a beginner might miss

  • Unit lineage: Always store how you derived gram values from ounces—auditors will ask.
  • Rounding rules: Decide on rounding at the UI layer, not during storage; keep high precision in your database.
  • Holiday calendars: Precompute a trading calendar and annotate your time-series to reduce confusion about gaps.
  • Validation checks: Compare a random historical date to a known source (e.g., a reputable market commentary) to ensure you’ve not inverted the rate.

Documentation and symbol references

Additional learning resources

Real-world scenarios in Dehradun’s context

1) Jewelry manufacturing margin guardrails

Build a pricing control where every SKU has a metal-weight profile. Your pipeline converts XAG to DEHR-XAG per gram historically, then computes SKU base cost. Layer on making charges, logistics, and markup. During volatile weeks, the system flags SKUs whose current price deviates from their rolling cost-based floor by more than a threshold.

2) Procurement timing for industrial components

For a plant that uses silver contacts in relays or sensors, condense DEHR-XAG per gram into weekly aggregates and monitor drawdowns. When a predefined drawdown occurs, create suggested purchase orders before mean reversion.

3) Research dashboards for local market analysis

Analysts build Storybook dashboards that plot DEHR-XAG per gram versus energy prices or local currency indices to understand cost pass-throughs. They annotate events (policy changes, seasonal demand) and share insights with operations.

Troubleshooting guide

  • No data for a specific day: Verify if it’s a weekend/holiday; check your start_date/end_date boundaries; ensure symbols=XAG is spelled correctly.
  • Mismatch vs known price: Re-check orientation (invert or not) and confirm the ounce-to-gram conversion. Validate base currency is USD in both places.
  • 429 or similar throttling: Implement retry with backoff and cache results to reduce repeated calls.
  • Parsing errors: Ensure your JSON parser handles numeric fields and that you don’t coerce scientific notation into strings accidentally.

Security considerations specific to this use case

  • Backend-only calls: Run Metals-API requests on the server. Clients hit your internal APIs that return normalized DEHR-XAG per-gram values.
  • Least privilege in CI/CD: Restrict who can access env secrets where your access_key lives.
  • Transport security: Use HTTPS everywhere; verify TLS certificates in your HTTP client libraries.
  • Data integrity: Hash or sign critical datasets if you distribute DEHR-XAG externally to verify tamper-evidence.

Scaling your DEHR-XAG service

  • Partition by date: Store historical data partitioned by YYYY=, MM= for fast retrieval.
  • Precompute metrics: Maintain rolling metrics tables for top endpoints to minimize recomputation.
  • Observability: Instrument latency, error rates, and payload validation stats. Alert on schema drifts.
  • Disaster recovery: Replicate critical datasets and keep infrastructure-as-code for quick rebuilds.

Verification checklist before going live

  • Orientation sanity check: Cross-verify a random date’s DEHR-XAG per gram against a reliable independent calculation.
  • Calendars and gaps: Validate your time-series length against expected trading days; annotate gaps.
  • Cache behavior: Confirm idempotency and non-duplication on ETL reruns.
  • Key safety: Confirm your access_key never appears in client-side code or logs.

Call to action: build your Dehradun Silver pipeline today

With a handful of REST calls and a precise conversion, you can publish reliable DEHR-XAG per-gram historical rates across your organization. Get your free API key from the Metals-API Website, review endpoint details in the Metals-API Documentation, and verify symbol coverage on the Metals-API Supported Symbols. Then automate everything—from ingestion to analytics—so teams in Dehradun can make faster, data-driven decisions.

Appendix: endpoint quick reference for this workflow

Endpoint Purpose Key Params Notes
/{date} Historical single-day XAG access_key, base=USD, symbols=XAG Use for backfills and point-in-time checks; convert ounce to gram.
/timeseries Historical range XAG access_key, start_date, end_date, base=USD, symbols=XAG Best for charts, backtests; handle gaps and convert to gram.
/convert Optional conversions access_key, from, to, amount Use for currency/amount transformations and validation.

Example cURL: quick time-series pull for XAG (convert to DEHR-XAG per gram downstream)

curl -s "https://metals-api.com/api/timeseries?access_key=YOUR_API_KEY&start_date=2026-09-10&end_date=2026-09-17&base=USD&symbols=XAG"

Pipeline step: invert if necessary, divide by 31.1034768, and store as DEHR-XAG (USD per gram).

Conclusion

You don’t need a complex stack to deliver precise, per-gram silver history for Dehradun. Metals-API gives you reliable XAG data via simple REST endpoints. From there, a deterministic ounce-to-gram conversion and optional currency layer produce DEHR-XAG per gram suitable for ERP materials costing, procurement timing, quant research, and retail pricing. Focus on:

  • Correct unit orientation and consistent conversions.
  • Caching immutable history and batching time-series pulls.
  • Robust error handling, key security, and auditability.
  • Practical UI/UX that makes units obvious and calculations transparent.

Start now: obtain an API key at the Metals-API Website, review the Metals-API Documentation, and confirm symbol support on the Metals-API Supported Symbols. Then ship a clean, resilient DEHR-XAG per-gram history service your Dehradun teams can rely on.

FAQ

What is DEHR-XAG?

DEHR-XAG is an application-level alias for “Dehradun Silver per gram,” derived from global Silver (XAG) data returned per troy ounce. You transform and label it internally for local consumption.

Why not query DEHR-XAG directly?

Metals-API exposes standard symbols like XAG. You compute the per-gram price and apply your regional label (DEHR-XAG) in your own system. See Metals-API Supported Symbols.

How do I convert troy ounces to grams?

Use the constant: 1 troy ounce = 31.1034768 grams. After ensuring the correct price orientation, divide by this factor to convert ounce-based values to per-gram.

What about INR pricing?

If you need INR per gram, first compute USD per gram, then convert to INR in your backend. You can use the Convert endpoint or your own FX data source. Keep the steps auditable.

How do I handle weekends and missing days?

Don’t assume a value exists for every calendar day. Accept sparse series, annotate gaps, and if needed, forward-fill with clear labeling for business dashboards (but not for strict quant backtests).

Can I cache historical data?

Yes—historical endpoints for past dates are effectively immutable. Cache aggressively to reduce API calls and speed up analytics.

Where can I get help with endpoints and parameters?

Visit the Metals-API Documentation for detailed guidance, or check symbols at the Metals-API Supported Symbols. For keys and plan options, go to the Metals-API Website.

Ready to use Metals-API?

Try it now!

Search

Related Posts

Recent Posts