Currency Converter API for Developers

A useful currency converter API gives you more than a multiplied number. It shows the rate, converted amount, source, observation time, market session, and whether the pair was derived. exchangerate.dev includes that context in every conversion response.

• Try GET /v1/convert/USD/EUR/100 without a key; use a server-side key for production.
• Single and batch conversion endpoints return rate provenance and freshness metadata.
• Converted amounts are quantized for the target currency; keep the rate at full precision.
• Rates are indicative estimates, not executable bank, card, or settlement quotes.

Make your first currency conversion request

The path contains the source currency, target currency, and amount. This request is enough to try the API and inspect the response. For a deployed application, create a free key and keep it on your server.

curl "https://api.exchangerate.dev/v1/convert/USD/EUR/100"

The response includes from, to, amount, rate, converted, derived, and derivation_bps_max, plus the normal response envelope: source, sources, market_session, timestamp, and data_updated_at. Those fields let the application explain what it converted and how fresh the underlying observation was.

Convert several amounts in one request

Use the POST endpoint when a job needs several target currencies. Each pair counts toward quota separately, but batching reduces network round trips and keeps the results in one response.

curl -X POST "https://api.exchangerate.dev/v1/convert" \  -H "Authorization: Bearer $EXCHANGERATE_API_KEY" \  -H "Content-Type: application/json" \  -d '{"from":"USD","pairs":[["EUR",100],["GBP",50],["JPY",1000]]}'

Keep rates precise and round money at the boundary

Store the returned rate at full precision. Round the final money amount according to the target currency and the rules of your product. The conversion endpoint quantizes converted for the target currency, but accounting systems should still preserve the original amount, rate, currency codes, and observation time beside the booked result.

Cache by data cadence, not page views

Do not call the upstream API once per browser render. Fetch on the server, cache a successful response, and reuse it until your product needs a refresh. Preserve data_updated_at when a refresh fails so users can see the age of the last good observation.

• Set a request timeout and handle 429 and 503 explicitly.
• Keep the API key in a server environment variable, never in browser JavaScript.
• Retain the last successful response for a bounded fallback window.
• Display the observation time and rate class when freshness matters.

Use the pattern in your stack

Follow the focused guides for React, Ruby on Rails, Shopify, or WooCommerce. Each keeps the upstream call on the server and separates display estimates from executable checkout prices.

Choose the endpoint that matches the job

Need to check a past rate before writing code? Use the historical exchange-rate lookup, then copy the matching API request.