API Authentication Notes

Details on the two available authentication methods.

Our currency conversion API supports two different authentication methods. This page explains the details of both and gives some brief info on the security trade offs between each approach.

⚡ Default In-URL Authentication

Our default authentication scheme is to simply include your API key in the URL that you send a GET request to. Here's an example:

GET https://v6.exchangerate-api.com/v6/YOUR-API-KEY/latest/USD

This is the fastest way to get started. You can actually just paste this GET request in your browser and immediately see your JSON response, no need to even fire up curl.

The disadvantage is that your API key can get included in logging as a result of being contained in the URL. Considering that our service doesn't store any user data and the keys' purpose is just access control & rate limiting most users are OK with this security tradeoff.

🔐 Token Bearer Authentication

For customers that are more concerned about this logging risk or have to meet audit requirements for all their integrated services we offer another common authentication approach called Token Bearer.

Some implementations of this method have a more complex process (e.g. JWT) but ours is very simple - your API key is simply the token and there is no need to follow any signing process or fetch a short lived Access Token.

Authentication with this method is handled by the passing of an HTTP header with the following format:

Authorization: Bearer YOUR-API-KEY

You must omit the `YOUR-API-KEY` section from your request URLs in order to use this authentication method. Here's an example URL:

GET https://v6.exchangerate-api.com/v6/latest/USD

🖥️ What About Client Side Auth?

If you want to generate API requests from client side code our usual suggestion is to make regular requests on a schedule from your infrastructure and then save the responses in your datastore. You can then handle requests from your users within your existing infrastructure and auth approach (if any). Our terms do permit caching of our data and with this approach you can avoid the need to manage authentication in public code.

➡️️​ As always, if you have any questions about our API or how it handles authentication you're welcome to contact us!