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:
- Lookup symbol for Ferro Silicon and verify on test calls.
- Pull latest price intraday for FE-SI (or its specific LME/CME symbol) at intervals consistent with your plan.
- Cache results for at least the refresh cadence to avoid redundant calls.
- For daily analytics, use the time-series endpoint to compute moving averages and ranges.
- Use OHLC for candlestick charts and bid/ask for execution-aware pricing in client tools.
- Use fluctuation for daily percent moves; set thresholds for alerting.
- Convert USD to your billing currency for quoting, or convert price units if your business logic requires it.
- 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
- Symbol discovery: Resolve FE-SI from the Supported Symbols directory.
- Latest loop: Poll Latest Rates or Intraday at your plan’s cadence; cache for the interval; store raw and normalized.
- Daily close: Pull OHLC and Lowest/Highest for session summaries; update dashboards and risk reports.
- History jobs: Nightly backfills with Time-Series for analytics and ML feature stores.
- Alerts: Use Fluctuation to detect abnormal moves; distribute to Slack/Teams/Email.
- FX logic: Convert to local quoting currency for sales and ERP integrations.
- Governance: Monitor API health, latency, error rates; rotate keys; audit usage.
Additional developer resources
- Primary reference: Official Metals-API Documentation
- Start here: Create your account and get a free API key
- Explore coverage: View the full list of supported symbols
- LME market information: London Metal Exchange
- Market analysis perspectives: World Steel Association
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.