Exchange Rates API to Snowflake: How to Move Your Data
Move Exchange Rates API data into Snowflake with Airbyte. Why the table has one column per currency, free plan base currency limits, and deriving cross rates.
Moving Exchange Rates API data into Snowflake solves a small problem that causes disproportionate trouble: converting figures between currencies consistently. Every team that reports across borders eventually discovers that finance, sales and analytics are each using a different rate for the same day, and nobody can say which is right.
This guide covers the managed path with Airbyte. It is a small, well-behaved pipeline, and the shape of what arrives will surprise you: rather than one row per currency per day, you get one row per day with a column for every currency the API supports.
Exchange Rates API to Snowflake at a glance:
Why move data from the Exchange Rates API to Snowflake?
Two situations account for most of these pipelines.
The first is one agreed rate table. Once a rates table exists in your warehouse, every report that converts currency uses the same numbers, and disagreements between teams become impossible rather than merely discouraged. That is the whole value, and it is worth more than the effort suggests.
The second is historical correctness. Converting last year's revenue at today's rate is wrong, and doing it properly needs the rate that applied on each transaction date. A daily rates table going back as far as your reporting does is what makes that possible, and it is not something a spreadsheet handles well.
What do you need before you start?
A very short list, and one item depends on what you are paying for:
An API access key. Generated from your Exchange Rates API account and entered as the access key. The Exchange Rates API source documentation covers the fields.
A start date, in the right format. Entered as year, month and day. Data added on and after this date is replicated. Set it to cover the earliest transactions anyone will convert, because a rates table that starts after your revenue history is only half useful.
A base currency you are actually allowed to use. This is the one to check before promising anything. On the free plan EUR is the only option available, and if you specify nothing EUR is used. A business reporting in dollars or pounds therefore either upgrades or handles the conversion downstream.
Snowflake objects and a role. A warehouse, database, schema and a role able to create tables in that schema. Volume is genuinely not a concern here, so the smallest warehouse you have is more than enough.
If your organisation restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list on the Snowflake side before you begin.
How do you build an Exchange Rates to Snowflake pipeline in Airbyte?
Step 1: Settle the base currency question
Check which plan you are on and therefore which base currencies you can request. If you are on the free plan and report in something other than euros, decide now whether to upgrade or to derive the rates you need downstream, because both are reasonable and they lead to different modelling.
Step 2: Configure the Exchange Rates API source
Click Sources in the left navigation, then New Source, and select Exchange Rates API, following adding a source. Enter the access key, the start date and optionally the base currency, then click set up source. This is one of the simplest configurations in the whole catalogue.
Step 3: Configure the Snowflake destination
Click Destinations, then New Destination, and select Snowflake, following adding a destination. Supply the account identifier, warehouse, database, schema and role. Consider putting this in a shared reference schema rather than alongside a particular team's data, since a rates table is something everyone will want to join against.
Step 4: Create the connection and schedule daily
Click Connections, then New connection, and choose a sync mode. Daily matches the grain of the data exactly, and there is no reason to sync more often since a published day's rate does not change afterwards. That immutability also means you never need a lookback window here, which is a pleasant contrast with most reporting sources.
One scheduling note worth thinking about: rates are published on business days, so weekends and holidays will not produce new values. Your downstream models need a rule for what rate applies on a Sunday, and carrying the last published rate forward is the usual answer.
Why is the table so wide?
Because the connector mirrors the API's response shape. Each record carries the date, then one field for every supported currency containing that currency's value on that date. With around 160 currencies covered, that is a table with a date column and roughly 160 rate columns.
That is fine as a landing shape and awkward to join against. Almost every use of this data wants the long form, a row per date and currency, so that you can join it to a transactions table on both the date and the currency code. Joining a wide table means writing a different join for every currency, which is exactly the kind of thing nobody maintains.
So build an unpivoted view over the landed table and point everyone at that. It is a modest piece of SQL, it turns 160 columns into two, and it is the difference between a rates table people use and one they copy figures out of by hand.
What if you cannot set the base currency you want?
On the free plan you are limited to euros as the base, which is inconvenient if your accounts are in dollars or pounds. The good news is that it does not block you, because every rate in a row shares the same base and you can therefore derive any pair from any other by division.
If a row gives you the euro rate for both dollars and pounds, the dollar to pound rate is one divided by the other. Doing that once in your unpivoted view lets you expose rates in whatever base your business reports in, without changing the pipeline or the plan.
Two caveats. Derived cross rates accumulate small rounding differences, which is immaterial for reporting and worth knowing if anyone reconciles to the penny. And if finance has a mandated rate source, use theirs rather than this, because being consistent with the accounts matters more than being consistent with a public API.
Frequently asked questions
Can I choose any base currency?
Not on the free plan, where EUR is the only option. If you specify nothing, EUR is used. You can derive other bases downstream by dividing one rate by another.
Why does my table have so many columns?
The output is a date plus one field per supported currency, mirroring the API response. Build an unpivoted view giving a row per date and currency, which is what joins want.
Do I need a lookback window?
No. Once a day's rate is published it does not change, so unlike most reporting sources there is nothing to re-read.
What rate applies at the weekend?
Rates are published on business days, so define a rule in your models. Carrying the last published rate forward is the usual approach, and it should be agreed with finance rather than assumed.
Can I do this without writing code?
The Airbyte setup is entirely UI-driven. You will want a Snowflake view unpivoting the currency columns, which is short SQL and the step that makes this dataset usable.
Get your exchange rates into Snowflake
Check which base currencies your plan allows, set a start date covering your earliest transactions, put the table in a shared reference schema, and build the unpivoted view before anyone tries to join against 160 columns. Then agree the weekend rule with finance so every report treats non-trading days the same way.
Airbyte's connector catalog includes 600+ pre-built connectors, so reference data can sit beside the financial sources that need it. For treasury balances in the same warehouse, see Kyriba to Snowflake, and for the ERP side, NetSuite to Snowflake.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.