Get Accurate Brass Shell (BRSH) - Per Ounce Prices in Multiple Currencies with this API for Node.js integration

Building a Node.js app that needs accurate Brass Shell (BRSH) price per ounce across multiple currencies? This guide shows how to integrate Metals-API Website into product pricing, procurement analytics, and risk dashboards so you can quote, hedge, and reconcile brass-derived components with confidence. You’ll see how to fetch real-time and historical data (per troy ounce), convert prices across currencies, and design a resilient data pipeline that accounts for caching, market hours, and unit conversions—while keeping the door open for future analytics and automation.

Why BRSH per ounce pricing matters for Node.js product teams

Whether you’re building a quoting engine for ammunition casings, fittings, fasteners, cartridges, or automotive terminals, “Brass Shell (BRSH) - per ounce” pricing is a practical denominator for:

Dynamic quotes in multi-currency e-commerce (USD, EUR, JPY, etc.).
Procurement benchmarking and cost variance analysis between suppliers.
Risk dashboards alerting to intraday or weekly price moves to trigger reorders or hedges.
Manufacturing ERP updates to refresh bill-of-materials cost rollups in real time.
Research backfills for trend lines, seasonal studies, and spread analysis.

Metals-API provides real-time and historical metals and currency data via simple JSON, built for developer ergonomics and production reliability. Start with a free key at the Metals-API Website and consult the Metals-API Documentation for details.

About Brass (BRASS) and Brass Shell (BRSH): digital transformation meets practical pricing

Brass is a copper-zinc alloy favored for its machinability, corrosion resistance, and electrical properties—used in casings, valves, precision parts, and conductors. Digitally, brass pricing has historically been fragmented across distributor quotes and regional markets. With APIs, developers can standardize brass-derived pricing into a consistent “per ounce” feed, integrate it into trading, fintech, and ERP tooling, and enrich it with analytics. This unlocks:

Smart Technology Integration: Serverless Node.js jobs updating BOMs, quoting margins, and currency conversions at deploy-time and run-time.
Data Analytics and Insights: Comparative charts (brass vs copper), cost attribution, and volatility-adjusted reorder logic.
Technological Advancement: Automation to reduce manual price refreshes and reconciliation errors.
Future Trends: Event-driven procurement (subscribe to fluctuations) and automated consumer pricing that respects target margins.

Before coding: verify symbol availability at the Metals-API Supported Symbols. If you rely on BRSH, confirm it’s listed. If BRSH is not listed, align workflows to available brass-related symbols or benchmark proxies (for example, copper for sensitivity analyses), and annotate your model to maintain transparency.

Quick start: fetch per-ounce data and convert across currencies

The fastest way to test your pipeline is with the Latest Rates endpoint. All responses are JSON, default base is USD, and the unit is per troy ounce unless specified.

Try it in curl

Replace ACCESS_KEY with your key. For demonstration we show a call retrieving common precious and industrial metals; if BRSH is supported in your plan/symbols, add it to symbols similarly.

curl -G https://metals-api.com/api/latest \
--data-urlencode "access_key=ACCESS_KEY" \
--data-urlencode "base=USD" \
--data-urlencode "symbols=XAU,XAG,XPT,XPD,XCU,XAL,XNI,XZN"

Example JSON response (unit: per troy ounce):

{
"success": true,
"timestamp": 1789606424,
"base": "USD",
"date": "2026-09-17",
"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"
}

What you use:

success: Boolean for error gating.
timestamp: Unix epoch seconds you can translate into reports; cache-key candidate.
base: Base currency (USD here). Controls interpretation of rates.
date: ISO-8601 calendar date; use in time series joins.
rates: Map of symbol to rate. Each value is “units of metal per 1 base currency unit” when unit is “per troy ounce.” For example, XAU: 0.000482 means 1 USD buys 0.000482 troy ounces of gold.
unit: Clarifies measurement (“per troy ounce”). Don’t assume grams or pounds.

Node.js pattern for converting and normalizing

This example demonstrates fetching latest data and computing a per-ounce price in your target currency. Substitute your symbols (e.g., BRSH if supported) and currencies as needed.

const https = require('https');
const querystring = require('querystring');

async function fetchLatest({ accessKey, base = 'USD', symbols = [] }) {
const qs = querystring.stringify({
access_key: accessKey,
base,
symbols: symbols.join(',')
});
const url = `https://metals-api.com/api/latest?${qs}`;
return new Promise((resolve, reject) => {
https.get(url, (res) => {
let data = '';
res.on('data', chunk => data += chunk);
res.on('end', () => {
try {
const json = JSON.parse(data);
if (!json.success) return reject(new Error('API error'));
resolve(json);
} catch (e) {
reject(e);
}
});
}).on('error', reject);
});
}

(async () => {
const accessKey = process.env.METALS_API_KEY;
const symbols = ['XCU']; // Replace/add 'BRSH' if supported in your plan
const latest = await fetchLatest({ accessKey, base: 'USD', symbols });

const { timestamp, date, unit, rates } = latest;
// Compute USD per troy ounce for XCU (if rate is ounces per USD, invert):
// Since rates are metal per 1 USD (per troy ounce), USD per ounce = 1 / rate
const ozPerUSD = rates['XCU'];
const usdPerOunce = ozPerUSD ? (1 / ozPerUSD) : null;

console.log({
asOf: new Date(timestamp * 1000).toISOString(),
date,
unit,
usdPerOunce
});
})().catch(err => {
console.error('Error:', err.message);
});

Note: Metals-API responses express metal per 1 unit of base currency. If you need the price as base currency per 1 ounce (e.g., USD/oz), invert the rate: price = 1 / rates[symbol]. Keep this consistent across your system to avoid silent unit errors.

Understanding units: troy ounces vs grams and how to prevent costly mistakes

Metals-API returns data “per troy ounce” by default. A troy ounce is approximately 31.1034768 grams—different from the avoirdupois ounce used in everyday weight. Many manufacturing specs list brass in kilograms or pounds. If your BOM is in kg, do this:

USD/oz = 1 / rates[BRSH] when base=USD and unit=per troy ounce.
USD/g = (USD/oz) / 31.1034768.
USD/kg = (USD/g) * 1000.

Always annotate your pricing metadata with the precise unit and any conversions applied. Consider a shared utility library that converts metal per USD to a canonical USD/oz and adds derived units for grams and kilograms.

Core endpoints you’ll use together for BRSH workflows

Below we show how to apply the Latest, Historical, Time-series, Convert, Fluctuation, OHLC, and Bid/Ask features in practical Node.js integrations. Where BRSH is available, plug in that symbol. If it’s not in the Metals-API Supported Symbols, align your approach to supported brass-related symbols; do not hard-code unsupported tickers.

Latest: real-time quoting and on-demand cache warming

Use Latest to drive your live quotes and to seed in-memory or distributed caches. Example JSON is shown earlier. Strategies:

Cold start: Warm your cache on service boot with a Latest call for all required symbols.
TTL: Set cache TTL based on your plan’s update frequency (for example, 60 minutes or 10 minutes, depending on subscription). Don’t poll faster than updates.
Edge cache: For multi-region Node.js deployments, use a shared cache (Redis) or CDN to minimize egress and latency.

Common pitfalls:

Inversion error: Mistaking ounces per USD for USD per ounce. Document and test with assertions.
Mixed unit math: Combining ounces and grams without explicit conversion utilities.
Silent fallback: If a symbol isn’t returned, do not silently default. Raise warnings to logs and fall back to last-known-good value with metadata.

Historical: backfilling charts and BOM revaluations

Historical rates let you retrieve a specific past date to revalue inventory or backfill charts. Example JSON:

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

Use cases:

Inventory revaluation as-of prior quarter-end.
Compliance or audit evidence for pricing snapshots.
Verification of supplier quotes against market reference.

Handling weekends and closures: Some metals have reduced liquidity on weekends/holidays. If a date yields sparse data, query the closest prior business day as a fallback and annotate the effective date in your UI. Do not interpolate across long closures without explicit analytics sign-off.

Time-series: building trends, seasonality, and volatility models

Use Time-series to request a daily range. Example JSON:

{
"success": true,
"timeseries": true,
"start_date": "2026-09-10",
"end_date": "2026-09-17",
"base": "USD",
"rates": {
"2026-09-10": {
"XAU": 0.000485,
"XAG": 0.03825,
"XPT": 0.000915
},
"2026-09-12": {
"XAU": 0.000483,
"XAG": 0.0382,
"XPT": 0.000913
},
"2026-09-17": {
"XAU": 0.000482,
"XAG": 0.03815,
"XPT": 0.000912
}
},
"unit": "per troy ounce"
}

Practical tips:

Normalization: Store normalized USD/oz alongside raw API values for reproducibility.
Joins: Key by ISO date and symbol; track base and unit with each row.
Downsampling: Compute weekly and monthly aggregates for dashboards to reduce query cost.
Gaps: If some dates are missing, backfill with last-known-good while tagging data quality.

Convert: converting amounts between currencies and metals

Convert helps you move between units and currencies in a single step. Example JSON:

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

How to interpret:

query: Your intent; persist it for auditability in quote systems.
info.timestamp: The rate’s recency; attach to prices in UI.
info.rate: The conversion rate used; store for reconciliation.
result: The numeric outcome; here 1000 USD becomes 0.482 troy ounces of XAU.
unit: The result unit (“troy ounces”).

Workflow idea: In multi-currency ecommerce, convert user’s currency to BRSH ounces for universal comparison, then convert back to display currency. This ensures margin logic is applied on a consistent underlying measure.

Fluctuation: alerting and risk rules

Fluctuation captures change between two dates. Example JSON:

{
"success": true,
"fluctuation": true,
"start_date": "2026-09-10",
"end_date": "2026-09-17",
"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"
}

Use it to:

Trigger replenishment: If change_pct exceeds threshold, enqueue purchase orders.
Alert product management: If BRSH drops 3% WoW, consider promotional pricing.
Risk reporting: Surface largest movers across your material set daily.

Implementation detail: Store both absolute and percentage changes. Since rates are metal per USD, define consistent orientation: either compute in that space or convert to USD/oz first; just be consistent everywhere.

OHLC: candlesticks, gap detection, and strategy backtests

Open/High/Low/Close provides a structured snapshot. Example JSON:

{
"success": true,
"timestamp": 1789606424,
"base": "USD",
"date": "2026-09-17",
"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"
}

Use cases:

Price bands in procurement UI (e.g., “Today’s range”).
Gap detection: Compare prior close to current open.
Backtests: Use open/close to evaluate daily strategies or cost averaging logic.

Tip: Invert OHLC values if you require USD/oz. Keep a helper for OHLC inversion to avoid copy-paste errors.

Bid/Ask: tighter quotes and spread-aware margining

Bid/Ask provides spread-aware views. Example JSON:

{
"success": true,
"timestamp": 1789606424,
"base": "USD",
"date": "2026-09-17",
"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"
}

Practical margining:

Buying cost basis: Use ask side (invert to get USD/oz ask if needed).
Selling basis: Use bid side.
Spread risk: Inflate safety margins or order sizes when spreads widen.

Display: Surface spread to power users so they understand why quotes adjust during illiquidity.

Symbol considerations for Brass Shell (BRSH)

Always confirm symbol coverage in your plan. Visit the Metals-API Supported Symbols to validate the exact symbol name, unit, and availability. If BRSH is supported, add it to your calls just like other metals. If not:

Use supported brass-related or industrial proxies (e.g., copper) for sensitivity analysis and internal planning.
Flag BRSH as “proxy-priced” in UX to maintain transparency with users or auditors.
Design your data model with a layer of indirection: product component maps to a pricing symbol that can be swapped when direct coverage becomes available.

Per-ounce vs per-piece pricing for components

Even if you sell per piece (e.g., shells or terminals), your cost engine should anchor on USD/oz (or USD/kg) then add scrap, machining, plating, and overhead. To move from per-ounce to per-piece:

Compute brass weight per piece in grams.
Convert to ounces or kilograms using exact conversion factors.
Multiply by USD per that unit derived from the API.
Add fabrication yields and losses; store assumptions with versioning.

Architecting your Node.js integration for resilience

Service layering: Create a MetalsPricingService encapsulating API calls and caching. Only expose normalized fields (USD/oz, timestamp, unit).
Caching: Use Redis with TTL pegged to your plan’s update frequency. Cache misses should not cascade into multiple identical API calls; de-dupe with a single-flight pattern.
Circuit breakers: If API errors spike, fall back to last-known-good values with clear UI badges (e.g., “Last update 58 minutes ago”).
Observability: Log timestamp, base, symbols, and cache hits/misses. Alert if symbol data is missing or unit changes unexpectedly.
Configuration: Externalize symbols and currencies to environment variables or feature flags so ops can react without redeploy.

Authentication, authorization, and key hygiene

API key: Pass it via access_key parameter. Keep keys out of client-side code; proxy via your backend.
Rotation: Support multiple keys for zero-downtime rotation. Store keys in a secret manager (e.g., environment variables injected at deploy time).
Least privilege: Limit key usage to the endpoints you need; segment environments (dev/stage/prod) with separate keys.

Get your key at the Metals-API Website and read the Metals-API Documentation for endpoint specifics.

Error handling and graceful degradation

Transport errors: Retry with jittered backoff; cap retries to avoid thundering herds.
API-level errors: Check success=false and parse any error object. Log symbol, base, and timeframe.
Partial data: If some symbols are missing, respond with a degraded response that clearly flags unavailable items and uses cached alternatives if recent.
Timeouts: Apply short timeouts for synchronous UI requests; longer for batch jobs. Fail fast rather than hanging.

Rate limits, quotas, and cost control without guesswork

Metals-API plans define update frequency and request quotas. Don’t poll faster than your plan refreshes data. Techniques:

Push caching upstream: Aggregate symbol requests per tick, not per user interaction.
Batch: Request multiple symbols in one call rather than separate requests.
Staggered refresh: Align cron or serverless triggers to plan update intervals.
Client-side cache: For purely read-only dashboards, leverage HTTP caching via your backend to avoid redundant server fetches.

Data validation and sanitization

Schema checks: Validate presence of success, timestamp, base, unit, and required rate symbols.
Range checks: Flag zero or negative rates as invalid.
Unit checks: Assert unit is “per troy ounce” before applying ounce-based math.
Time checks: Ignore responses with timestamp older than acceptable staleness threshold for real-time features.

Security and compliance

HTTPS only: All requests should be over TLS; reject mixed content.
Key scope: Keep keys server-side and access-restricted.
Audit: Log key usage events, IP addresses (compliant with privacy policies), and endpoint access for investigations.
Secrets management: Use a vault or managed secrets; never commit keys to repos.

Production patterns for weekends and market closures

Weekend mode: Lock quotes to last business day’s close; allow manual override.
UI affordances: Label “Market Closed” with timestamp of last update; avoid showing stale prices as “live.”
Backfill jobs: Run a reconciliation pass after weekend/holidays to align any derived analytics with the first liquid session.

Performance optimization: latency, throughput, and cost

Warm caches at start-of-day and every allowed update tick.
Sharded caches per region to reduce cross-region latency while maintaining consistency with a small lag tolerance.
Precompute: Maintain USD/oz and primary display currencies pre-inverted and rounded to your precision model; avoid expensive floating-point inversions in hot paths.
Vectorization: When consuming Time-series in batch workflows, transform rates in slices rather than per-record loops to reduce CPU overhead.

Data modeling for analytics and audit trails

Immutable events: Store each API snapshot with timestamp, base, unit, and raw rates JSON for replayability.
Derived tables: Maintain normalized, inverted USD/oz tables for analytics joins.
Versioned assumptions: Keep conversion constants and process yields versioned with effective dates.

Designing pricing UX with transparency

Show “As of” timestamp and base currency.
Indicate unit used in price (USD/oz, USD/kg) and provide easy toggles.
When BRSH is proxy-priced, disclose the proxy symbol and methodology inline with a tooltip linking to your pricing methodology doc.

Step-by-step Node.js integration plan

Confirm symbol coverage at Metals-API Supported Symbols.
Get your key from the Metals-API Website.
Create a pricing service module that implements:
- Latest fetch with cache, returns normalized USD/oz and timestamp.
- Historical and Time-series for charts and audits.
- Convert for multi-currency calculations.
- Fluctuation and OHLC for alerts and analytics.
- Bid/Ask for spread-aware margining.
Add monitoring: error rates, symbol coverage, cache health, staleness duration.
Integrate into quoting, ERP, and research tools.
Document methodology: unit conversions, inversion logic, fallback rules.

Comparing symbol usage patterns and units

Item	Example Symbol	API Rate Meaning	To get USD/oz	Notes
Gold	XAU	oz per 1 USD	1 / rates.XAU	Default unit: per troy ounce
Silver	XAG	oz per 1 USD	1 / rates.XAG	Use for spread monitoring
Copper	XCU	oz per 1 USD	1 / rates.XCU	Industrial proxy comparisons
Brass Shell	BRSH	Verify at Symbols List	Invert if provided per ounce	Check coverage before use

Scenario walkthroughs that product teams ship

1) Multi-currency e-commerce pricing for BRSH components

At each update tick, your backend fetches Latest for BRSH (or proxy) and store USD/oz.
For each storefront currency, compute local_currency/oz using Convert, or compute via currency cross-rates if you maintain them.
Add per-piece weights and yields, compute price floors, and apply business rules.
Cache prices and annotate with a timestamp visible in admin UI for accountability.

2) Procurement dashboard with alerting

Daily Fluctuation for BRSH and peers; alert on change_pct thresholds.
OHLC to display daily ranges and identify widening volatility regimes.
Time-series to overlay moving averages and seasonal patterns (e.g., Q1 spikes).

3) ERP cost rollups with audit-ready historicals

At quarter-end, query Historical for the cut-off date; reprice WIP and finished goods.
Store raw JSON snapshots alongside calculated USD/kg used in the ledger.
Enable auditors to trace every figure to a timestamp and unit.

Timestamps, timezones, and consistency

timestamp field is Unix epoch seconds; convert to UTC ISO string and store it.
date is ISO calendar date; align it with your accounting calendar if needed.
Always present “as of” in UTC to avoid ambiguity across timezones.

Extending with analytics: from raw data to insights

Volatility tracking: Compute rolling standard deviation from Time-series to size safety stock.
Seasonality: Compare month-over-month averages YoY to budget for expected swings.
Cross-metal spreads: Track BRSH vs copper to understand alloy-driven relationships.

Troubleshooting common issues

Missing symbol error: Verify coverage in Metals-API Supported Symbols; if unsupported, switch to proxy and document rationale.
Stale data: Ensure you respect update intervals; check your caching layer for overly long TTLs.
Inconsistent units: Confirm “unit” is “per troy ounce” in each response before inversion; add tests.
Rounding drift: Use a consistent decimal precision policy for display vs ledger calculations.

Validation checklist before going live

Does every response path validate success, timestamp, base, and unit?
Do you log and alert on symbol omissions or schema deviations?
Are inversion and unit conversions centralized in a single utility?
Are cache TTLs aligned to plan update cadence?
Is your API key stored server-side, rotated, and monitored?

Additional resources

Metals-API Documentation — complete endpoint references and usage details.
Metals-API Supported Symbols — verify BRSH and other metals coverage before coding.
Metals-API Website — get a free API key to start integrating today.
London Metal Exchange — for broader market context on industrial metals.
ISO 4217 currency codes — ensure correct currency identifiers.

Conclusion: shipping accurate BRSH per-ounce pricing into Node.js apps

With Metals-API, Node.js teams can deliver accurate per-ounce pricing for Brass Shell (BRSH) across currencies, power smart e-commerce, automate procurement decisions, and maintain audit-ready histories. The keys to success are clear unit handling (troy ounces), consistent inversion to USD/oz where needed, disciplined caching aligned to update frequencies, and transparent symbol validation via the Metals-API Supported Symbols. The combined use of Latest, Historical, Time-series, Convert, Fluctuation, OHLC, and Bid/Ask provides a complete toolbox for real-time quoting, backtesting, and risk management. Get started with a free key on the Metals-API Website and consult the Metals-API Documentation as you build.

FAQ

Does Metals-API support BRSH (Brass Shell) directly?
Check the Metals-API Supported Symbols. If unavailable, use a documented proxy and disclose methodology.
What unit are prices in?
By default, “per troy ounce.” Validate “unit” in every response and convert carefully for grams or kilograms.
How should I interpret rates values?
Rates are metal per 1 base currency unit. To get USD per ounce, invert the rate: price = 1 / rate.
How often are prices updated?
Depends on your subscription plan. Align your caching and polling to the documented update cadence.
How do I handle weekends and holidays?
Use the last available business day’s data; label UIs accordingly and reconcile when markets reopen.
Where do I get an API key?
Visit the Metals-API Website to create a free key and begin integration.

Ready to use Metals-API?

Try it now!