Get LME Tin (LME-TIN) prices with this simple API

LME Tin prices drive everything from electronics solder costs to hedging programs in manufacturing. If your use case is to price invoices off today’s LME Tin settlement, refresh a trading dashboard every few minutes, or backfill a time series for risk models, you can do all of it with a single, simple API: Metals-API. In this guide, we’ll show how to retrieve LME Tin (often referenced as LME-TIN) and spot Tin (XSN) data using a streamlined workflow, discuss practical implementation details developers tend to miss, and integrate the results into pricing, analytics, and ERP pipelines. Along the way, we’ll emphasize LME Tin’s market structure, units (troy ounces vs metric tons), timestamps, caching, and robust error handling so your integration is correct from day one.

Why an LME Tin API matters for developers and product teams

Tin is an essential input for electronics (especially solder), packaging, and chemicals. For quant teams, LME Tin is a volatile industrial metal with idiosyncratic supply risk. For manufacturers and jewelry components, accurate and timely Tin pricing directly impacts margin. An LME Tin API allows you to: (1) quote and reprice orders in real time, (2) sync ERP cost centers to market, (3) automate hedging triggers based on LME historical movements, (4) drive alerting, and (5) build historical datasets that fuel forecasting models. With Metals-API, you get a single, consistent JSON interface across metals, including Tin.

Main keyword focus: LME Tin API for real-time and historical price retrieval

In this article, we’ll center on the LME Tin API capabilities: retrieving latest Tin prices (spot XSN and LME historical), building time series, computing fluctuations, and converting between Tin units and currencies. We’ll also include implementation strategies for analytics, trading, fintech, and manufacturing applications.

Quick orientation: symbols, units, and base currency

Before you start coding, lock down three essentials that determine your calculations downstream:

• Symbols: Spot Tin is denoted as XSN. For LME-specific series, Metals-API provides an LME historical endpoint for LME symbols (e.g., LME-TIN). Always confirm availability and formatting at the Metals-API Supported Symbols page.
• Units: By default, exchange rates are quoted “per troy ounce” when you use standard endpoints returning spot-like rates. LME traditionally quotes many contracts in USD per metric ton (MT). You must convert units correctly to avoid major pricing errors.
• Base currency: Responses default to USD as the base (“base”: “USD”). You can convert to other currencies via the conversion endpoint.

Metals-API provides consistent JSON schemas across endpoints. You’ll see keys such as success, timestamp (UNIX seconds), base (default USD), date (ISO), and unit (e.g., “per troy ounce”). For LME historical series, you can access LME symbols going back to 2008 as available via the historical LME endpoint.

Core use case: price updates for a tin-linked product every 10 minutes

Suppose you maintain a B2B catalog where a solder alloy price is indexed to Tin plus a margin. The product team needs price refreshes every 10 minutes during market hours and daily close prices for audit. Your steps:

1. Pull the latest XSN rate (default per troy ounce, base USD).
2. Convert to your preferred unit (e.g., USD/kg or USD/MT) and currency (e.g., EUR).
3. Apply your formula: product price = (converted Tin benchmark + premium) × quantity.
4. Cache responses to avoid redundant API calls and throttle downstream updates.
5. At day’s end, store the close (OHLC endpoint) and reconcile cost-of-goods in ERP.

Everything above can be scheduled via a queue/worker and validated by comparing intraday vs daily close to detect anomalies. Let’s walk through the endpoints you’ll use and the implementation nuances that matter in production.

Authentication, base URL, and security

You pass your unique API key using an access_key parameter in the query string. Treat this as a secret and do not embed it in client-side code unless strictly necessary. Best practice:

• Store the key in a server-side environment variable.
• Proxy client requests through your backend, which adds the key and enforces quota and rate controls.
• Rotate keys periodically, especially if you suspect exposure.

Get started at the Metals-API Website and click through to create a free API key. Keep the Metals-API Documentation open as you integrate.

Latest Tin rate (XSN): real-time spot and practical caveats

The latest endpoint returns the most recent exchange rates for supported metals. Depending on your subscription plan, refresh frequency can be every 60 minutes, every 10 minutes, or faster. For Tin spot (XSN), this is the quickest way to get a current indicative price.

Example: latest request for Tin (XSN)

Use curl from your backend job:

curl -G https://metals-api.com/api/latest \
--data-urlencode "access_key=YOUR_ACCESS_KEY" \
--data-urlencode "symbols=XSN" \
--data-urlencode "base=USD"

Representative JSON response

{
"success": true,
"timestamp": 1789432070,
"base": "USD",
"date": "2026-09-15",
"rates": {
"XSN": 0.0325
},
"unit": "per troy ounce"
}

Field notes you will actually use:

• success: Boolean; check this before parsing anything else.
• timestamp: UNIX seconds; store it and convert to your reporting timezone if needed.
• base: Typically “USD”. If you request a different base, reflect this in downstream pricing logic.
• date: Calendar date associated with the price snapshot. This can differ from your local timezone’s date around midnight UTC.
• rates.XSN: The number of troy ounces of Tin you get for 1 USD, i.e., XSN per USD.
• unit: “per troy ounce” is a crucial cue for unit conversions.

Converting “per troy ounce” to USD/MT or USD/kg

Metals-API latest returns rates as metal-units per USD (e.g., troy ounces per 1 USD). To convert to USD per troy ounce, invert the rate. From there, convert to USD/kg or USD/MT.

• USD per troy ounce = 1 / rates.XSN
• 1 troy ounce = 31.1034768 grams
• USD per kilogram = (USD/oz_t) × (1 troy ounce / 0.0311034768 kg)
• USD per metric ton = USD/kg × 1000

Be explicit about units in logs, dashboards, and invoices. Mix-ups between troy ounces and avoirdupois ounces, or oz and kg/MT, are a common and costly source of error.

JavaScript example: fetch latest Tin, convert to USD/kg and USD/MT

// Server-side Node.js example (do not expose your key in client-side code)
import fetch from "node-fetch";

const ACCESS_KEY = process.env.METALS_API_KEY;

async function getTinPriceMetrics() {
const url = new URL("https://metals-api.com/api/latest");
url.searchParams.set("access_key", ACCESS_KEY);
url.searchParams.set("symbols", "XSN");
url.searchParams.set("base", "USD");

const res = await fetch(url.href, { timeout: 10000 });
if (!res.ok) {
throw new Error(`HTTP ${res.status}`);
}
const data = await res.json();

if (!data.success) {
throw new Error(`API error: ${JSON.stringify(data)}`);
}

const rateXsnPerUsd = data.rates?.XSN;
if (!rateXsnPerUsd || rateXsnPerUsd <= 0) {
throw new Error("Missing or invalid XSN rate");
}

// Convert XSN per USD to USD per troy ounce
const usdPerTroyOunce = 1 / rateXsnPerUsd;

// troy ounce to kilogram
const TROY_OUNCE_TO_KG = 0.0311034768;
const usdPerKg = usdPerTroyOunce / TROY_OUNCE_TO_KG;

// kilogram to metric ton
const usdPerMetricTon = usdPerKg * 1000;

return {
timestamp: data.timestamp,
date: data.date,
usdPerTroyOunce: Number(usdPerTroyOunce.toFixed(2)),
usdPerKg: Number(usdPerKg.toFixed(2)),
usdPerMetricTon: Number(usdPerMetricTon.toFixed(0)),
unitSource: data.unit, // "per troy ounce"
base: data.base
};
}

getTinPriceMetrics()
.then(console.log)
.catch(console.error);

Handling weekends and market closures

Industrial metals often see reduced activity or closures over weekends and certain holidays. The latest endpoint may return the last available tick or official close. Best practice:

• If the timestamp is older than N minutes during “live” hours, flag your UI and reference the age of data.
• For weekends, display the last official close and note the market status.
• Automate a daily EOD job that fetches OHLC data to store an authoritative “close.”

Historical LME Tin: building analytics, backtesting, and compliance records

For LME-specific tin history, Metals-API provides a historical LME endpoint with data available back to 2008 for supported LME symbols. This lets you backfill time series, run factor models, and create compliance archives of historical rates. Always consult the Metals-API Documentation for endpoint details and symbol availability. You can also confirm LME symbols in the Metals-API Supported Symbols list.

Example: request historical LME Tin for a specific date

The following illustrates the general pattern for fetching LME historical data for a symbol like LME-TIN on a chosen date:

curl -G https://metals-api.com/api/historical-lme \
--data-urlencode "access_key=YOUR_ACCESS_KEY" \
--data-urlencode "date=2024-12-02" \
--data-urlencode "symbols=LME-TIN" \
--data-urlencode "base=USD"

Representative JSON response (historical LME)

{
"success": true,
"base": "USD",
"date": "2024-12-02",
"rates": {
"LME-TIN": {
"close": 24350.0,
"unit": "per metric ton"
}
}
}

What matters to your application:

• rates["LME-TIN"].close: The daily close you can store as the authoritative EOD price.
• unit: LME historical data often aligns with LME quoting conventions such as “per metric ton.” Always check and harmonize with your internal units.
• date: Align this date with your accounting period close; consider timezone when persisting.

Common use cases:

• Backfill last 3 years of daily closes for model features or benchmark indices.
• Compute rolling volatilities, drawdowns, and VaR using LME-specific time series.
• Reconcile invoices and hedge settlements to historical closes stored in your data lake.

Time-series data for Tin: from baselining to anomaly detection

The time-series endpoint returns daily historical rates between two dates for supported symbols. This is useful for baselining, trend analysis, and building ML features.

Example: time-series request for Tin (spot XSN) across a range

curl -G https://metals-api.com/api/timeseries \
--data-urlencode "access_key=YOUR_ACCESS_KEY" \
--data-urlencode "start_date=2026-09-08" \
--data-urlencode "end_date=2026-09-15" \
--data-urlencode "base=USD" \
--data-urlencode "symbols=XSN"

Representative JSON response

{
"success": true,
"timeseries": true,
"start_date": "2026-09-08",
"end_date": "2026-09-15",
"base": "USD",
"rates": {
"2026-09-08": {
"XSN": 0.0326
},
"2026-09-10": {
"XSN": 0.0324
},
"2026-09-15": {
"XSN": 0.0325
}
},
"unit": "per troy ounce"
}

Implementation tips:

• Not all days will be present (weekends/holidays). Your code should handle gaps.
• Normalize all series to a canonical unit in your warehouse (e.g., USD/MT). Store both raw and normalized forms.
• Ensure idempotency when backfilling; use upserts keyed by symbol+date.

Fluctuation: quantify short-term moves for alerts and risk

Use the fluctuation endpoint to compute period-over-period changes and percentages across your chosen window. This is ideal for triggers (e.g., escalate if LME Tin moves more than 2% day-over-day).

Example: fluctuation request for Tin (XSN)

curl -G https://metals-api.com/api/fluctuation \
--data-urlencode "access_key=YOUR_ACCESS_KEY" \
--data-urlencode "start_date=2026-09-08" \
--data-urlencode "end_date=2026-09-15" \
--data-urlencode "base=USD" \
--data-urlencode "symbols=XSN"

Representative JSON response

{
"success": true,
"fluctuation": true,
"start_date": "2026-09-08",
"end_date": "2026-09-15",
"base": "USD",
"rates": {
"XSN": {
"start_rate": 0.0326,
"end_rate": 0.0325,
"change": -0.0001,
"change_pct": -0.31
}
},
"unit": "per troy ounce"
}

Key fields:

• start_rate and end_rate: Use these to derive absolute changes in your normalized units if needed.
• change_pct: Pre-computed for convenience; useful for alerting thresholds.

OHLC: reliable opens, highs, lows, and closes

For charting and EOD reconciliation, the OHLC endpoint returns open, high, low, and close for a given date. This gives you a consistent snapshot to store in your warehouse and feed BI tools.

Example: OHLC request for Tin (XSN)

curl -G https://metals-api.com/api/open-high-low-close/2026-09-15 \
--data-urlencode "access_key=YOUR_ACCESS_KEY" \
--data-urlencode "base=USD" \
--data-urlencode "symbols=XSN"

Representative JSON response

{
"success": true,
"timestamp": 1789432070,
"base": "USD",
"date": "2026-09-15",
"rates": {
"XSN": {
"open": 0.0326,
"high": 0.0328,
"low": 0.0323,
"close": 0.0325
}
},
"unit": "per troy ounce"
}

Use cases:

• Save an immutable EOD snapshot for audit and financial statements.
• Drive candlestick charting in dashboards.
• Detect intraday range breakouts to feed strategy logic or notifications.

Bid/Ask: spreads and execution-aware pricing

When available for your subscription level, the bid and ask endpoint provides bid, ask, and spread. Use this to minimize slippage in your pricing algorithms, especially if you apply markups or perform hedging near-real-time.

Example: bid/ask request for Tin (XSN)

curl -G https://metals-api.com/api/bid-ask \
--data-urlencode "access_key=YOUR_ACCESS_KEY" \
--data-urlencode "base=USD" \
--data-urlencode "symbols=XSN"

Representative JSON response

{
"success": true,
"timestamp": 1789432070,
"base": "USD",
"date": "2026-09-15",
"rates": {
"XSN": {
"bid": 0.0324,
"ask": 0.0326,
"spread": 0.0002
}
},
"unit": "per troy ounce"
}

How to use:

• Invert bid/ask to get USD/oz bid/ask for execution-aware quotes.
• Use spread to adapt your margin dynamically when markets widen.

Convert: currency and cross-metal conversions

The conversion endpoint is your utility knife for monetary conversions: USD to XSN, XSN to USD, or cross-currency conversions for pricing in customer-local currencies.

Example: convert 1000 USD to Tin (XSN)

curl -G https://metals-api.com/api/convert \
--data-urlencode "access_key=YOUR_ACCESS_KEY" \
--data-urlencode "from=USD" \
--data-urlencode "to=XSN" \
--data-urlencode "amount=1000"

Representative JSON response

{
"success": true,
"query": {
"from": "USD",
"to": "XSN",
"amount": 1000
},
"info": {
"timestamp": 1789432070,
"rate": 0.0325
},
"result": 32.5,
"unit": "troy ounces"
}

Practical notes:

• If you need a result in kilograms or metric tons, convert the result from troy ounces accordingly.
• For multi-currency catalogs, chain a currency conversion with your Tin conversion to present localized prices.

Intraday: higher-frequency snapshots when you need finer granularity

For strategies and dashboards that need more frequent updates for a single symbol, the intraday endpoint provides higher-frequency snapshots for that symbol, subject to plan limits. This is useful for live tiles and execution-sensitive workflows. Treat intraday as transient; persist only the aggregates you need.

Example: intraday request for Tin (XSN)

curl -G https://metals-api.com/api/intraday \
--data-urlencode "access_key=YOUR_ACCESS_KEY" \
--data-urlencode "symbols=XSN" \
--data-urlencode "base=USD"

Representative JSON response (truncated for clarity)

{
"success": true,
"base": "USD",
"symbol": "XSN",
"unit": "per troy ounce",
"data": [
{ "timestamp": 1789431600, "rate": 0.03255 },
{ "timestamp": 1789431900, "rate": 0.03252 },
{ "timestamp": 1789432200, "rate": 0.03250 }
]
}

Recommendations:

• Apply rate-limiting and caching to avoid unnecessary repeated calls.
• Downsample for charts to avoid overwhelming your UI with points.
• Store only summarized bars unless you need tick-by-tick backtesting.

Lowest/Highest and analytics-friendly features

For quick range calculations, the lowest-highest endpoint lets you query the minimum and maximum over a specified date. This is handy for context in dashboards and sanity checks for alerts.

Example: get lowest and highest for Tin (XSN) on a date

curl -G https://metals-api.com/api/lowest-highest/2026-09-15 \
--data-urlencode "access_key=YOUR_ACCESS_KEY" \
--data-urlencode "base=USD" \
--data-urlencode "symbols=XSN"

Representative JSON response

{
"success": true,
"base": "USD",
"date": "2026-09-15",
"rates": {
"XSN": {
"lowest": 0.0323,
"highest": 0.0328
}
},
"unit": "per troy ounce"
}

Use it to:

• Annotate intraday charts with daily extremes.
• Compute range-based signals without extra client-side processing.

Practical architecture: how to wire Metals-API into your stack

A typical integration pattern for LME Tin and spot Tin looks like this:

1. Ingress: A cron or scheduler (e.g., every 10 minutes during market hours; once daily for OHLC) triggers a backend job.
2. Fetch layer: Server-side service calls the latest, OHLC, and, if needed, LME historical endpoints. All calls include the access_key securely.
3. Normalization: Convert all Tin values to canonical units (e.g., USD/MT) and store the raw JSON response for audit.
4. Caching: Layered caching with a short TTL (e.g., 60–600 seconds) prevents redundant hits.
5. Storage: Persist normalized series in a time-series database or warehouse. Use symbol+date as composite keys.
6. Serving: GraphQL/REST service exposes Tin pricing to ERP/web apps with consistent schemas.
7. Monitoring: Alerts fire if timestamp age exceeds thresholds or if spreads widen abruptly.

Caching and performance optimization

• Client-side caching: Avoid; keep secrets server-side.
• Server-side caching: Memcached/Redis per endpoint+params with conservative TTL aligned to your plan’s update frequency.
• Stale-while-revalidate: Serve cached data and refresh in the background when TTL expires.
• Batching: Request multiple symbols in one call when it reduces total traffic (e.g., XSN plus other metals you show together).
• Backoff: If you observe errors or rate limit responses, implement exponential backoff and jitter.

Error handling and recovery strategies

• Check success: Always branch on success before reading fields.
• HTTP vs API errors: Distinguish HTTP status errors from JSON-level errors (success=false).
• Graceful degradation: If latest fails, show the last cached EOD close with a stale badge. Log and notify.
• Validation: Reject negative or zero rates; log anomalies for inspection.
• Idempotency: Use deterministic keys for storage to prevent duplicates when retrying.

Data validation and sanitization

• Strict schema checks: Validate presence and types of timestamp, base, unit, and rates fields.
• Unit normalization: Do not mix per troy ounce with per metric ton. Store the unit alongside each value.
• Timezone handling: Convert timestamp to UTC internally; only localize at the UI layer.
• Rounding rules: Define bank-grade rounding when presenting prices or calculating invoices.

Security considerations

• Secret storage: Keep access_key in environment variables or a KMS/secret manager.
• Network: Make calls only from your backend over HTTPS.
• Least privilege: If you proxy requests, restrict endpoints the proxy can call.
• Monitoring: Alert on unusual request volume or repeated failures.

Real-world scenarios and implementation playbooks

1) ERP dynamic cost updates for solder production

Use latest XSN to compute USD/kg and push to ERP cost tables every 10 minutes. Cache for 5 minutes to reduce volume. At EOD, store OHLC close for audit and roll over your BOM standard cost at midnight UTC. If currency exposure exists (e.g., costs in EUR), use convert to localize prices.

2) Hedging triggers and execution windows

Pull bid/ask to compute execution-aware triggers (e.g., average of inverted bid/ask in USD/MT). Fire alerts if the fluctuation endpoint signals a >2% daily move, then confirm with intraday snapshots before executing hedges. Record LME-TIN historical close for post-trade analysis.

3) Research: forecasting with LME Tin time series

Backfill LME-TIN historical closes into a warehouse. Use time-series XSN for cross-checking with spot-like references. Normalize all data to USD/MT. Compute rolling features and feed into forecasting pipelines. Persist raw JSON responses for provenance and repeatability.

About Tin (XSN): technology, digital transformation, and analytics

Tin’s industrial relevance has accelerated alongside electronics miniaturization and the shift to lead-free solders. The digital transformation of metal markets now brings developer-grade APIs that unify access to Tin prices and metadata under consistent JSON schemas. This unlocks measurable gains:

• Technological innovation: Real-time feeds enable adaptive pricing, API-first trading tools, and composable analytics services.
• Data analytics and insights: Time-series analysis across XSN and LME-TIN clarifies supply shocks, seasonal patterns, and volatility regimes.
• Smart technology integration: Embed Tin pricing in IoT-connected production lines to recalibrate consumption plans or reorder points when prices move.
• Future trends: Expect richer intraday granularity, expanded LME coverage, and tighter integrations with order management and hedging platforms.

Choosing symbols and aligning them to your use case

Purpose	Symbol	Endpoint emphasis	Typical unit
Spot-like Tin reference for indicative pricing	XSN	latest, timeseries, fluctuation, OHLC, intraday	per troy ounce (default)
LME-specific daily closes for hedging, compliance	LME-TIN	historical LME endpoint	often per metric ton

Always confirm supported symbols at the Metals-API Supported Symbols page. If your downstream logic expects MT, convert spot outputs and store a normalized series to avoid confusion.

Handling base currencies and cross-currency pricing

• Default base is USD. If your catalog is in EUR, either request EUR base where supported or convert post-fetch using the convert endpoint.
• When displaying prices to end users, round at the last step to minimize cumulative rounding error.
• If you quote customers in their local currency, snapshot the FX rate alongside the Tin rate for full auditability.

Timestamps, dates, and timezone strategy

• timestamp: UNIX seconds; store raw value and convert to UTC in your warehouse.
• date: ISO date string; align to your accounting timezone only in reporting.
• EOD logic: Drive EOD processes by UTC to keep calculations unambiguous, then present localized dates in BI tools.

Comparing endpoints and selecting the right tool for the job

• latest: Real-time updates for dashboards and pricing tiles.
• historical LME: Authoritative daily closes for LME Tin-backed models and accounting.
• timeseries: Bulk-in historical daily values for statistical analysis.
• fluctuation: Quick pct-change for alerting and risk thresholds.
• OHLC: EOD candlestick components, useful for visualization and data hygiene.
• bid/ask: Execution-aware pricing and spread management.
• intraday: Higher-frequency snapshots to monitor market conditions.
• convert: Currency and cross-asset conversions for pricing and localization.

Troubleshooting common pitfalls

• Unit mix-ups: If numbers look off by ~32x or ~1000x, check troy ounce vs kilogram vs metric ton conversions.
• Missing days: Weekends and holidays will produce gaps; forward-fill for charts but never for accounting.
• Time drift: If timestamp is older than expected, display “last updated” and trigger a background refresh.
• Zero or null rates: Validate and retry; if persistent, fall back to last good value with a stale indicator.
• API key exposure: Audit client apps and public repos for accidental key leaks; rotate immediately if found.

Performance, scaling, and cost awareness

• Request consolidation: Fetch multiple symbols where supported to amortize overhead.
• Adaptive polling: During low-volatility windows, lengthen polling intervals; shorten when spread widens.
• Warehouse writes: Buffer writes and batch insert to reduce I/O overhead on high-frequency jobs.
• Compression and storage: Keep raw JSON for audit but compress and segment by date for efficient retrieval.

Security, governance, and audit trails

• Access controls: Limit who can run backfills or rotate keys.
• Provenance: Store raw responses with headers/timestamps for post-event audit.
• Data retention: Set policies for how long you keep intraday vs EOD data.

Putting it all together: end-to-end example flow

1. Scheduler triggers latest XSN fetch every 10 minutes; cache for 5 minutes.
2. Normalize to USD/MT and push to ERP for dynamic pricing.
3. At market close, call OHLC for XSN; store open/high/low/close normalized to USD/MT.
4. Nightly job fetches historical LME-TIN close for the day and stores alongside OHLC spot figures.
5. Alerting service uses fluctuation over the last 7 days to recalibrate price buffers and hedging thresholds.
6. Monthly, backfill any missed days via time-series and reconcile.

Practical guidance a beginner might miss

• Document your conversion constants (troy ounce to gram, kg, MT) in a single module shared across services.
• Annotate every stored value with unit, base currency, symbol, and source endpoint.
• Use feature flags to switch from spot-based pricing to LME close if a compliance rule triggers.
• Forecasting: Detrend and seasonally adjust LME Tin; keep spot and LME series separate to avoid leakage.

Where to learn more and get started

• Sign up for a key at the Metals-API Website and start testing in minutes.
• Browse the full endpoint options and parameters in the Metals-API Documentation.
• Verify all symbols, including XSN and LME variants, at the Metals-API Supported Symbols page.

Additional resources

• LME Tin contract overview for contract specs and market notes.
• BIS statistics for macro background that can influence commodity prices.
• ISO standards on weights and measures to align unit conversions with standards.

Conclusion

With a single integration to Metals-API, you can retrieve and operationalize LME Tin and spot Tin data across your products: live pricing, ERP updates, hedging triggers, and rich historical analysis. The key to getting Tin right is unit discipline (troy ounces vs kilograms vs metric tons), consistent base currency handling, robust timestamp logic, and careful caching. From intraday monitoring to historical LME closes back to 2008 (for supported symbols), Metals-API delivers the structured, developer-friendly building blocks you need to modernize metal pricing in fintech, trading, jewelry, electronics, and manufacturing workflows. Get your free key at the Metals-API Website and start building today, and keep the Metals-API Documentation handy as you refine your integration.

FAQ

What symbol should I use for Tin?

Use XSN for spot Tin in the standard endpoints. For LME-specific history, use the historical LME endpoint with the appropriate LME symbol (e.g., LME-TIN). Check the Metals-API Supported Symbols to confirm availability and exact names.

Are prices in USD by default?

Yes, USD is the default base. You can use the convert endpoint to translate to other currencies.

What units are returned?

Most standard endpoints (e.g., latest, OHLC, timeseries) return “per troy ounce” when quoting metal units relative to the base currency. LME historical data may be listed per metric ton. Always check and convert units consistently.

How do I handle weekends and holidays?

Expect gaps for non-trading days. Use the timestamp and date fields to determine data freshness. For dashboards, display the last available close and annotate the market status.

Can I get bid/ask for Tin?

Depending on your plan, the bid-ask endpoint provides bid, ask, and spread for supported symbols. Use this to build execution-aware pricing and manage margins during volatile periods.

How should I store Tin data?

Persist both the raw JSON response (for audit) and normalized values (e.g., USD/MT) with explicit unit and currency fields. Use symbol+date as a composite key for daily series and timestamped keys for intraday data.

Where do I get help and examples?

Start with the Metals-API Documentation. For symbol reference, use the Metals-API Supported Symbols. To obtain a key and explore plans, visit the Metals-API Website.