Historical Kyrgyzstani Som (KGS) - N/A Prices: Daily Close Data for API Integration
You need daily closing Kyrgyzstani som (KGS) rates you can pipe into charts, P&L, or pricing logic—and you want them programmatically, with clean inversion to USD/KGS when needed. By the end of this guide you’ll be able to pull historical and time-series close data for KGS from Metals-API, normalize and invert it to the quote you require, and handle practical pitfalls like base currency, timestamps, and non-trading days.
What “daily close” for KGS means in this workflow
Metals-API returns end-of-day snapshots keyed by a UTC date and a UNIX timestamp. For KGS (a fiat currency), the core field is the exchange rate quoted relative to the base currency. By default, the base is USD, so:
- rates.KGS = KGS per 1 USD (KGS/USD)
- rates.USDKGS = USD per 1 KGS (USD/KGS), when available as a synthetic symbol
This makes it straightforward to drive two common use cases:
- Display KGS closes against USD on a daily chart (KGS per USD).
- Convert USD metal prices into local KGS without rounding slippage by using the synchronized close.
If you care about metal pricing locally, you’ll typically do: metal price in USD per troy ounce × KGS per USD = KGS per troy ounce. For this article we stay focused on the currency leg (KGS), since that’s what your title and integration require. If you need compatible metal symbols, check the catalog via the Metals-API Supported Symbols.
Endpoints to use for KGS daily close data
To integrate daily KGS closes and backfill history with sane request economics, you’ll primarily use:
- Latest: for today’s close snapshot when available.
- Historical: for a specific past date (single day backfill).
- Time-series: for contiguous daily closes between two dates (bulk backfill).
All three return the same structure: a base currency (default USD), a UNIX timestamp, and a date string (UTC). For parameter details, see the Metals-API Documentation. If you haven’t generated a key yet, get one here: Register.
Quick start: fetch the latest KGS close
Use the latest endpoint and request KGS. If you also need the inverted USDKGS quote, ask for that symbol too so you don’t have to invert client-side.
curl "https://metals-api.com/api/latest?access_key=YOUR_API_KEY&symbols=KGS,USDKGS"
Example of an official JSON response structure you will see for KGS/USD on the latest (values shown below come from a valid Metals-API response and are included here verbatim so you can map fields):
{"success":true,"timestamp":1791540480,"date":"2026-10-09","base":"USD","rates":{"KGS":87.45,"USD":1,"USDKGS":0.011435105774728416}}
What you’ll actually use from the response:
- success: boolean gate. Check this first.
- timestamp: UNIX seconds for the pricing snapshot (UTC). Useful for cache keys and data alignment.
- date: ISO date (UTC) corresponding to the daily close.
- base: USD here. If you don’t change it, interpret rates as “per 1 USD.”
- rates.KGS: KGS per 1 USD (KGS/USD).
- rates.USDKGS: USD per 1 KGS (USD/KGS), when included.
Build historical KGS daily close series
If you need yesterday’s close only, call the historical endpoint with a specific date. For a fuller backfill (for example last year of daily closes), use the time-series endpoint. Both return dates in UTC; if your charts use a local timezone, normalize during ingest to avoid “off-by-one” on the x-axis.
Historical (single date) request
Pattern (do not include braces literally): GET /YYYY-MM-DD?access_key=...&symbols=KGS. This is convenient for point backfills or reconciliations.
Example:
curl "https://metals-api.com/api/2026-10-08?access_key=YOUR_API_KEY&symbols=KGS"
Parse the same core fields: success, timestamp, base, date, and rates.KGS.
Time-series (bulk) request
Pattern: GET /timeseries?access_key=...&start_date=YYYY-MM-DD&end_date=YYYY-MM-DD&symbols=KGS. This is optimal for batch backfills and for daily ETL runs that roll the window forward.
Example:
curl "https://metals-api.com/api/timeseries?access_key=YOUR_API_KEY&start_date=2026-09-01&end_date=2026-10-09&symbols=KGS"
The response includes an object keyed by date with rates.KGS for each business day in range. On weekends and market closures, don’t assume every calendar date will appear. You should:
- Accept sparse dates (only the days the service publishes closes).
- Optionally forward-fill missing dates on the application side if your chart requires a continuous calendar series (tag the forward-filled points distinctly if needed).
See request/response field definitions in the Documentation.
Code: fetch and normalize daily KGS closes
The following JavaScript snippet downloads a time-series for KGS, normalizes to both directions (KGS/USD and USD/KGS), and prepares an array ready for charting or storage.
async function fetchKgsTimeseries({ apiKey, startDate, endDate }) {
const url = new URL("https://metals-api.com/api/timeseries");
url.searchParams.set("access_key", apiKey);
url.searchParams.set("start_date", startDate); // YYYY-MM-DD (UTC)
url.searchParams.set("end_date", endDate); // YYYY-MM-DD (UTC)
url.searchParams.set("symbols", "KGS"); // request KGS per USD
const res = await fetch(url.toString(), { method: "GET" });
if (!res.ok) {
throw new Error(`HTTP ${res.status}: ${await res.text()}`);
}
const data = await res.json();
if (!data.success) {
// Metals-API includes error details when success=false
const msg = data.error ? `${data.error.type || "error"}: ${data.error.info || ""}` : "Unknown API error";
throw new Error(msg);
}
// Data layout: data.rates[date].KGS = KGS per 1 USD
// For some cases you'll prefer USD per 1 KGS (the inverse).
const rows = [];
const dates = Object.keys(data.rates || {}).sort();
for (const d of dates) {
const bySymbol = data.rates[d] || {};
const kgsPerUsd = bySymbol.KGS;
if (typeof kgsPerUsd !== "number") continue;
const usdPerKgs = 1 / kgsPerUsd; // invert when USDKGS is not explicitly requested
rows.push({
date: d, // ISO date in UTC
base: data.base || "USD",
kgs_per_usd: kgsPerUsd, // KGS/USD
usd_per_kgs: usdPerKgs // USD/KGS
});
}
return rows;
}
// Example usage:
// fetchKgsTimeseries({ apiKey: "YOUR_API_KEY", startDate: "2026-09-01", endDate: "2026-10-09" })
// .then(rows => console.log(rows.slice(0, 5)))
// .catch(console.error);
Notes:
- You can also request symbols=KGS,USDKGS on latest/historical endpoints to avoid inversion, but for time-series it’s common to request KGS only and invert client-side.
- Use the UNIX timestamp and date strings from responses for deterministic caching and reconciliation.
Converting between KGS/USD and USD/KGS
There are three practical ways to get the quote direction you need:
| Method | What you request | What you get | Pros | Cons |
|---|---|---|---|---|
| Direct KGS (default base USD) | symbols=KGS | rates.KGS = KGS per 1 USD | Simple, minimal payload | Requires inversion if you want USD per KGS |
| Direct USDKGS | symbols=USDKGS | rates.USDKGS = USD per 1 KGS | No inversion error, cleaner for pricing UIs | Not all flows request it by default; add to symbols list |
| Client-side inversion | symbols=KGS, compute 1/values | Derived USD per 1 KGS | One symbol fetch, reproducible math | Watch for division by zero and numeric precision |
If your application prices metals locally (e.g., USD gold price → KGS), always use the same “close” snapshot for both the metal leg and the KGS leg to avoid stale-cross issues. Retrieve both legs for the same date (same timestamp) and multiply appropriately.
Caching, scheduling, and non-trading days
To keep request counts low and guarantee deterministic outputs across services:
- Cache by (endpoint, base, symbols, date range) and, where present, by timestamp.
- For daily jobs, schedule once prices are published for the UTC day. If you need regional close alignment, normalize post-ingest using the date string and timestamp.
- Expect sparse dates on time-series across weekends and holidays. Your ETL should not assume every calendar date appears. Fill as needed in your analytics layer.
- If you only need the last close throughout the day, don’t refetch repeatedly. Cache the daily latest payload keyed by its timestamp until it changes.
Units, base currency, and metals context
For fiat symbols like KGS, there is no metal unit in the payload; you’re dealing strictly with currency rates. By default base=USD, meaning rates are “units of X per 1 USD.” For metal symbols, Metals-API returns rates relative to USD per troy ounce vs. metals per 1 USD depending on symbol conventions; verify each symbol on the Supported Symbols page and align your multiplication accordingly when converting to KGS. Keep a single unit system in your datastore (e.g., store all metals as USD/oz, all FX as quote/base) and derive alternates on read.
Production checklist for KGS daily close integrations
- Key management: Store your Metals-API key in a secure secret manager; do not hardcode.
- Request scoping: Only request the symbols you need (e.g., KGS or KGS,USDKGS).
- Error handling: Always check success; log and alert on any API error payloads.
- Idempotent ETL: Drive daily imports by date; re-run safely without duplicates by using primary keys like (date, symbol, base).
- Numerics: Use decimal types when persisting to databases to avoid binary float rounding drift, especially after inversions.
- Monitoring: Track gaps in time-series (weekends/holidays) and set expectations in front-ends.
End-to-end example: latest KGS close with inversion
This short Python sample fetches the latest KGS close and returns both directions (KGS/USD and USD/KGS) in one object for downstream consumers.
import os
import requests
def latest_kgs(api_key: str):
url = "https://metals-api.com/api/latest"
params = {
"access_key": api_key,
"symbols": "KGS,USDKGS"
}
r = requests.get(url, params=params, timeout=30)
r.raise_for_status()
data = r.json()
if not data.get("success"):
raise RuntimeError(f"API error: {data.get('error')}")
base = data.get("base", "USD")
ts = data["timestamp"]
date = data["date"]
rates = data["rates"] or {}
kgs_per_usd = rates.get("KGS")
usd_per_kgs = rates.get("USDKGS")
# Derive missing leg if not present
if kgs_per_usd is not None and usd_per_kgs is None and kgs_per_usd != 0:
usd_per_kgs = 1.0 / kgs_per_usd
return {
"date": date,
"timestamp": ts,
"base": base,
"kgs_per_usd": kgs_per_usd,
"usd_per_kgs": usd_per_kgs
}
if __name__ == "__main__":
api_key = os.getenv("METALS_API_KEY", "YOUR_API_KEY")
print(latest_kgs(api_key))
Downstream, keep both quotes in your cache so UIs and calculations can consume whichever direction they require without recomputation.
How this fits with metals-priced products in KGS
For apps that show a commodity priced locally, you will typically assemble a synchronized price as:
- Get the metal’s daily close in USD (ensure the same close timestamp/date you use for KGS).
- Get rates.KGS for the same date (KGS per USD).
- Compute local price: price_usd × KGS_per_USD.
This keeps the quote internally consistent and prevents drift caused by mixing time windows. If you are building a marketplace or checkout flow that must round to the som, round at the final step with your business rules; keep upstream rates unrounded in storage.
Operational tips that save time
- Pagination: When requesting time-series, the response is bounded by date range parameters; plan ranges so they fit memory and align with your batch window.
- Retries: For transient network issues, retry idempotent GETs using exponential backoff; never retry on definitive API errors without investigation.
- Backfills: For large historical imports, process by month or quarter to simplify retries and reconciliation.
- Audit: Log raw payloads (or their hashes) with timestamp and request parameters to trace any downstream discrepancies.
Where to find symbols and parameters
If you need to confirm availability of KGS or related symbols you intend to combine (e.g., specific metals), review the symbol directory: Metals-API Supported Symbols. For the parameter reference and all endpoint behaviors, keep the docs open: Metals-API Documentation.
Pricing and key management notes
- Metals-API does not offer a free trial. You’ll need an API key to query endpoints.
- Plan details can change; when you need copper intraday and other expanded features, note that Copper Monthly is $19.99/mo at the time of writing. Select a plan that matches your frequency and endpoint needs.
- Rotate keys periodically and scope their usage server-side to avoid client exposure.
For programmatic control and platform-level integrations, review MCP if you need management features across environments.
Validation and reconciliation
To ensure your daily KGS series remains consistent over time:
- Store both the date and the UNIX timestamp from each payload; downstream consumers can choose the axis they need.
- Write a daily job that compares the latest time-series close for KGS to the previous day—in percentage terms—to catch obvious anomalies before they hit production charts.
- For independent cross-checks, you can compare directional moves to public FX summaries from central banks or financial terminals. Example references include the Kyrgyz Republic’s central bank communications or broad FX summaries from major financial portals. Keep in mind that methodologies and close conventions can differ.
External reference examples for general FX context:
Common pitfalls when working with KGS time-series
- Mixing base currencies: If you change base from USD, re-interpret rates correctly before computing derived values.
- Timezone creep: Always treat Metals-API dates/timestamps as UTC; convert only at the chart/UI edge.
- Implicit inversion errors: If you compute USD/KGS from KGS/USD, guard against division by zero and round consistently.
- Weekend forward-fill: If your KPI requires calendar-daily values, clearly mark forward-filled points so analysts don’t mistake them for fresh closes.
FAQ
Q: How do I get a continuous KGS daily series including weekends?
A: Use the time-series endpoint for business days, then forward-fill missing calendar dates in your application. Keep the original business-day series for auditing.
Q: Can I pull both KGS and USDKGS in one call?
A: Yes. Include both in the symbols parameter (e.g., symbols=KGS,USDKGS) on latest or historical endpoints. For time-series, you can request KGS and invert client-side to obtain USDKGS per date.
Q: Which timestamp should I store—the UNIX timestamp or the date string?
A: Store both. The UNIX timestamp supports cache/version control and reconciliation; the date string (UTC) is convenient for grouping and charting.
Q: How should I convert metal prices into KGS?
A: Multiply the metal’s USD quote by KGS per USD from the same close snapshot. Keep the units consistent (e.g., USD per troy ounce × KGS per USD → KGS per troy ounce).
Q: Is there a free trial?
A: No. Metals-API has no free trial. Choose a plan that matches your update frequency and endpoints, then authenticate with your API key.
Get your API key and start pulling KGS daily closes in minutes: Register. Keep the Documentation and Symbols pages open as you integrate, and explore MCP if you manage multiple environments.