API to Get the Belarusian Ruble (BYR) Price using cURL examples

You need to pull the live Belarusian Ruble price into your app, chart a short history, and show a clean USD↔BYR conversion users can trust. By the end of this guide, you’ll fetch the latest BYR quote with a copy-paste cURL command, parse the JSON in Python, understand how the fields map to your UI, and know what to watch out for with base currency, time boundaries, and caching.

Goal: Get the latest BYR price and wire it to your UI

The core workflow is simple: call the latest endpoint, read the response fields, and present the price. If you’re building a payout calculator, you’ll multiply an amount by the rate you need (USD→BYR or BYR→USD) and round to your preferred precision. If you’re charting, you’ll combine this with historical endpoints and follow the time constraints (end_date cannot be today).

All requests to Indices-API are authenticated via the access_key query parameter. The default base currency is USD, so quotes are returned in terms of “how many units of the other symbol equate to 1 USD” or with an explicit cross symbol in rates when provided. See the example below.

Before you write code, confirm your symbols on the official list. The modern ISO code for the Belarusian ruble is BYN, but some datasets and legacy instruments still use BYR. The API response in this article uses BYR. Always verify your exact symbol on the Indices-API Supported Symbols page.

Symbols to use for Belarusian Ruble pricing

Use these as a quick mapping for what you’ll see in the response. Verify final codes in your environment with the symbols endpoint on the Symbols page:

Make a real request for the latest BYR price (cURL)

Copy, paste, and run. Replace YOUR_API_KEY with your key. If you need an API key, you can get one in minutes at Indices-API Register. The endpoint returns the latest values with a timestamp, date, and rates map.

curl -s "https://indices-api.com/api/latest?access_key=YOUR_API_KEY"

Here is the official sample response we’ll use in this article. Use these exact values to validate your integration and field mapping:

{"data":{"success":true,"timestamp":1791420000,"date":"2026-10-08","base":"USD","rates":{"BYR":3.0637254901961,"USD":1,"USDBYR":0.3263999999999977}}}

Field-by-field: what you actually need

• data.success: Boolean indicating a successful response.
• data.timestamp: Unix timestamp for the pricing snapshot. Treat as UTC for storage and cache control.
• data.date: Calendar date string for the snapshot (YYYY-MM-DD). This is linked to the last official update for that day.
• data.base: The response base currency. By default it’s "USD".
• data.rates: Key-value pairs of rates. In this sample:
  • BYR: 3.0637254901961 — BYR per 1 USD, given base is USD.
  • USD: 1 — since base is USD.
  • USDBYR: 0.3263999999999977 — an explicit USD→BYR cross symbol. Where present, you can use this directly to convert USD to BYR.

When both BYR and USDBYR appear, prefer the explicit cross for USD→BYR conversion. If you only have BYR (as BYR per USD), then USD→BYR is BYR itself, while BYR→USD is 1 / BYR. Normalize both in your client so your UI always has a consistent direction for math and display.

Python example: fetch, parse, and compute USD↔BYR conversions

This small script calls the same latest endpoint, reads the key fields, and demonstrates both conversion directions. It assumes the same response shape shown above.

import os
import requests
from decimal import Decimal, ROUND_HALF_UP

API_KEY = os.getenv("INDICES_API_KEY", "YOUR_API_KEY")
URL = "https://indices-api.com/api/latest"

resp = requests.get(URL, params={"access_key": API_KEY}, timeout=10)
resp.raise_for_status()
payload = resp.json().get("data", {})

if not payload.get("success"):
    raise RuntimeError("API call was not successful")

timestamp = payload.get("timestamp")
date_str = payload.get("date")
base = payload.get("base")
rates = payload.get("rates", {})

# Extract rates from the map; fall back safely if a key is missing
rate_usd_to_byr = rates.get("USDBYR")
rate_byr_per_usd = rates.get("BYR")

# Normalize directions:
# Prefer explicit USDBYR if present; otherwise assume BYR is BYR per USD.
if rate_usd_to_byr is None and rate_byr_per_usd is not None:
    rate_usd_to_byr = rate_byr_per_usd

# Derive BYR->USD if we only have USD->BYR
rate_byr_to_usd = None
if rate_usd_to_byr:
    rate_byr_to_usd = 1.0 / float(rate_usd_to_byr)

def quantize(amount, places="0.0001"):
    return Decimal(str(amount)).quantize(Decimal(places), rounding=ROUND_HALF_UP)

usd_amount = 125.00
byr_amount = 400.00

if rate_usd_to_byr:
    est_byr = quantize(usd_amount * float(rate_usd_to_byr))
    print(f"{usd_amount} USD ≈ {est_byr} BYR (date={date_str}, ts={timestamp}, base={base})")

if rate_byr_to_usd:
    est_usd = quantize(byr_amount * rate_byr_to_usd, "0.01")
    print(f"{byr_amount} BYR ≈ {est_usd} USD (date={date_str}, ts={timestamp}, base={base})")

Tip: Use Decimal for money math to control rounding and avoid binary float surprises. You can select a precision and rounding mode that matches your business rules.

How quotes are expressed and how to display them correctly

Indices-API responses are, by default, expressed relative to USD. In practice:

• When base is "USD" and the rates map contains BYR, read it as “BYR per USD.”
• If the rates map contains an explicit cross like "USDBYR", that’s a direct “USD to BYR” multiplier.
• To get the inverse direction (BYR→USD) when you only have USD→BYR, compute 1 / rate and display with the right number of decimals (e.g., 2–4 for USD, more for small fractional values).

When showing price widgets, label the direction. For example, “1 USD = X BYR” versus “1 BYR = X USD.” If you need both, compute both and cache them together.

Update frequency, weekends, and time boundaries

Latest rates are updated depending on your subscription plan’s cadence (for example, every 60 minutes or every 10 minutes). Always check the timestamp field to avoid stale UI. If you’re caching on your edge, set your TTL to be slightly shorter than your plan’s update frequency, and invalidate caches when you detect a newer timestamp.

For historical and time-series queries, note that end_date cannot be today. Query up to yesterday, then append today’s latest via the latest endpoint to complete a chart. This is a common pattern: stitch daily candles from historical with a “live” point from latest.

Weekends and holidays: FX markets have limited liquidity on weekends and holidays. If you see unchanged rates for a non-business day, this can be expected. Use the date and timestamp fields to anchor your chart and show gaps explicitly when needed.

Historical and time-series BYR pricing (request format and limits)

To backfill or chart the Belarusian Ruble over a period (e.g., the past 30 days), use the historical and time-series endpoints. The API supports daily snapshots between your chosen start_date and end_date (remember: end_date cannot be today). Exact URL formats, date limits per request, and examples are documented in the Indices-API Documentation.

Once you have the series, you’ll parse it similarly to the latest response. Use the base, date, and rates fields for each day. If you consistently need USD→BYR, prefer the explicit cross symbol when present; otherwise compute it from BYR per USD as needed.

Caching patterns that save load time and quota

• Client cache: Cache the last successful payload and timestamp to ensure your UI remains responsive during transient errors.
• Edge cache: Use a short TTL slightly less than your update cadence (for example, if updates are every 10 minutes on your plan, cache for 8–9 minutes).
• Server-side memoization: If multiple internal services need the same quote, centralize the fetch and fan out an internal copy rather than calling the API repeatedly.
• Stitch live + historical: Combine historical daily data with the latest point to produce intraday-updated charts without hammering the historical endpoint.

Error handling and resilience

• Check data.success before trusting the payload.
• Validate that the base is what you expect for your calculations (“USD” in this example).
• Guard for missing keys in rates. If USDBYR is missing, compute from BYR if available.
• Surface the server timestamp in logs to debug “stale data” complaints.
• Implement a fallback message in your UI if a refresh fails, using the last known good value.

Precision, rounding, and display

BYR amounts can become large quickly when converting from USD depending on the rate magnitude. Pick a consistent rounding policy:

• For USD displays: 2 decimals (e.g., 123.45) is typical.
• For BYR displays: 0–4 decimals depending on your operational needs. If users make payouts in whole BYR, round half up to 0 decimals.
• When showing both directions, compute from the same base number and round at the end to avoid drift.

Production readiness checklist

• Authentication: access_key must be attached as a query parameter.
• Timeouts and retries: Set a client timeout (e.g., 10 seconds) and a brief exponential backoff on retryable errors.
• Observability: Log timestamp, date, and the top-line rate you used for a given user action or quote.
• Data stitching: Use latest for “today” and historical/time-series for prior days. Respect the “end_date cannot be today” constraint on historical windows.
• Caching: Apply cache headers/TTL based on your plan’s update cadence.
• Symbol hygiene: Confirm BYR versus BYN continuously with the Symbols reference to avoid silent symbol mismatches.

Where to find the right endpoint details

This article focused on the latest rates endpoint for BYR with a working cURL request and a Python example. For historical, time-series, OHLC, and fluctuation endpoints, see the full parameter set, date formats, and limits in the Indices-API Documentation. If you operate in multi-cloud environments or need connectivity details, see the MCP page.

You can explore the platform and product overview at indices-api.com and start testing immediately with a key from Indices-API Register. The Pro plan is $49.99/mo with a 7-day trial so you can validate latency, coverage, and integration fit.

Additions your users will appreciate

• “As of” label: Show the date and time from timestamp/date, e.g., “As of 2026-10-08 00:00 UTC.”
• Both directions: Offer a toggle to switch between “1 USD = X BYR” and “1 BYR = X USD.”
• Copy-to-clipboard: Allow copying the numeric result in one click.
• Light caching indicator: If you cache, indicate approximate freshness to set expectations.
• Audit trail: For compliance-focused apps, store the payload’s timestamp and the specific rate used for a payout conversion.

Why BYR vs. BYN matters

The Belarusian ruble underwent redenomination; BYN is the current ISO code, while BYR is sometimes used in legacy datasets. Your users won’t care which code you picked—until numbers look off. Reduce risk by pinning the exact symbol you use, asserting it in code, and validating it periodically against the official Symbols reference. If you ingest third-party data alongside Indices-API, document your internal mapping (BYR↔BYN) explicitly.

For macro context on policy changes and redenominations, you can also reference the National Bank of the Republic of Belarus for public communications: nbrb.by.

End-to-end: building a BYR widget with live + yesterday

Put it all together in a simple flow:

1. On load, fetch latest with your access_key and store timestamp/date alongside the payload.
2. If your UI shows a 30-day chart, query time-series up to yesterday (end_date=yesterday), then append today’s latest as the final point.
3. Display “1 USD = X BYR” using USDBYR when present; otherwise compute it from BYR per USD.
4. Offer a BYR→USD input path by computing the reciprocal and rounding appropriately.
5. Cache for a few minutes (under your plan’s update cadence) and refresh on a schedule or user action.

This keeps your UI steady even during transient network conditions, and it respects the constraint that end_date cannot be today.

Security and operational notes

• Keep your access_key out of client-side code if possible; proxy calls through your backend.
• If you must call from the browser, consider rate-limiting per session and rotate keys periodically.
• Log minimal PII and avoid logging the full access_key. Hash or mask it in logs.
• Monitor upstream health and latency. If you deploy multi-region, pair your stack with guidance from the MCP page.

What to expect from updates and trialing plans

Update frequency varies by plan tier (e.g., every 60 minutes or every 10 minutes). Test your UI with the 7-day trial on the Pro plan ($49.99/mo) to dial in your cache TTL, refresh policies, and reconciliation logic for live and historical data. You can skim endpoints now and build from the examples on the Documentation page. If you need to evaluate fit broadly, the homepage at indices-api.com summarizes coverage and capabilities.

FAQ

Q: Which symbol should I use—BYR or BYN?
A: The sample in this article uses BYR. Because symbols can differ by dataset or period, confirm the exact code in your account using the Symbols page before shipping. If you migrate between sources, map BYR↔BYN explicitly.

Q: Why can’t I set end_date to today on time-series/historical?
A: Historical and time-series are finalized per trading day. Use end_date=yesterday, then append today’s live point from the latest endpoint to display a complete line up to “now.”

Q: What timezone is the timestamp?
A: Treat timestamp as Unix epoch seconds in UTC. Align your UI’s “as of” label to UTC unless you have a clear user preference for local time.

Q: Do rates update on weekends?
A: FX liquidity is limited on weekends/holidays, so rates may hold steady. Always rely on the timestamp and date fields to understand freshness and set user expectations.

Q: How do I get both USD→BYR and BYR→USD?
A: Use USDBYR directly if present; otherwise compute it from BYR (BYR per USD). For BYR→USD, compute the reciprocal (1 / USDBYR). Round at display time to avoid compounding rounding errors.

Get your key and ship

Grab a free trial key and wire the latest BYR price into your app in minutes. Start here: Register. For endpoint parameters and more examples, keep the Documentation open, and confirm any symbol details on the Symbols page.