API to Get the Trichy Silver (TRIC-XAG) Price — Spot and Historical Endpoints

You need the Trichy city silver price (TRIC-XAG) to power a live checkout, auto-reprice inventory, or backfill a city-specific chart. By the end of this guide you’ll be able to query the API, understand why TRIC-XAG behaves differently from global XAG spot, handle the restricted-symbols error correctly, and know exactly which endpoints to use for spot and historical data.

What TRIC-XAG Represents and How It Differs from Global XAG

TRIC-XAG denotes a city-referenced silver price for Trichy (Tiruchirappalli), India. This is distinct from the global silver benchmark symbol XAG. Because city-referenced Indian symbols are curated differently, they are not served by the generic market endpoints used for global metals.

As a result, requests that include TRIC-XAG to generic endpoints like latest or historical will return a restricted-symbols error. That error is the API telling you to use the dedicated India pricing endpoint for city symbols. We’ll show you the exact error so your integration can handle it cleanly.

For a full list of available symbols (including whether a code like TRIC-XAG is supported), check the up-to-date catalog at Metals-API Supported Symbols.

Two common goals: live Trichy silver and historical series

Teams typically aim to do one of two things:

• Fetch a live, city-referenced TRIC-XAG price for real-time pricing, hedging, or alerts.
• Backfill a TRIC-XAG historical series to chart trends, calibrate pricing models, or compute volatility.

Both needs are supported, but TRIC-XAG must be accessed via the dedicated endpoint for Indian city metals rather than the generic latest/historical endpoints. If you call the generic endpoints with TRIC-XAG, you will see the following error payload.

Working example: calling latest with TRIC-XAG and handling the restricted-symbols error

Use this call to validate your connectivity and key. It demonstrates the exact error you must handle when passing TRIC-XAG to the generic latest endpoint.

curl "https://metals-api.com/api/latest?access_key=YOUR_API_KEY&symbols=TRIC-XAG"

Official response you should expect if you query TRIC-XAG at this endpoint:

{"success":false,"error":{"code":403,"type":"restricted_symbols","info":"The specified symbols are restricted to the gold-price-india endpoint only.","restricted_symbols":["TRIC-XAG"],"endpoint_required":"\/api\/gold-price-india","message":"Indian gold city symbols can only be used with the \/api\/gold-price-india endpoint."}}

What you’ll actually use from this response:

• error.code: 403 — treat as a permanent error for this endpoint/symbol combination (do not retry).
• error.type: "restricted_symbols" — the failure class; route to a symbol/endpoint compatibility path.
• error.restricted_symbols: ["TRIC-XAG"] — confirms which symbol triggered the restriction.
• error.endpoint_required: "/api/gold-price-india" — the endpoint family you must switch to for TRIC-XAG.
• error.message/info: human-readable guidance; safe to display in logs or in tooling UX.

Production-grade error handling in Python

The snippet below calls the same endpoint as the cURL example, inspects the error, and shows a clean way to steer your app toward the correct endpoint for TRIC-XAG.

import os
import requests

API_KEY = os.getenv("METALS_API_KEY", "YOUR_API_KEY")
URL = "https://metals-api.com/api/latest"
params = {
    "access_key": API_KEY,
    "symbols": "TRIC-XAG"  # City-referenced Indian symbol
}

resp = requests.get(URL, params=params, timeout=10)
data = resp.json()

if not data.get("success", False):
    err = data.get("error", {})
    if err.get("type") == "restricted_symbols" and "TRIC-XAG" in err.get("restricted_symbols", []):
        # Route the request to the dedicated India pricing endpoint in your application.
        # Keep logic centralized so you can support multiple Indian city symbols consistently.
        print("TRIC-XAG must be requested via:", err.get("endpoint_required"))
        # Example handling:
        # next_url = "https://metals-api.com" + err.get("endpoint_required")
        # ... build your request for TRIC-XAG using the dedicated endpoint per the docs ...
    else:
        raise RuntimeError(f"Metals-API error: {err.get('message') or err}")
else:
    # This block will not run for TRIC-XAG on /api/latest. For global XAG it would.
    rates = data["rates"]
    print(rates)

Key takeaway: your integration should detect error.type == "restricted_symbols" and automatically route TRIC-XAG to the dedicated India pricing endpoint indicated by endpoint_required. Keep this routing table configurable so you can easily add more Indian city symbols later.

Which endpoints to use for spot and historical price retrieval

For global silver (XAG), you would normally use:

• latest — for spot-like updates
• historical — for day-by-day snapshots
• time-series — for a date range of daily closes

However, for TRIC-XAG specifically, the error envelope above tells you the symbol is restricted and must be queried via a dedicated endpoint for Indian city pricing. That’s the path to both spot and historical TRIC-XAG. Refer to the endpoint guidance in the Documentation and confirm symbol availability in the Symbols list before coding.

Units, base currency and inversion for pricing math

When you work with silver, watch three details that routinely trip up integrations:

• Unit: Metals-API quotes metal rates “per troy ounce” unless otherwise noted. 1 troy ounce = 31.1034768 grams.
• Base: By default, rates are relative to USD. With base=USD, a rate like rates.XAG is “troy ounces per 1 USD.”
• Inversion: If you need USD per troy ounce, compute 1 / rates.XAG. This is especially important if you’re comparing local-market quotes expressed in currency-per-ounce versus ounces-per-currency from the API.

If you’re combining city-referenced TRIC-XAG with global series or with your ERP’s local currency, make sure you normalize to a single unit and base (e.g., USD/oz) first, then apply conversions downstream.

Silver in manufacturing and smart supply chains: why TRIC-XAG matters

Silver’s conductivity, reflectivity, and antimicrobial properties make it a key input in electronics, photovoltaics, automotive components, and medical devices. Procurement teams in India often benchmark against city-referenced prices to match local logistics costs, making TRIC-XAG useful for smart manufacturing and supply chain systems that reprice bills of material, renegotiate supplier quotes, and hedge exposures.

In a digital manufacturing stack—ERP, MES, procurement bots, and pricing engines—you can use TRIC-XAG to keep factory-to-customer quotes aligned with local market conditions. Integrating the correct endpoint and handling symbol restrictions programmatically helps avoid stale pricing or silent failures in pricing microservices.

Practical implementation guidance that saves time

• Time and timezone: Timestamps returned by the API are Unix epoch seconds. Treat them as UTC unless specified in the endpoint’s docs.
• Weekend/holiday handling: Metals markets and localized city quotes may not update on weekends or specific local holidays. Cache the most recent value and display “as of” timestamps in UI.
• Caching and request budgets: Cache successful responses for short intervals (e.g., 30–60 seconds for spot-like data, longer for historical) to reduce calls and improve page performance.
• Symbol validation: At startup, fetch the symbol catalog and validate the presence of TRIC-XAG. Fail fast in CI/CD if symbols you depend on are missing or restricted.
• Error routing: Centralize handling for error.type == restricted_symbols. The error payload includes endpoint_required to guide your reroute logic.
• Consistent units: Convert everything to one canonical measure (USD/oz is common) before computing revenue recognition, COGS, or price quotes. Remember: per-USD rates must be inverted to USD-per-oz.
• Monitoring: Alert on sudden gaps (no new timestamps when you expect them) and on repeating restricted_symbols errors that suggest misrouted requests.

About plans, access, and getting your key

There is no free trial. If you’re working with copper heavy workloads, note that Copper Monthly is $19.99/mo. For city-referenced silver like TRIC-XAG, choose a plan that covers the endpoints you’ll call and the update cadence your product needs. You can sign up for an API key here: Register.

If you plan to deploy quant screens, batch backfills, or distributed workers, review the platform options here: MCP.

Endpoint references and symbol catalog

For TRIC-XAG, remember that the generic latest/historical family is not the correct path—your code must route to the dedicated Indian pricing endpoint. Review the endpoint specifics and parameters here:

• Documentation — endpoint specs, parameters, response fields, and usage notes.
• Symbols — check if TRIC-XAG and related city symbols are currently listed.

For market context and model validation, you may also find these resources helpful:

• LBMA precious metal benchmarks — independent reference prices for precious metals.
• CME Silver futures — for futures-based hedging and price discovery correlation studies.

From raw API to production: a minimal workflow

To ship a reliable TRIC-XAG integration into your trading tool, ERP, or e-commerce platform, consider this minimal workflow:

1. Symbol check at startup: Assert TRIC-XAG is present and flagged as a city symbol in your symbol map.
2. Route build: If the symbol is a city-referenced Indian symbol, select the dedicated India endpoint; otherwise use generic endpoints for global XAG.
3. Fetch and cache: Cache the latest value with a timestamp and unit metadata (“per troy ounce,” base USD).
4. Normalize: Convert to a single pricing basis (e.g., USD/oz) for all downstream math.
5. Fallback policy: On restricted_symbols errors, do not retry the same endpoint; route to the required endpoint per error.endpoint_required.
6. Historical backfill: Use the India endpoint’s historical capability for TRIC-XAG; store as daily bars with timezone and source notes.
7. Observability: Log error.type, endpoint, symbol, and timestamp for every failure to speed up support and incident response.

FAQ

Q: Why does my TRIC-XAG call to /api/latest fail while XAG works?
A: TRIC-XAG is a city-referenced Indian symbol and is restricted from generic endpoints. The error payload includes endpoint_required pointing to the dedicated India pricing endpoint. Route your request there.

Q: How do I convert the API’s silver rate to USD per troy ounce?
A: With base=USD, rates.XAG is ounces per 1 USD. Compute USD per ounce as 1 / rates.XAG. Keep units consistent across your app (USD/oz is common). 1 troy oz = 31.1034768 g if you need grams.

Q: Can I get historical TRIC-XAG for charts?
A: Yes, but not via the generic historical/time-series endpoints. Use the dedicated India pricing endpoint family as indicated by the error.endpoint_required field and check the date range in the Documentation.

Q: Does Metals-API offer a free trial?
A: No. Choose a plan that includes the endpoints you need. Copper Monthly is $19.99/mo; review plans and register to get your key.

Q: How should I handle weekends and local holidays?
A: Expect fewer or no updates on non-trading days. Cache the most recent value and display an “as of” timestamp in UI. For batch jobs, treat unchanged timestamps as normal during closures.

Ready to integrate TRIC-XAG into your pricing or analytics workflow? Get your key now and start building: Register. If you need to operationalize workloads at scale, review platform options here: MCP.