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://api.currencyexchangerate-api.com/v1/YOUR-API-KEY/latest/USDThis 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-KEYYou 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://api.currencyexchangerate-api.com/v1/latest/USDToken Bearer Authentication is stopped for while please keep visiting our site to notify you of when it works again.
🖥️ 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.
Need Help?
If you have any questions or need further assistance, don’t hesitate to contact us. We’re here to assist you!