Rwandan Franc (RWF) - N/A Price Today: Real-time spot rate and 24h change for API consumers

Metals-API 9 min read
Rwandan Franc (RWF) - N/A Price Today: Real-time spot rate and 24h change for API consumers

You need to quote or settle a transaction in Rwandan Franc (RWF) right now and also show the 24-hour change. By the end of this guide you’ll be able to pull the current USD↔RWF spot from Metals-API, invert it correctly for your UI or pricing engine, and compute a robust 24-hour delta suitable for dashboards, quotes, or alerts.

What we’re building: live RWF spot and a reliable 24h change

We’ll focus on two endpoints that cover the majority of production use cases for RWF:

Illustration: Rwandan Franc (RWF) - N/A Price Today: Real-time spot rate and 24h change for API consumers
  • Latest Rates to fetch the current spot for RWF with USD as base.
  • Historical Rates (by date) to compare against the prior day and compute a 24-hour delta.

This keeps the solution small, cacheable, and fast for web, mobile, and server-side integrations. If you later need intraday bars, OHLC, or fluctuation summaries, refer to the Metals-API documentation when you extend your pipeline.

How Metals-API quotes RWF (and why inversion matters)

By default, Metals-API returns rates relative to USD. For currencies, that typically means:

  • rates.RWF = RWF per 1 USD (USD→RWF).
  • rates.USDRWF = USD per 1 RWF (RWF→USD). This is the mathematical inverse of rates.RWF.

In UI and reports, you often need both representations: “RWF per USD” for consumer prices and “USD per RWF” for cross-currency ledgers or settlements. Metals-API returns both fields directly, so you don’t have to calculate the inverse yourself (though you can if needed).

One-call latest: copy-paste curl

Use the Latest endpoint to fetch the current spot. Request only the symbols you need to keep payloads minimal and cache-friendly.

curl "https://metals-api.com/api/latest?access_key=YOUR_API_KEY&symbols=RWF,USDRWF"

Sample JSON response (official sample):

{"success":true,"timestamp":1792912140,"date":"2026-10-25","base":"USD","rates":{"RWF":1476.413621,"USD":1,"USDRWF":0.0006773169698357856}}

Fields you’ll actually use

  • success: Boolean flag, check before using the payload.
  • timestamp: Unix epoch (seconds). Treat as UTC and convert once at the edge of your system for display.
  • date: ISO date of the rate snapshot. For day-over-day comparisons, this anchors your “today” value.
  • base: USD by default. Important when you’re mixing metals and FX in one pipeline.
  • rates.RWF: RWF per 1 USD.
  • rates.USDRWF: USD per 1 RWF (inverse).
Field Meaning Practical use
rates.RWF RWF per USD Convert USD-denominated prices into RWF for checkout, ERP, and quotes.
rates.USDRWF USD per RWF Normalize incoming RWF amounts into USD for P&L, risk, or settlements.
timestamp UTC seconds since epoch Drive “last updated” labels and TTL-based caching.

Python example: latest spot plus 24h change

This example fetches the latest spot (RWF and USDRWF), then calls the previous calendar day to compute a 24-hour absolute and percent change. It also shows defensive handling for weekends/holidays by stepping back until a prior rate is available.

import requests
from datetime import datetime, timedelta, timezone

API_BASE = "https://metals-api.com/api"
API_KEY = "YOUR_API_KEY"
SYMBOLS = "RWF,USDRWF"

def get_latest():
    url = f"{API_BASE}/latest"
    params = {"access_key": API_KEY, "symbols": SYMBOLS}
    r = requests.get(url, params=params, timeout=10)
    r.raise_for_status()
    data = r.json()
    if not data.get("success"):
        raise RuntimeError(f"API error: {data}")
    return data

def get_by_date(d: datetime):
    url = f"{API_BASE}/{d.strftime('%Y-%m-%d')}"
    params = {"access_key": API_KEY, "symbols": SYMBOLS}
    r = requests.get(url, params=params, timeout=10)
    r.raise_for_status()
    data = r.json()
    if not data.get("success"):
        return None
    return data

def find_previous_available(latest_date_iso: str, max_lookback_days: int = 7):
    # Start from previous calendar day and walk back until data is found.
    d = datetime.fromisoformat(latest_date_iso).date()
    for i in range(1, max_lookback_days + 1):
        candidate = d - timedelta(days=i)
        got = get_by_date(datetime.combine(candidate, datetime.min.time()))
        if got and got.get("rates", {}).get("RWF") is not None:
            return got
    raise RuntimeError("No prior data found within lookback window")

latest = get_latest()
latest_date = latest["date"]
latest_rwf_per_usd = latest["rates"]["RWF"]
latest_usd_per_rwf = latest["rates"]["USDRWF"]
latest_ts = latest["timestamp"]

# Find prior day's data (handles weekends/holidays if latest-1 doesn't exist)
prior = find_previous_available(latest_date)
prior_date = prior["date"]
prior_rwf_per_usd = prior["rates"]["RWF"]

# Compute 24h change in RWF per USD terms
abs_change = latest_rwf_per_usd - prior_rwf_per_usd
pct_change = (abs_change / prior_rwf_per_usd) * 100.0

print({
    "as_of_utc": datetime.fromtimestamp(latest_ts, tz=timezone.utc).isoformat(),
    "base": latest["base"],
    "spot": {
        "RWF_per_USD": latest_rwf_per_usd,
        "USD_per_RWF": latest_usd_per_rwf
    },
    "prior_date": prior_date,
    "change_24h": {
        "abs_RWF_per_USD": abs_change,
        "pct": pct_change
    }
})

Notes for production:

  • Cache the latest response for at least your plan’s update interval to avoid redundant calls.
  • Store the last known valid day so you can compute the delta without re-querying on each page load.
  • Decide which side you display. Many UIs show “USD/RWF” (i.e., RWF per USD). If your product displays “RWF/USD”, use rates.USDRWF or 1 / rates.RWF.

Implementing 24h change reliably

There are two common patterns for day-over-day change:

  1. Latest minus prior calendar day via the Historical endpoint (as in the code above). This is simple and works well for end-of-day or daily summary cards.
  2. Fluctuation endpoint to pull the change between two dates in one response. Use this when you need a standardized delta without writing your own arithmetic.

You can find parameter details for Historical and Fluctuation in the Documentation. Keep the symbols list tight (RWF, USDRWF) to reduce bandwidth and latency.

Production checklists: units, base currency, and time handling

Avoid subtle integration bugs by standardizing these conventions across your services:

  • Units: Metals-API expresses metal quotes per troy ounce by default. For currencies like RWF, rates are unitless exchange rates relative to USD. Don’t mix units in the same computation graph without explicit conversion.
  • Base currency: The default base is USD. When you combine currency and metal prices (for example, pricing a gold item in RWF), pull the metal rate (relative to USD) and the RWF rate (relative to USD), then compose them carefully.
  • Inversion: rates.RWF and rates.USDRWF are inverses. Depending on your UI, you may display one, but store both to avoid repeated inversion in hot paths.
  • Timestamps and timezone: timestamp is epoch seconds in UTC. Convert once at the edge (API layer or client) and reuse.
  • Weekends and holidays: Currency markets are 24/5. If you need a “24h change” snapshot on weekends, compare the latest to the most recent prior business day. The Python example above steps back automatically.
  • Caching: A reverse proxy (e.g., Nginx or Cloud CDN) with a TTL aligned to your plan’s update frequency reduces load. Key your cache by path and symbols to prevent accidental cross-contamination.

From RWF to metals: quoting precious metals for Rwandan buyers

If your product quotes precious or industrial metals to Rwandan customers, you’ll often combine a metal quote (e.g., XAU per USD) with the RWF spot. Metals-API uses USD as the base for both metals and currencies, which makes composition straightforward:

  • USD→Metal: rates.XAU gives troy ounces per USD.
  • USD→RWF: rates.RWF gives RWF per USD.

To display “RWF per troy ounce of gold,” multiply (USD per troy ounce) by (RWF per USD). When you request the latest rates, pass only the symbols you need to keep payloads small. See the full list of available tickers in the Metals-API Supported Symbols.

Operational guardrails: errors, fallback, and display

  • Error handling: Always check success before reading fields. If false, surface a clear message internally and fall back to the last cached value for user-facing views.
  • Fallback dates: For the “prior day,” step back until a data point exists rather than assuming yesterday will always be present.
  • Rounding and formatting: Decide on decimal precision per symbol. RWF often displays with 0 decimal places for retail, but keep full precision in storage to avoid drift.
  • Data freshness: Show a “Last updated” timestamp converted from timestamp to local time to reduce support tickets about perceived staleness.

Deployment patterns that scale

  • Server-side aggregator: One service fetches metals and FX and publishes normalized quotes (including RWF) over your internal bus. Downstream apps subscribe, reducing duplicate API calls.
  • Edge caching: Co-locate a TTL cache near users. Invalidate when timestamp changes or at a fixed cadence that matches your plan’s update interval.
  • Observability: Log timestamp, date, and symbol set alongside response times. Alert if the timestamp stops advancing.

When you expand beyond RWF

As your product grows, you may add more symbols, intraday series, OHLC, or bid/ask for trading surfaces. Start here with Latest and Historical to ship fast, then explore additional endpoints in the Metals-API Documentation. If you need to align your pricing with specific market checkpoints, review the MCP program and plans at MCP. Metals has no free trial; plans are designed to match update frequency and symbol needs.

Common pitfalls with FX+metals in RWF pipelines

  • Mixing units: You can’t add or average “RWF per USD” with “troy ounces per USD.” Convert to a shared axis first.
  • Double inversion: If you read rates.USDRWF and then invert again in a UI formatter, you’ll display the wrong direction. Keep a small helper to standardize display.
  • Weekend drift: Some teams compute “24h change” against a missing day (NaN) and display 0% inadvertently. Always find the most recent prior available day.

Security, reliability, and compliance

  • API key hygiene: Store YOUR_API_KEY in a secrets manager and pass it server-side. Avoid embedding keys in client apps.
  • Retrieval posture: Prefer short, explicit symbol lists (RWF, USDRWF) for principle-of-least-privilege and speed.
  • Auditability: Persist the fields you display (date, timestamp, rate values) alongside your own transaction IDs to support reconciliations.

Where to find parameters, symbols, and onboarding

  • Endpoint parameters and examples: Documentation
  • All available currencies and metals: Symbols
  • Pricing and programs: MCP

FAQ

Q: How do I show “USD/RWF” versus “RWF/USD” correctly?
A: Use rates.RWF for “RWF per USD.” Use rates.USDRWF for “USD per RWF.” If you only have one, invert it (1 / value). Keep the direction consistent across your system.

Q: What date should I use for a 24-hour change on weekends?
A: Use the most recent prior business day with data. If the latest date is Saturday, step back to Friday (or earlier if a holiday) and compare.

Q: Can I request both metals and RWF in one call?
A: Yes—pass a comma-separated symbols list (e.g., RWF, USDRWF, XAU) to the Latest endpoint. Keep the list minimal to reduce latency and payload size.

Q: How often do rates update?
A: Update frequency depends on your plan. Design your cache TTL to match your plan’s cadence and check the timestamp field to confirm freshness.

Q: Is there a free trial?
A: No. Metals-API does not offer a free trial. Review plans and options on the MCP page.

Ready to fetch live RWF rates and compute your 24h change? Get your API key now and integrate with the Latest and Historical endpoints in minutes: Register. For endpoint details and more examples, see the Documentation.