Query Ferro Silicon (FE-SI) prices with this API

Metals-API 16 min read
Query Ferro Silicon (FE-SI) prices with this API

Ferro Silicon price transparency matters when you’re quoting alloy surcharges in steelmaking, rebalancing an inventory hedge, or building a procurement dashboard that alerts on intraday moves. This guide shows how to query Ferro Silicon (FE-SI) prices programmatically using the Metals-API, transform the feed into actionable analytics, and integrate it into trading, ERP, and pricing workflows. While we’ll center on Ferro Silicon’s industrial use case, all techniques apply broadly to metals data. We’ll also cover practical details developers often ask about: base currency, units (troy ounces vs metric tons), timestamps, caching, time zones, weekend behavior, and how to combine latest, time-series, OHLC, bid/ask, fluctuation, and conversion endpoints into one resilient service stack.

Why query Ferro Silicon prices with Metals-API?

Ferro Silicon (often traded as FE-SI or Ferrosilicon) is a key deoxidizer and alloying element in steel and cast iron production. It’s a cornerstone for long-term supply contracts, index-linked surcharges, and short-term purchasing decisions. Digitizing the feed that powers these decisions unlocks:

  • Real-time quoting in procurement and e-commerce portals when suppliers need responsive, conditional pricing.
  • Automated surcharge calculations in ERPs based on daily or intraday benchmarks.
  • Alerts and dashboards for volatility management, enabling hedging or inventory optimization.
  • Backtesting in quant research for exposure measurement and correlation studies against steel, silicon metal, and energy costs.

Metals-API provides a JSON REST interface that cleanly integrates into data pipelines, microservices, and client-side applications. You can start quickly at the Metals-API Website, explore the Metals-API Documentation, and check whether Ferro Silicon is available and under which symbol via the Metals-API Supported Symbols page. If you don’t have an API key yet, sign up there to get a free API key and begin testing.

First, confirm the correct Ferro Silicon symbol

Before writing any code, confirm the exact tradable symbol used by the API for Ferro Silicon. Metals-API covers precious and industrial metals; symbols can vary by venue or contract. Do not assume the ticker code. Instead:

  • Visit the live Supported Symbols page and search for “Ferro Silicon” or “Ferrosilicon.”
  • If a contract is listed under a specific venue (e.g., LME), note the precise exchange-qualified symbol from that page.
  • Keep your code flexible: externalize the symbol into a configuration variable so you can change it without redeploying.

If Ferro Silicon is not listed for your plan or region, you can prototype with another industrial metal (e.g., copper or aluminum) using the same endpoints, then switch the symbol once you have the proper access.

How data is quoted: base currency, units, and conversions

Metals-API delivers exchange rates relative to a base currency (USD by default) and uses a unit descriptor in the response. In the example responses below, the unit is “per troy ounce.” For precious metals like gold (XAU) and silver (XAG), that’s standard. For Ferro Silicon, pricing in physical markets is typically per metric ton. If your response unit differs from how you price FE-SI commercially, you will need to convert units consistently.

  • Base currency: Default is USD. Convert to your local currency using the Convert Endpoint or perform your own FX conversion off-platform if you already have a currency rates feed.
  • Units: Many industrial users require per metric ton. If the returned unit is “per troy ounce,” convert to kg or metric ton in your logic, or leverage the Convert Endpoint for monetary conversions. Always store the “unit” field alongside the rate to avoid silent dimensionality errors.
  • Timestamps: Response includes a Unix epoch timestamp and a date. Treat the data as UTC for aggregation and cache invalidation routines.

End-to-end flow: from latest quotes to analytics and alerts

Here’s a practical flow you can implement:

  1. Lookup symbol for Ferro Silicon and verify on test calls.
  2. Pull latest price intraday for FE-SI (or its specific LME/CME symbol) at intervals consistent with your plan.
  3. Cache results for at least the refresh cadence to avoid redundant calls.
  4. For daily analytics, use the time-series endpoint to compute moving averages and ranges.
  5. Use OHLC for candlestick charts and bid/ask for execution-aware pricing in client tools.
  6. Use fluctuation for daily percent moves; set thresholds for alerting.
  7. Convert USD to your billing currency for quoting, or convert price units if your business logic requires it.
  8. Persist all observations with timestamp and unit for auditability and reproducibility.

Quick-start: one curl and one JavaScript example

Replace YOUR_API_KEY with your key from the Metals-API Website. In the curl request below, swap YOUR_SYMBOL with the Ferro Silicon symbol you found on the Supported Symbols page. The sample JSON body shown after is representative of the Metals-API format, using available metals from the examples.

curl: latest rates for a specific symbol

curl -sG "https://metals-api.com/api/latest" \
--data-urlencode "access_key=YOUR_API_KEY" \
--data-urlencode "base=USD" \
--data-urlencode "symbols=YOUR_SYMBOL"

Representative JSON format (example metals shown):

{
"success": true,
"timestamp": 1789432554,
"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"
}

JavaScript example: request, parse, and normalize

This JavaScript example demonstrates how to fetch, verify, and transform the response. Replace YOUR_SYMBOL with the Ferro Silicon symbol you confirmed earlier.

// Minimal example using fetch in Node.js or modern browsers
async function fetchMetalRate(symbol) {
const url = new URL("https://metals-api.com/api/latest");
url.searchParams.set("access_key", process.env.METALS_API_KEY || "YOUR_API_KEY");
url.searchParams.set("base", "USD");
url.searchParams.set("symbols", symbol);

const res = await fetch(url.toString(), { method: "GET", timeout: 10000 });
if (!res.ok) throw new Error("HTTP error " + res.status);
const json = await res.json();

if (!json.success) {
// Handle API-level errors consistently, log json.error if present
throw new Error("API error retrieving " + symbol);
}

// Extract the rate and unit
const rate = json.rates[symbol];
const unit = json.unit; // e.g., "per troy ounce"

// Normalize: if your business logic needs USD per metric ton, convert here
// This example doesn't assume unit conversion factors; implement per your context.
return {
symbol,
rate,
unit,
base: json.base, // "USD"
asOf: new Date(json.timestamp * 1000).toISOString()
};
}

fetchMetalRate("YOUR_SYMBOL")
.then((data) => console.log(data))
.catch((err) => console.error(err));

Fields you’ll actually use:

  • success: Quick guard for runtime logic.
  • timestamp and date: Use timestamp for cache keys and to align with your time zone logic.
  • base: Always store; you’ll need it for conversions and UX labels.
  • rates: Object keyed by symbol; extract your FE-SI symbol value.
  • unit: Critical for dimensional correctness; store and propagate through your system.

Choosing the right endpoint for each Ferro Silicon use case

Metals-API offers multiple endpoints to support real-time pricing, historical research, and charting. Below are concrete FE-SI scenarios and how to implement them.

Intraday quoting and dashboards: Latest Rates and Intraday

When building a live dashboard or performing frequent refreshes for quotes, start with the Latest Rates endpoint. Depending on your plan, data updates at intervals such as every 60 minutes or every 10 minutes. For higher temporal resolution of a single symbol, the Intraday endpoint lets you query intraday exchange rate data for a single symbol. Use Intraday when you need granular snapshots of a specific symbol like FE-SI without pulling the entire basket.

Representative Latest Rates response structure:

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

Implementation notes:

  • Parameters: access_key (required), base (optional; defaults to USD), symbols (comma-separated; specify FE-SI or equivalent).
  • Caching: Cache by (endpoint, base, symbols) and respect the provider’s refresh cadence; avoid hammering the endpoint more frequently than it updates.
  • UI: Show the “as of” time derived from timestamp to set user expectations.

Backfilling and analytics: Historical Rates and Time-Series

For time-based analyses (rolling volatility, moving averages, model training), you’ll use Historical Rates (single day) or Time-Series (multiple days). Historical rates are available for most currencies and metals; check available ranges and your plan in the documentation. For FE-SI, once you confirm the symbol, the approach is identical.

Representative Historical Rates response format:

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

Representative Time-Series response 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"
}

Implementation notes:

  • Parameters: Include start_date and end_date for Time-Series; ensure they’re within your plan’s limits.
  • Data gaps: Weekends/holidays may be absent or carry last-available updates; handle missing days in your charting code.
  • Backfill strategy: Batch your queries by month or quarter; respect rate limits and introduce exponential backoff for retries.

Execution-aware pricing: Bid and Ask

If your application cares about executable levels (e.g., you set quotes that include spread or you backtest slippage), use the Bid and Ask endpoint. It returns bid, ask, and spread per symbol when supported for your plan.

{
"success": true,
"timestamp": 1789432554,
"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"
}

Implementation notes:

  • Use bid/ask midpoints for fair-value analytics; use bid for conservative sell valuations and ask for conservative buys.
  • Propagate the spread to front-end UIs so users see market tightness.
  • Cache and throttle similarly to Latest Rates; intraday plans refresh more often.

Candles and charting: OHLC

For candlestick charts and quantitative signals, the Open/High/Low/Close endpoint is crucial. It provides a single day’s OHLC snapshot for supported symbols.

{
"success": true,
"timestamp": 1789432554,
"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"
}

Implementation notes:

  • Persist the OHLC four-tuple with timestamp and unit for reproducibility.
  • Use OHLC close for end-of-day marks; open for gap analysis.
  • If FE-SI OHLC is supported via an exchange-specific symbol, ensure you’re requesting the correct one.

Day-over-day changes: Fluctuation

To power alerting and risk summaries, the Fluctuation endpoint returns start and end rates plus absolute and percentage changes over a specified date range.

{
"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"
}

Implementation notes:

  • Set alert thresholds on change_pct; route to Slack/email for procurement and risk teams.
  • Combine with bid/ask to include spread-aware triggers.

Conversion: price transformations and currency

The Convert endpoint transforms any amount from one currency or metal to another. For FE-SI use cases, developers commonly convert USD-marked data into EUR or local currency for quoting, or convert monetary amounts into physical quantities for logistics accounting.

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

Implementation notes:

  • Always log the rate and timestamp used for conversion to ensure auditability.
  • For unit conversions (e.g., troy ounces to metric tons), apply deterministic factors in your code and keep those constants versioned.

LME-focused history: Historical LME

If your FE-SI is traded or benchmarked on the London Metal Exchange and is available in your plan, the Historical LME endpoint provides historical data for LME symbols back to earlier years. This is essential for backtesting FE-SI hedges or running long-horizon analytics. Confirm exact symbol availability for Ferro Silicon in the Symbols directory first.

Extremes and ranges: Lowest/Highest and OHLC

The Lowest/Highest Price endpoint answers: “What was the lowest and highest price on a given date?” While OHLC provides intraday bar snapshots, Lowest/Highest focuses on extrema, which can be useful for stress testing and scenario planning. Combine it with OHLC to capture both range and closing behavior.

Comparing endpoints at a glance

Feature Purpose Typical FE-SI Use Notes
Latest Rates Most recent prices Dashboards, quotes Respect refresh cadence; cache results
Intraday Granular updates for one symbol Order timing, frequent polling Use for high-resolution FE-SI view
Historical Rates Single date backfill Valuation, snapshot audits Use for EOD reporting
Time-Series Multiple dates Charts, analytics, ML features Batch by range; handle missing days
Bid and Ask Executable spreads Quote precision, slippage modeling Show spread in UIs
OHLC Candles Technical analysis, EOD marks Store O/H/L/C with timestamp
Fluctuation d/d change summary Alerts, risk reporting Use change_pct thresholds
Convert Currency/metal conversion Quote in EUR/JPY; physical calc Log used rate and time
Historical LME LME-specific history FE-SI if available on LME Verify symbol on Symbols page
Lowest/Highest Daily extrema Stress tests, risk scenarios Complement OHLC

Practical guidance most beginners miss

Units: troy ounces vs metric tons

The examples show “per troy ounce.” Industrial metals are commonly priced per metric ton. Decide whether to:

  • Convert returned units into your internal canonical unit (e.g., store everything as USD/mt).
  • Retain provider-native units and convert only at display time.

Canonical approaches ease analytics but require thorough migration if provider units change. Whichever you choose, record both the original unit and the transformed unit, with conversion factors and timestamps.

Base currency and multi-currency quoting

Default base is USD. If your quoting currency differs, use the Convert endpoint to translate amounts. If your system already maintains an FX feed, keep Metals-API in USD and apply FX via your own rates for consistency across your product.

Timestamps and time zones

  • Metals-API timestamps should be treated as UTC.
  • Normalize all persisted times to UTC to avoid DST drift in analytics.
  • Display in user-local zones in UI layers only.

Weekends and market closures

Expect fewer or no updates on weekends and holidays. Handle missing dates explicitly in time series by forward-filling or using business-day calendars in visualizations.

Caching and cost control

  • Set HTTP cache lifetimes aligned to refresh cadence. Avoid polling more often than new data is available.
  • Introduce a small randomized jitter to polling intervals to avoid thundering herds.
  • Cache per key (endpoint, base, symbols, date range, aggregation) to maximize hit ratios.

Deep dive: interpreting response fields and building robust logic

Common fields across endpoints

  • success: Always check first. If false, log and alert operationally.
  • timestamp: Use as the authoritative “as of” for caching and ETL ids.
  • base: Keep in schema for multi-currency analytics.
  • unit: Track rigorously. Unit errors are the top source of pricing bugs.

Examples of different scenarios

Success with available symbols:

{
"success": true,
"timestamp": 1789432554,
"base": "USD",
"date": "2026-09-15",
"rates": { "XCU": 0.294118 },
"unit": "per troy ounce"
}

Success with multiple symbols (useful for cross-metal spreads):

{
"success": true,
"timestamp": 1789432554,
"base": "USD",
"date": "2026-09-15",
"rates": {
"XAL": 0.434783,
"XNI": 0.142857
},
"unit": "per troy ounce"
}

Error scenario (illustrative handling approach):

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

Implementation tips:

  • For success=false, parse error.code and error.type, map to retriable/non-retriable classes, and expose to observability tooling.
  • Propagate human-readable error.info to logs with request correlation ids.
  • Fail “open” for dashboards (show stale-but-labeled data) and fail “closed” for trading flows (block orders) depending on risk policy.

Security, authentication, and operational resilience

Authentication

  • Your API key is passed via the access_key parameter. Never hardcode it in client-side code for public apps; proxy through a secure backend.
  • Rotate keys periodically. Store in a secret manager (e.g., AWS Secrets Manager, HashiCorp Vault) and hot-reload at runtime where possible.

Authorization and least privilege

  • If building multi-tenant services, segregate API keys per tenant or per environment (dev/staging/prod) to reduce blast radius.
  • Mask keys in logs and never expose them in client error messages.

Rate limiting and quota management

  • Respect plan-based rate limits; implement a token bucket or leaky bucket client to spread requests over time.
  • Use HTTP 429 handling with exponential backoff and jitter. Consider circuit breakers to protect your system under sustained limit hits.

Error handling and recovery

  • Classify errors: network, HTTP, and API-level (success=false). Retry network and 5xx with backoff; do not retry authentication or parameter errors.
  • On downstream failures, serve the last known good value (with timestamp and a “stale” badge) for non-critical dashboards.

Data validation and sanitization

  • Validate that rates are positive numbers and within expected bands; alert on outliers.
  • Ensure timestamps are reasonable (not far in future/past) before persisting.
  • Strictly parse and enforce ISO date formats for time-series ranges.

Performance optimization for heavy users

  • Batch requests: Request multiple symbols in one call where appropriate to amortize overhead.
  • Sharding: For large time-series backfills, shard ranges and process in parallel with concurrency limits.
  • Compression: Enable HTTP compression where supported by your HTTP client stack.
  • In-memory caching: Use LRU caches at the aggregator microservice layer; refresh in background.
  • Event-driven updates: Schedule refreshes keyed to known exchange sessions for FE-SI where applicable.

Building production-grade Ferro Silicon analytics

Data model

  • Keyed by: symbol, base, unit, timestamp.
  • Store raw and normalized values (e.g., USD/oz and USD/mt) with the conversion factor used.
  • Persist endpoint source (latest, ohlc, bid/ask) and version for traceability.

Derived analytics

  • Rolling metrics: 5/20/60-day moving averages, realized volatility, daily ranges.
  • Spread analytics: From bid/ask, compute mid and percent spread for liquidity proxies.
  • Alerts: Thresholds on fluctuation change_pct; composite alerts mixing FX and FE-SI movement.

Front-end integration

  • Show “as of” UTC timestamp prominently.
  • Use OHLC for daily charts and Time-Series for history—merge them where helpful.
  • Label units explicitly; include a toggle if you offer multiple units (oz, kg, mt).

Historical context and digital transformation in Ferro Silicon markets

As steel, foundry, and electronics supply chains modernize, data-driven sourcing replaces static vendor quotes and spreadsheet trackers. With APIs, procurement teams integrate FE-SI benchmarks directly into RFQ flows, and treasurers measure exposure alongside energy, freight, and FX. Quant teams analyze correlations across alloys, silicon metal, and broader commodities to determine whether to hedge with related instruments. And product teams bring customers net-price transparency, factoring FE-SI movement into e-commerce carts and ERP-discount logic. These transformations are made tractable by simple, reliable feeds like the Metals-API that encapsulate exchange- and market-specific complexities behind a single, consistent contract.

Putting it all together: an FE-SI service pattern

  1. Symbol discovery: Resolve FE-SI from the Supported Symbols directory.
  2. Latest loop: Poll Latest Rates or Intraday at your plan’s cadence; cache for the interval; store raw and normalized.
  3. Daily close: Pull OHLC and Lowest/Highest for session summaries; update dashboards and risk reports.
  4. History jobs: Nightly backfills with Time-Series for analytics and ML feature stores.
  5. Alerts: Use Fluctuation to detect abnormal moves; distribute to Slack/Teams/Email.
  6. FX logic: Convert to local quoting currency for sales and ERP integrations.
  7. Governance: Monitor API health, latency, error rates; rotate keys; audit usage.

Additional developer resources

FAQ

How do I find the correct Ferro Silicon symbol?

Use the live Supported Symbols page. Search for “Ferro Silicon” or “Ferrosilicon,” and note any exchange qualifiers. Avoid guessing; symbol formats vary by venue.

The response says “per troy ounce,” but I price FE-SI per metric ton. What do I do?

Convert units consistently in your code and store both the original and normalized values. Keep conversion constants version-controlled and expose units clearly in your UI and exports.

How often does data update?

Update frequency depends on your subscription plan and the specific endpoint. The Latest Rates endpoint typically updates at plan-specific intervals (e.g., every 60 minutes or every 10 minutes). Cache responses for at least the refresh period to avoid unnecessary calls.

What happens on weekends and holidays?

Expect reduced or no updates. Your time-series may have gaps; handle missing dates explicitly in queries and charts (e.g., by forward-filling or using business-day calendars).

Can I get bid/ask for Ferro Silicon?

If supported for your plan and symbol, yes. Use the Bid and Ask endpoint. If bid/ask isn’t available for your FE-SI contract, fall back to mid or last prices for analytics and clearly label this in UIs.

How do I convert USD FE-SI prices to EUR?

Use the Convert endpoint to translate amounts between currencies. Log the timestamped rate applied for auditability and to reconcile with accounting later.

What are best practices for reliability?

Implement rate limiting, caching aligned to refresh cadence, exponential backoff for retries, circuit breakers, and observability (latency, error rates). Always store timestamp, base, and unit with the value.

Where do I start?

Sign up at the Metals-API Website, read the documentation, confirm the FE-SI symbol in Supported Symbols, and make your first test request. From there, implement the Latest Rates flow and add Time-Series, OHLC, and Fluctuation as your needs evolve.