Get High Grade Copper Sep 2025 (HGU25) - Per Pound prices using this API for Python scripts

Need High Grade Copper Sep 2025 (HGU25) per-pound prices inside a Python workflow? Here’s a practical way to do it with the Metals-API — a real-time and historical metals data API that returns copper prices as XCU, denominated in USD per troy ounce. In this guide, you’ll map spot copper (XCU) quotes to your HGU25 analytics, convert troy ounces to pounds, and use two to three focused endpoints to build a maintainable, production-grade pipeline. We’ll walk through requests, JSON responses, unit conversions, caching, and time handling so you can plug results into trading models, manufacturing pricing, and research dashboards.

What “HGU25 per pound” means for your Python scripts

HGU25 is the CME/COMEX High Grade Copper futures contract for September 2025. Metals-API provides a robust spot-copper data series via the XCU symbol, returned as USD per troy ounce. If your downstream models require HGU25 in USD per pound, a common practice is to:

• Pull XCU with Metals-API for real-time or historical values.
• Convert from troy ounces to pounds using a precise factor (1 lb = 14.5833333 troy oz).
• Optionally apply a contract-specific basis or spread (if you maintain one from your futures workflow) to proxy the HGU25 level.

This approach lets you standardize units across pricing tools and align with the copper futures calendar without inventing unsupported symbols. You’ll also benefit from the API’s consistent JSON structure and time semantics for reproducible analysis.

Key concept: XCU spot copper as the backbone for HGU25 analytics

Because Metals-API exposes copper via the XCU symbol, you’ll use XCU as the observable and perform lightweight transformations to arrive at a “per-pound” view suitable for HGU25-related dashboards and alerts. This keeps the pipeline stable and avoids symbol mismatches. To confirm current symbols and availability, check the authoritative list at the Metals-API Supported Symbols.

If you are new to Metals-API, start here: Metals-API Website. To implement the examples below, sign up and get a free API key — you’ll pass it via the access_key parameter.

Where XCU data fits into HGU25 decisioning

Developers and quants often use XCU as the real-time or historical reference series for:

• Real-time pricing display or alerts keyed to copper moves, while maintaining results in lb for manufacturing BOMs and ERP price updates.
• Historical backtests comparing spot-based heuristics vs. futures (HGU25) models.
• Risk dashboards that convert all copper exposures into a standardized unit (USD/lb) to drive hedging logic.

Because Metals-API returns prices per troy ounce with USD as the base by default, conversions are deterministic. A unit conversion is enough to feed systems that must run in “per pound” terms.

Endpoints we’ll use for HGU25-oriented workflows

We’ll focus on three endpoints that keep your integration lean and relevant to HGU25 analytics:

• Latest rates: for near-real-time XCU quotes when markets are open.
• Time-series: for stitching together historical copper series that drive backtests and seasonal analytics toward Sep 2025.
• OHLC: for daily open/high/low/close on XCU to power candlestick charts and intraday summaries.

For full API coverage (including additional endpoints like conversion, fluctuation, bid/ask, and more), refer to the Metals-API Documentation. We’ll keep examples centered on XCU so you can adapt them cleanly to HGU25-related tasks.

Units, conversions, and accuracy for “per pound” copper

Metals-API data for copper is returned per troy ounce, base USD. To convert to USD/lb precisely:

• 1 troy ounce = 31.1034768 grams.
• 1 avoirdupois pound = 453.59237 grams.
• Therefore, 1 lb = 453.59237 / 31.1034768 = 14.5833333 troy ounces.
• USD per pound = (USD per troy ounce) × 14.5833333

Be explicit about rounding and precision in your code. If you model basis/spread between spot and HGU25, apply it after the unit conversion so all steps are transparent and auditable.

Authentication, base currency, time, and market calendar

• Authentication: Include your API key as the access_key query parameter. Get a key at the Metals-API Website.
• Base currency: By default, the base is USD. The JSON will indicate the base field explicitly.
• Timestamps and timezone: API responses include a Unix timestamp and a date field. Align these to your system timezone and be careful with end-of-day logic when generating OHLC or EOD summaries.
• Weekends/market closures: Metals quotes can be static across weekends. Implement fallback/caching to avoid burning requests when no new data is expected.

Latest rates: fetch XCU and convert to USD per pound

Use the Latest endpoint to retrieve current XCU in USD per troy ounce. Then convert to USD per pound inside your Python flow.

curl example: latest XCU

curl -s "https://metals-api.com/api/latest?access_key=YOUR_API_KEY&base=USD&symbols=XCU"

Example JSON response (Latest)

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

Field usage:

• success: Boolean indicating the request succeeded.
• timestamp: Unix time for the rate snapshot. Use for cache keys and latency measurement.
• base: Currency base (USD by default); confirms value semantics.
• date: Calendar date of the data. Validate against your EOD logic.
• rates.XCU: Copper spot in USD per troy ounce. Convert to per pound by multiplying by 14.5833333.
• unit: Confirms “per troy ounce” for metals. Essential for unit transforms.

Python example: latest XCU to USD/lb

import os
import json
import urllib.request
from decimal import Decimal, ROUND_HALF_UP

API_KEY = os.getenv("METALS_API_KEY", "YOUR_API_KEY")
URL = f"https://metals-api.com/api/latest?access_key={API_KEY}&base=USD&symbols=XCU"

TOZ_PER_POUND = Decimal("14.5833333")

def fetch_json(url: str) -> dict:
with urllib.request.urlopen(url, timeout=10) as resp:
data = resp.read()
return json.loads(data.decode("utf-8"))

def to_usd_per_pound(usd_per_toz: Decimal) -> Decimal:
return (usd_per_toz * TOZ_PER_POUND).quantize(Decimal("0.0001"), rounding=ROUND_HALF_UP)

def main():
payload = fetch_json(URL)
if not payload.get("success", False):
raise RuntimeError(f"API failure: {payload}")
usd_per_toz = Decimal(str(payload["rates"]["XCU"]))
usd_per_lb = to_usd_per_pound(usd_per_toz)
print(json.dumps({
"date": payload["date"],
"timestamp": payload["timestamp"],
"usd_per_toz": str(usd_per_toz),
"usd_per_lb": str(usd_per_lb),
"unit_from": payload.get("unit"),
"unit_to": "per pound"
}, indent=2))

if __name__ == "__main__":
main()

Typical output from the Python script

{
"date": "2026-09-19",
"timestamp": 1789776584,
"usd_per_toz": "0.294118",
"usd_per_lb": "4.2879",
"unit_from": "per troy ounce",
"unit_to": "per pound"
}

What you’ll use next:

• usd_per_lb: Feed this into your pricing, alerts, or ERP update routines.
• timestamp/date: Write to your datastore with these fields for reproducibility and reconciliation.
• Rounding: Quantize with a consistent decimal policy (ROUND_HALF_UP shown) to prevent rounding drift.

Time-series: build a historical XCU curve to contextualize HGU25

For HGU25 analytics, you’ll often need a historical baseline: seasonality, drawdowns, and trend regimes into late 2024–2025. Metals-API’s time-series endpoint provides daily XCU values for a given date range.

curl example: time-series window around a sample period

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

Example JSON response (Time-series)

{
"success": true,
"timeseries": true,
"start_date": "2026-09-12",
"end_date": "2026-09-19",
"base": "USD",
"rates": {
"2026-09-12": {
"XCU": 0.295000
},
"2026-09-14": {
"XCU": 0.294500
},
"2026-09-19": {
"XCU": 0.294118
}
},
"unit": "per troy ounce"
}

Field usage:

• timeseries: Confirms this is a time-series response.
• start_date, end_date: The requested interval; store for auditing.
• rates: Daily snapshots keyed by ISO date; each includes XCU in USD per troy ounce.
• unit: You’ll convert each daily value to USD/lb using 14.5833333.

Implementation tips for time-series:

• Weekend handling: Expect missing or static dates around weekends/holidays. When building continuous curves, forward-fill logically or skip non-business days based on your model.
• Caching and pagination: Cache responses for fixed historical windows. For rolling windows, maintain a local store and update only the last N days to minimize calls.
• Alignment to futures calendar: If modeling HGU25 seasonality, map each historical date to “days to Sep expiry” features in your feature store. The metals time-series gives you the core price input.

OHLC: daily candles for XCU to inform HGU25 signal design

The Open/High/Low/Close endpoint returns structured daily OHLC for your symbol, enabling robust charting or volatility analytics. Use it to derive daily ranges, ATR-like measures, and intraday heuristics feeding HGU25 strategies.

curl example: OHLC for a date

curl -s "https://metals-api.com/api/open-high-low-close/2026-09-19?access_key=YOUR_API_KEY&base=USD&symbols=XCU"

Example JSON response (OHLC)

{
"success": true,
"timestamp": 1789776584,
"base": "USD",
"date": "2026-09-19",
"rates": {
"XCU": {
"open": 0.295200,
"high": 0.296000,
"low": 0.293900,
"close": 0.294118
}
},
"unit": "per troy ounce"
}

Field usage:

• rates.XCU.open/high/low/close: USD per troy ounce. Convert each to USD/lb.
• Derived metrics: Range = high - low; Candle body = close - open; Map both to per-pound after conversion.
• Timestamp/date: Store as your EOD marker; be conservative with cut-off definitions across timezones.

Additional JSON scenarios and how to use them

Latest endpoint including multiple metals (useful when you also track inputs beyond XCU)

Even if your focus is HGU25, sometimes teams fetch a small basket and filter locally. The structure remains the same; we’ll highlight XCU below.

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

Implementation note: If you do request multiple symbols, validate that XCU is present before proceeding, and fallback to cached values if it's absent.

Time-series response showing a flat weekend

{
"success": true,
"timeseries": true,
"start_date": "2026-09-16",
"end_date": "2026-09-19",
"base": "USD",
"rates": {
"2026-09-16": { "XCU": 0.294700 },
"2026-09-17": { "XCU": 0.294500 },
"2026-09-18": { "XCU": 0.294500 },
"2026-09-19": { "XCU": 0.294500 }
},
"unit": "per troy ounce"
}

Usage: You might see repeated values across non-trading days. Decision: forward-fill knowingly or filter weekends from time-series analytics.

OHLC response with tighter daily range (lower realized intraday volatility)

{
"success": true,
"timestamp": 1789776584,
"base": "USD",
"date": "2026-09-18",
"rates": {
"XCU": {
"open": 0.294600,
"high": 0.294800,
"low": 0.294300,
"close": 0.294500
}
},
"unit": "per troy ounce"
}

Usage: After converting to USD/lb, calculate high-low and compare to prior days; incorporate into a volatility-controlled position size or alert threshold for your HGU25-facing tool.

Parameter choices and validation for accuracy

• base=USD: This is the default and matches most futures P&L conventions. Keep it consistent across endpoints.
• symbols=XCU: Only request what you need. Smaller payloads reduce network overhead and parsing time.
• start_date/end_date (time-series): Use ISO dates. Validate that end_date ≥ start_date, and enforce safe maximum windows according to your plan tier and data needs.
• OHLC date path: Ensure the date you request aligns with your intended trading session cutoff to avoid mixing partial-day data with full-day analytics.

From XCU to HGU25: basis, convergence, and mapping strategies

While Metals-API doesn’t publish futures contract codes like HGU25 directly, you can create a clean mapping that keeps your logic auditable:

1. Fetch XCU as the observable spot series (USD/toz).
2. Convert to USD/lb (multiply by 14.5833333).
3. Apply a basis adjustment, b(t), where b(t) is maintained by your futures model (could be function of carry, inventory, calendar spreads, or regression). HGU25_estimate = USD/lb_spot + b(t).
4. Use CME product metadata for contract calendars and roll logic. See CME Group’s copper futures product page for specifications: CME High Grade Copper contract specs.

This hybrid approach uses Metals-API as a reliable price backbone while your futures-specific engine handles basis modeling, roll conventions, and risk logic tied to Sep 2025.

Caching, request efficiency, and robustness

• Client-side caching keyed by date and symbol: For historical pulls, cache indefinitely. For latest, cache by timestamp and practical staleness windows (e.g., a few minutes, depending on your plan update frequency).
• Retries and timeouts: Implement short socket timeouts and bounded retries with exponential backoff. Do not spam retries; consult your plan’s fair use guidelines.
• Weekend behavior: If the timestamp doesn’t advance across calls, short-circuit additional requests until the next trading session or a scheduled refresh.
• Concurrency: If you aggregate data for multiple consumers, centralize one Metals-API fetch process and share the normalized results internally, minimizing duplicate calls.

Data validation and sanitization

• Schema checks: Assert on presence of fields like success, base, date, rates, and rates.XCU.
• Type safety: Convert numeric strings to Decimal in Python for financial-grade arithmetic.
• Bounds checks: Reject or flag values that are NaN, infinite, or fall outside plausible ranges based on your historical database.
• Unit label: Always confirm unit == 'per troy ounce' before converting to lb; raise if unit changes unexpectedly.

Error handling and graceful degradation

Design your client to be predictable when something goes wrong:

• Transport errors: On HTTP/network failures, return last-known-good data with a “stale” flag or fail fast, depending on your SLA.
• API errors: If success is false, log the body for diagnostics and route to fallback logic. Avoid guessing at missing values.
• Partial updates: If OHLC is not yet finalized intraday, label it as preliminary and exclude it from EOD archives until end-of-session completeness criteria are met.

Security best practices

• Key management: Store your access_key in environment variables or a secrets manager. Never hardcode in source repos.
• TLS: Always use HTTPS endpoints (as demonstrated).
• Least privilege: If multiple services read the API, issue separate keys per service to isolate risk and track usage.
• Logging hygiene: Do not log raw URLs with the access_key in plaintext in shared logs.

Performance and scaling tactics

• Batch windows: For historical backfills, segment date ranges to stay within reasonable response payload sizes and retry scope.
• Normalization pipeline: Convert to USD/lb at ingestion and store both raw (USD/toz) and derived (USD/lb) values for maximum flexibility without recomputation.
• Pre-aggregation: Compute daily rolling averages, ranges, and volatility metrics once per day and serve pre-aggregates to charts and alerts.
• Stateless worker pattern: Design fetchers to be idempotent so you can scale horizontally behind a queue without duplicate side-effects.

How timestamp and date fields affect your EOD logic

Metals-API provides both a human-readable date and a Unix timestamp. Decide how your system pins “end of day” for OHLC consolidation:

• UTC normalization: Convert timestamps to UTC and define day cutoffs at 00:00:00Z boundaries to avoid timezone drift.
• Historical consistency: When storing the time-series, persist the original date from the payload for traceability and your computed EOD boundary in metadata.
• Intraday snapshots: If you poll the latest endpoint frequently, store samples by timestamp to analyze intraday microstructure or to build a nowcasting signal for HGU25.

Designing a copper-per-pound API wrapper for your org

To keep your applications clean, build an internal wrapper that:

• Fetches XCU from Metals-API and validates success/base/unit.
• Converts USD/toz to USD/lb with a stable Decimal policy.
• Annotates records with source, timestamp, and any basis adjustments for HGU25 mapping.
• Caches results with TTL aligned to your plan’s update frequency.

This wrapper becomes your single entry point for copper pricing across backtesting, dashboards, and ERP integrations, ensuring unit correctness and consistent semantics.

Practical integration checklist for HGU25 workflows

• Confirm your symbol: Use XCU for copper. Verify it on the Metals-API Supported Symbols page.
• Implement latest/time-series/OHLC in small, testable functions.
• Convert to USD/lb consistently and store both raw and converted values.
• If modeling HGU25 explicitly, maintain a basis function, b(t), with provenance and change control.
• Cache aggressively; avoid polling when markets are closed.
• Add monitoring: Alert on missing fields, unexpected unit/base changes, or stale timestamps.

End-to-end example: from API to per-pound analytics and alert

1. Call Latest (XCU) and store USD/toz with timestamp, then derive USD/lb.
2. Compare USD/lb to a rolling 20-day mean derived from the time-series endpoint (converted to USD/lb).
3. If deviation exceeds a chosen z-score threshold, trigger an alert for your HGU25 desk or pricing engine.
4. End of day, persist OHLC (converted to USD/lb) and compute realized daily range, feeding a risk-adjusted size calculator for next session’s HGU25 logic.

Reference: three focused endpoints for XCU-driven HGU25 tooling

Endpoint	Purpose	Key Parameters	Primary Fields Used
latest	Near-real-time XCU	access_key, base=USD, symbols=XCU	timestamp, date, rates.XCU, unit
timeseries	Historical XCU curve	access_key, base=USD, symbols=XCU, start_date, end_date	rates[date].XCU, start_date, end_date, unit
open-high-low-close/YYYY-MM-DD	Daily OHLC candles	access_key, base=USD, symbols=XCU	rates.XCU.open/high/low/close, date, unit

For details on optional parameters, response structures, and additional endpoints, use the Metals-API Documentation.

Quality assurance: tests your CI/CD should run

• Schema tests: Ensure all required fields appear and types match expectations.
• Unit conversion tests: Verify USD/toz × 14.5833333 equals USD/lb within your rounding policy.
• Weekend tests: Confirm code paths don’t spam the API when timestamps are static.
• Backfill tests: Simulate multi-day time-series pulls and verify no duplicates or gaps post-merge.
• Failure injection: Mock non-success payloads and transport timeouts to test fallback logic.

Data governance and lineage

• Provenance: Store raw JSON payloads or hashes alongside derived series for audits.
• Metadata: Annotate each record with base, unit, access window, and your conversion constants.
• Versioning: If your basis function for HGU25 mapping changes, bump a model version and tag all derived outputs.

Operational monitoring

• Freshness: Track how long since the last successful latest pull; alert if it exceeds thresholds.
• Drift: Monitor rolling stats of USD/lb for anomalies relative to historical distributions.
• Cost control: Sample request counts and cache hit rates. Adjust polling accordingly.

Frequently used formulas for copper per pound

• USD/lb = USD/toz × 14.5833333
• Daily range (lb) = (high_toz - low_toz) × 14.5833333
• ATR-like measure (lb) = rolling mean of daily ranges after conversion

Example: building a 10-day rolling per-pound series from time-series

Pull a 15-day window to compute the last 10 rolling averages; convert each to USD/lb and persist. This supports thresholds for HGU25 desk alerts or rebalancing. Because the API returns per troy ounce, perform conversion before aggregation to avoid rounding magnification.

Compliance with your futures calendar and rolls

For an HGU25 pipeline, you’ll likely roll your modeling focus from a front contract to Sep 2025 as you get closer to the target delivery month. Because the API provides a spot copper series (XCU), maintain a separate module that manages:

• Contract calendars and business day conventions (e.g., from your CME calendars).
• A basis function b(t) aligned to carry/storage models or historical convergence patterns.
• Roll dates and rules for switching contracts when building a continuous HGU-based series for backtests.

Combining XCU with external futures data (optional)

Some teams overlay futures market data from their existing feeds with XCU spot from Metals-API to reinforce estimates and diagnostics. Ensure you label each source and reconcile units rigorously. For official futures specs, refer to the CME link above.

Security and privacy considerations for production

• Keys in secret stores; short-lived containers pull keys at startup only.
• Segmented network access to limit egress to approved endpoints.
• PII-free by design: metals data pipelines rarely handle personal data; keep it that way.

Putting it all together: a minimal architecture

• Fetcher (cron or event-driven): Calls latest/time-series/OHLC for XCU, validates and converts to USD/lb.
• Normalizer: Rounds, annotates with metadata (unit, base, timestamp), writes to time-series DB.
• Analytics: Computes rolling stats, ATR, z-scores, basis-adjusted HGU25 estimates.
• Delivery: Serves to dashboards, alerts, and ERP price update jobs.
• Observability: Logs, metrics, and alerts for data freshness and API health.

Additional references and where to go next

• Start building now: Metals-API Website — get a free API key and test XCU requests within minutes.
• Read the docs: Metals-API Documentation — full parameter options, response formats, and endpoint coverage.
• Check symbols first: Metals-API Supported Symbols — confirm XCU and other symbols you might need.
• Futures product info: CME High Grade Copper contract specs — calendar and contract rules for HGU-series analytics.

Conclusion

To get High Grade Copper Sep 2025 (HGU25) per-pound prices into Python scripts, anchor your workflow on Metals-API’s XCU series. Fetch XCU via Latest for real-time usage, Time-series for historical context, and OHLC for candle analytics. Convert USD/toz to USD/lb with a precise 14.5833333 factor and, if needed, overlay your basis function for HGU25 estimates. Implement caching, careful timestamp handling, schema validation, and robust error paths so your production systems are stable and transparent. With a small, focused set of endpoints and disciplined unit conversion, you can power alerts, dashboards, and pricing engines that speak your organization’s preferred unit — USD per pound — while keeping the underlying data lineage clean and reliable. Get started today at the Metals-API Website and grab a free API key.

FAQ

Does Metals-API provide the HGU25 contract directly?

Metals-API exposes copper via the XCU symbol (USD per troy ounce). For HGU25-specific modeling, most teams use XCU as the observable and apply a basis or spread in their own futures module.

How do I convert to USD per pound accurately?

Multiply USD/toz by 14.5833333. Use Decimal arithmetic to avoid floating-point drift. Store both raw (USD/toz) and derived (USD/lb) values for auditability.

Which endpoints should I start with?

Use Latest for current XCU, Time-series for historical curves, and OHLC for daily candles. These three cover most HGU25-related analytics needs. For other endpoints, see the Metals-API Documentation.

What about weekends and holidays?

Expect static or unchanged values across market closures. Cache aggressively and avoid unnecessary polling during these periods.

Can I change the base currency?

The API defaults to USD. Keep USD for consistency with most futures P&L conventions, or review the docs for currency options and confirm how base affects returned rates.

How often are latest rates updated?

Update frequency depends on your subscription plan. Design your polling cadence and cache TTL to match your plan’s update interval. Refer to your account details on the Metals-API Website.

What security practices should I follow?

Store access keys in environment variables or secret managers, use HTTPS, and scrub keys from logs. Allocate separate keys per service if possible.