Get Aluminum Futures (ALU-F) - Per Ounce Historical Prices using this API: with OHLC (open-high-low-close) data
Need aluminum futures (ALU-F) historical prices per ounce with daily OHLC bars to backfill charts, power pricing engines, or validate your signals? This guide shows how to fetch aluminum historical and OHLC data programmatically using Metals-API, with practical tips for unit handling (troy ounce vs. grams/tonne), base currency, caching, and market-closure caveats. While many trading systems refer to aluminum futures as “ALU-F,” on the Metals-API side you will query the aluminum instrument symbol listed on the symbols page (commonly XAL). Below, we’ll map your ALU-F usage to the appropriate Metals-API symbol and implement a robust, production-ready workflow.
What you will build: reliable ALU-F per-ounce historical OHLC
We will implement a small data pipeline that:
- Resolves your house symbol ALU-F to the official Metals-API symbol for Aluminum (see the symbols registry).
- Backfills historical rates per troy ounce over a time range and stores them with timestamps and base currency context.
- Retrieves daily OHLC (open-high-low-close) price bars for Aluminum to drive chart candles, analytics, and alerts.
- Handles calendar gaps (weekends/holidays), normalizes units, and caches responses to save requests.
Before you start, get your API key at the Metals-API Website and confirm the official Aluminum symbol on the Metals-API Supported Symbols page. In many integrations, ALU-F maps to XAL for aluminum pricing retrieval. We’ll use XAL in requests below and explain how to keep your internal ALU-F label intact for downstream systems.
Why aluminum pricing and OHLC are different in the API
In most exchanges and clearing workflows, aluminum is quoted and settled per metric ton. However, Metals-API delivers prices by default “per troy ounce.” This has two consequences you should plan for:
- Always read the “unit” field in responses to confirm the unit of measure. Metals-API returns “per troy ounce” by default.
- If your analytics or user interface expects per gram or per metric ton, convert precisely and consistently (1 troy ounce = 31.1034768 grams; 1 metric ton = 1,000,000 grams ≈ 32,150.7466 troy ounces). Document your chosen conversion path in your codebase.
For futures workflows, you may also keep a mapping layer: ALU-F (internal) → XAL (Metals-API) so your apps can continue to use ALU-F while the data client queries XAL. Keep this mapping in a config table and validate it periodically against the latest symbol catalog.
Endpoints we will use
We’ll focus on three endpoints that directly serve the ALU-F per-ounce historical/OHLC use case:
- Time-Series Endpoint: to backfill daily Aluminum prices over a date range.
- Historical Rates Endpoint: to fetch a single day’s price (useful for incremental jobs).
- Open/High/Low/Close (OHLC) Endpoint: to get daily candles for Aluminum.
For the complete API surface, refer to the Metals-API Documentation. Always confirm available symbols in advance via the Metals-API Supported Symbols page.
Authentication and base request patterns
All requests require your access_key parameter. The API’s base currency is USD by default, and responses include a “base” field for certainty. For ALU-F/XAL workflows, you’ll generally keep base=USD and store both the numeric rate and the unit (“per troy ounce”).
Example: time-series backfill for Aluminum (XAL)
Use this when you need a continuous daily history (e.g., last 12 months) to seed charts or train models.
curl -s "https://metals-api.com/api/timeseries?access_key=YOUR_API_KEY&start_date=2026-09-01&end_date=2026-09-25&base=USD&symbols=XAL"
Sample JSON response:
{
"success": true,
"timeseries": true,
"start_date": "2026-09-01",
"end_date": "2026-09-25",
"base": "USD",
"rates": {
"2026-09-01": { "XAL": 0.434000 },
"2026-09-02": { "XAL": 0.433500 },
"2026-09-03": { "XAL": 0.435200 },
"2026-09-04": { "XAL": 0.435000 },
"2026-09-07": { "XAL": 0.434800 },
"2026-09-08": { "XAL": 0.434600 },
"2026-09-09": { "XAL": 0.434783 },
"2026-09-10": { "XAL": 0.434750 },
"2026-09-11": { "XAL": 0.434720 },
"2026-09-14": { "XAL": 0.434710 },
"2026-09-15": { "XAL": 0.434705 },
"2026-09-16": { "XAL": 0.434700 },
"2026-09-17": { "XAL": 0.434690 },
"2026-09-18": { "XAL": 0.434680 },
"2026-09-21": { "XAL": 0.434690 },
"2026-09-22": { "XAL": 0.434720 },
"2026-09-23": { "XAL": 0.434740 },
"2026-09-24": { "XAL": 0.434760 },
"2026-09-25": { "XAL": 0.434783 }
},
"unit": "per troy ounce"
}
Key fields you will use:
- success: boolean status.
- timeseries: indicates a range response.
- start_date/end_date: requested bounds.
- base: the base currency (USD by default).
- rates[date].XAL: aluminum rate that day in units specified by unit (per troy ounce).
- unit: confirms unit of measure.
Common steps after parsing:
- Normalize each daily value to your internal unit (e.g., store both per oz and per mt for downstreams).
- Save a canonical timestamp: choose UTC midnight for the date key, document timezone handling in your data contracts.
- Maintain your internal symbol mapping: store symbol_source="Metals-API", symbol_api="XAL", symbol_internal="ALU-F".
Example: historical snapshot for a specific date
Use the Historical Rates endpoint for day-by-day incremental loads or point-in-time valuation.
curl -s "https://metals-api.com/api/2026-09-24?access_key=YOUR_API_KEY&base=USD&symbols=XAL"
Sample response:
{
"success": true,
"timestamp": 1790208860,
"base": "USD",
"date": "2026-09-24",
"rates": {
"XAL": 0.434760
},
"unit": "per troy ounce"
}
Fields to persist:
- date and timestamp: store both for auditing; timestamp is epoch seconds.
- rates.XAL: numeric price per troy ounce in base currency.
- unit: persist to guarantee unit correctness across pipelines.
Example: daily OHLC bars for Aluminum
When you need open, high, low, and close for chart candles or backtesting, use the OHLC endpoint. Request a specific trading date and symbol.
curl -s "https://metals-api.com/api/open-high-low-close/2026-09-25?access_key=YOUR_API_KEY&base=USD&symbols=XAL"
Sample response:
{
"success": true,
"timestamp": 1790295260,
"base": "USD",
"date": "2026-09-25",
"rates": {
"XAL": {
"open": 0.434760,
"high": 0.435000,
"low": 0.434600,
"close": 0.434783
}
},
"unit": "per troy ounce"
}
Field guidance:
- rates.XAL.open/high/low/close: per-ounce daily OHLC in USD.
- timestamp: aligns the data snapshot; store as-is plus an ISO-8601 conversion in your database.
- unit: consumers should not assume units; always read and log.
Bridging ALU-F and XAL in your architecture
Most platforms will keep ALU-F (futures shorthand) as the user-facing symbol, while using XAL with Metals-API under the hood. Implement this cleanly:
- Symbol registry: a table keyed by symbol_internal with fields symbol_api, provider, status, and last_verified_at. Example: ALU-F → XAL, provider=Metals-API.
- Mapper function: internal_to_provider("ALU-F") → "XAL".
- Unit registry: store a canonical base_unit for each instrument and a converter to other units your users expect (grams, kilograms, metric tons).
On ingestion, fetch by provider symbol, persist with both the provider and internal symbol, and make the unit explicit in your schema.
JavaScript integration example
The following minimal Node.js example demonstrates a resilient fetch for Aluminum time-series and OHLC, with basic validation and unit notes. Replace YOUR_API_KEY with your key from the Metals-API Website.
const fetch = require('node-fetch');
const API_BASE = 'https://metals-api.com/api';
const API_KEY = process.env.METALS_API_KEY || 'YOUR_API_KEY';
// Map your internal futures symbol (ALU-F) to Metals-API symbol (XAL)
const INTERNAL_TO_API = { 'ALU-F': 'XAL' };
function assertUnit(unit) {
if (unit !== 'per troy ounce') {
throw new Error(`Unexpected unit: ${unit}`);
}
}
async function getAluminumTimeseries(start, end) {
const sym = INTERNAL_TO_API['ALU-F'];
const url = `${API_BASE}/timeseries?access_key=${API_KEY}&start_date=${start}&end_date=${end}&base=USD&symbols=${sym}`;
const res = await fetch(url);
const json = await res.json();
if (!json.success) throw new Error(`Timeseries error: ${JSON.stringify(json)}`);
assertUnit(json.unit);
return json; // Persist json.rates[date][XAL]
}
async function getAluminumOHLC(date) {
const sym = INTERNAL_TO_API['ALU-F'];
const url = `${API_BASE}/open-high-low-close/${date}?access_key=${API_KEY}&base=USD&symbols=${sym}`;
const res = await fetch(url);
const json = await res.json();
if (!json.success) throw new Error(`OHLC error: ${JSON.stringify(json)}`);
assertUnit(json.unit);
return json; // Use json.rates.XAL.{open,high,low,close}
}
(async () => {
try {
const ts = await getAluminumTimeseries('2026-09-01', '2026-09-25');
console.log('Timeseries:', Object.keys(ts.rates).length, 'days, unit:', ts.unit);
const ohlc = await getAluminumOHLC('2026-09-25');
console.log('OHLC:', ohlc.rates.XAL);
} catch (e) {
console.error(e);
process.exit(1);
}
})();
What you’ll use downstream:
- timeseries.rates: daily close-equivalent readings keyed by date; store one row per date.
- ohlc.rates.XAL: open, high, low, close for chart candles and analytics.
Data handling you should not skip
Units and conversions
- Default unit in examples is “per troy ounce.” Always read json.unit before assuming.
- Convert to grams: oz_troy_to_grams = 31.1034768.
- Convert to metric tons: oz_troy_to_metric_ton = 32150.7465686 (approx). Multiply per-ounce price by that factor to obtain per-metric-ton price.
- Round thoughtfully: keep at least 6 decimals internally to minimize drift across conversions; only round for display.
Base currency and normalization
- Responses default to base=USD. If you need another base for reporting, multiply by appropriate FX rates or use the Convert endpoint when combining metals and currencies (see documentation).
- Store both the raw rate and the base currency in your DB schema to avoid ambiguity.
Timestamps and timezone
- timestamp is epoch seconds; convert to UTC ISO-8601 when storing.
- Daily rates are keyed by date; we recommend normalizing to UTC midnight for the effective date.
Weekends and market closures
- You may observe missing dates in time-series around weekends/holidays. Your aggregator should not “fill forward” without a business rule.
- When building charts, render gaps or document your fill logic (e.g., forward-fill for valuation but mark as stale).
Caching and request efficiency
- Cache time-series responses keyed by start_date/end_date/symbol/base for 24 hours (or your data freshness policy).
- For daily jobs, prefer Historical or OHLC for the single date over re-pulling a large time-series.
- Batch symbols when practical, but keep payloads manageable and cache per day.
Endpoint deep dive: Time-Series for Aluminum
Purpose and functionality
Retrieve daily Aluminum (XAL) prices between two dates to backfill datasets or perform rolling analytics. The response includes one entry per date with the Aluminum rate under rates[date].XAL.
Required parameters
- access_key: your API key.
- start_date: inclusive, format YYYY-MM-DD.
- end_date: inclusive, format YYYY-MM-DD.
- symbols: use XAL for Aluminum (confirm on the symbols page).
- base: optional; defaults to USD. Keep USD for consistency unless you have a strong reason otherwise.
Example responses
Success with partial date coverage (e.g., weekend skipped):
{
"success": true,
"timeseries": true,
"start_date": "2026-09-18",
"end_date": "2026-09-25",
"base": "USD",
"rates": {
"2026-09-18": { "XAL": 0.434680 },
"2026-09-20": { },
"2026-09-22": { "XAL": 0.434720 },
"2026-09-25": { "XAL": 0.434783 }
},
"unit": "per troy ounce"
}
Notes:
- Some calendars may omit non-trading days, or return empty objects; code defensively.
- Always check success and unit; treat missing dates explicitly in downstream logic.
Error example (invalid date):
{
"success": false,
"error": {
"code": "invalid_date",
"type": "Invalid Date",
"info": "The date format is invalid or out of range."
}
}
Troubleshooting tips:
- Validate dates client-side before calling.
- If you see gaps, do not assume continuity; document a strategy for missing dates.
Performance and optimization
- For large ranges, paginate your own requests by month to avoid very large payloads and to ease retries.
- Cache past windows; rerun only the trailing N days where revisions might occur (define N per your governance).
Security best practices
- Store access_key in environment variables or a secrets manager; never hardcode.
- Restrict outbound network ACLs to trusted hosts where possible.
Endpoint deep dive: Historical Rates for Aluminum
Purpose and functionality
Retrieve a single day’s Aluminum price, useful in daily ETL jobs, on-demand valuation, or audit checkpoints.
Parameters
- Path date: /YYYY-MM-DD (UTC).
- access_key: your API key.
- symbols: XAL.
- base: optional; default USD.
Success response
{
"success": true,
"timestamp": 1790208860,
"base": "USD",
"date": "2026-09-24",
"rates": { "XAL": 0.434760 },
"unit": "per troy ounce"
}
Practical use:
- Run this each trading day for T-1 close if that matches your reporting policy.
- If your ledger requires EOD snapshots, store the raw payload with a content hash for audit.
Error and recovery
{
"success": false,
"error": {
"code": "missing_access_key",
"type": "No API Key",
"info": "You have not supplied an API Access Key."
}
}
Recovery steps:
- Retry only after adding the access_key, not on exponential backoff.
- For transient network errors, backoff with jitter and cap retries to protect budgets.
Endpoint deep dive: OHLC for Aluminum
Purpose and functionality
Obtain daily open, high, low, and close for Aluminum (XAL) to power candles, breakout logic, and risk controls.
Parameters
- Path date: /open-high-low-close/YYYY-MM-DD.
- access_key: your API key.
- symbols: XAL.
- base: optional; default USD.
Success response
{
"success": true,
"timestamp": 1790295260,
"base": "USD",
"date": "2026-09-25",
"rates": {
"XAL": {
"open": 0.434760,
"high": 0.435000,
"low": 0.434600,
"close": 0.434783
}
},
"unit": "per troy ounce"
}
How to use it:
- Charting: render OHLC with the unit in your legend. If you convert to metric ton for display, keep conversion factors visible in tooltips.
- Analytics: compute ATR, range, gap-open logic. Always maintain unit consistency across bars.
Edge cases
- Quiet sessions may exhibit tight ranges; do not infer missing liquidity solely from narrow high-low spreads.
- If a date is a holiday, your request may yield empty or absent values; encode guardrails.
Practical pipeline design for ALU-F data
Suggested architecture
- Scheduler: triggers daily at T+1 00:30 UTC for historical and OHLC pulls.
- Fetcher: queries OHLC for the date and falls back to Historical if OHLC unavailable.
- Normalizer: enforces unit and base currency standards; stores both raw and derived units (oz, g, mt).
- Warehouse: partitions by date and symbol; include provider metadata and schema version.
- Downstream services: charts, alerts, model training reading from curated views.
Data model essentials
- symbol_internal (e.g., ALU-F), symbol_api (XAL), provider (Metals-API), unit (“per troy ounce”), base (“USD”).
- For OHLC: date, open, high, low, close; for timeseries: date, close (or daily rate).
- Integrity hashes for payloads to support audits and reproducibility.
Quality controls and validation
- Bounds checks: assert that high ≥ max(open, close) and low ≤ min(open, close).
- Spike detection: z-score on returns to flag anomalies for manual review.
- Unit drift: monitor the unit field; raise alerts if it changes from “per troy ounce.”
Governance, security, and secrets
- Protect your API key via secret managers (e.g., AWS Secrets Manager, HashiCorp Vault).
- Access separation: read-only roles for analysts; service accounts for ingestion.
- Audit trails: log request IDs, URLs without secrets, response hashes, and timestamps.
Scaling and performance tips
- Front a small in-memory cache for the current day; refresh at a cadence that matches your plan’s update frequency.
- Batch requests per symbol with clear retry semantics and idempotent upserts into storage.
- Prefer immutable historical snapshots; re-ingest only when required by governance.
Extending your analytics
- Compute derived features like rolling volatility, moving averages, and range-based indicators directly from OHLC.
- Correlate Aluminum prices with energy inputs or FX for hedging models (manage units diligently).
Working with innovation: aluminum and digital transformation
Aluminum underpins technologies from EVs to lightweight aerospace parts. Integrating real-time and historical Aluminum pricing into fintech and manufacturing systems fuels smarter procurement, automated repricing, and data-driven hedging. Metals-API’s machine-readable JSON plus straightforward endpoints make it practical to embed Aluminum price intelligence in ERP quotes, inventory valuation, and IoT-driven production plans. With developers standardizing around transparent units, timestamps, and symbols (ALU-F → XAL), teams can build resilient, auditable pipelines that scale as product lines and geographies expand.
Troubleshooting and common pitfalls
- Mismatch between ALU-F and XAL: always confirm your symbol mapping against the official symbols list.
- Assuming units: do not assume per tonne; always read the “unit” field and convert explicitly.
- Timezone ambiguity: normalize all dates to UTC and document it in your API contracts.
- Weekend gaps: do not force-fill unless your business rules require it, and then tag filled values.
Complete “latest” check for sanity
Although historical and OHLC anchor this workflow, it’s useful to cross-check the latest price for monitoring dashboards. This is optional but helpful for operational sanity checks.
curl -s "https://metals-api.com/api/latest?access_key=YOUR_API_KEY&base=USD&symbols=XAL"
Sample JSON (excerpt adapted for Aluminum):
{
"success": true,
"timestamp": 1790295260,
"base": "USD",
"date": "2026-09-25",
"rates": {
"XAL": 0.434783
},
"unit": "per troy ounce"
}
Use this for dashboards and alerting; for backfills and chart bars use Time-Series and OHLC as described.
Call to action: get your key and confirm symbols
Ready to integrate Aluminum historical OHLC into your stack? Get a free API key at the Metals-API Website, then review parameters and examples in the Metals-API Documentation. Before coding, verify Aluminum’s symbol on the Metals-API Supported Symbols page and add your ALU-F → XAL mapping to your config.
Additional resources
- In-depth API documentation and endpoint reference
- Live list of supported metals symbols
- Sign up and get your API key
- Market background on base metals (external)
- Aluminum market overview (external)
Conclusion
To operationalize ALU-F historical pricing per ounce with OHLC:
- Map ALU-F to the official Aluminum symbol used by Metals-API (commonly XAL; confirm on the symbols page).
- Use Time-Series for backfills, Historical for single-day increments, and OHLC for daily candles.
- Treat unit, base currency, timestamp, and weekend closures as first-class data fields.
- Implement caching, retries, and schema rigor to build a resilient pricing foundation for analytics, ERP pricing, and hedging strategies.
Start now: get your key at the Metals-API Website and follow the documentation for production-grade integration.
FAQ
Is ALU-F the same symbol I will call in Metals-API?
Not necessarily. Many teams use ALU-F internally for aluminum futures. In Metals-API you will typically request Aluminum via XAL. Confirm the exact code on the Supported Symbols page and keep a mapping (ALU-F → XAL) in your config.
What unit are the prices in?
By default, Metals-API returns prices “per troy ounce.” Always verify the “unit” field in the response. Convert explicitly if you need grams or metric tons.
Which endpoints should I use for historical OHLC?
Use the OHLC endpoint for daily open, high, low, close bars. For close-only or daily rates across ranges, use the Time-Series endpoint. For a single day, use the Historical endpoint.
How do I handle weekends and holidays?
You may see missing dates or empty bodies for non-trading days. Do not assume continuity; choose either to render gaps on charts or implement controlled forward-fill for valuation, and document that policy.
Do I need to pass a base currency?
No; base defaults to USD. If you require other bases, handle conversion carefully and always persist base in your data schema.
How often should I cache?
Cache static historical ranges aggressively. For daily runs, pull only the latest date(s). Dashboards can cache “latest” for a short window aligned with your plan’s refresh interval.
Where can I find all parameters and symbols?
See the Metals-API Documentation for endpoints/parameters and verify aluminum’s symbol on the Supported Symbols page.