Exchange Rates API to Databricks: How to Move Your Data
Move Exchange Rates API into Databricks with Airbyte. Why a free plan fixes your base currency at EUR, and how to reshape the wide daily record.
Moving Exchange Rates API into Databricks gives currency conversion a place in your transformation layer rather than in whichever query somebody wrote last. Any organisation trading across borders needs rates beside revenue, and needs everyone using the same ones.
This guide covers the managed path with Airbyte. Two things shape the build: a free plan decides your base currency for you, and the shape that arrives is awkward in a way that is easy to fix once and painful to ignore.
Exchange Rates API to Databricks at a glance:
Why move data from Exchange Rates API to Databricks?
Two situations account for most of these pipelines.
The first is one agreed rate table feeding every model, so that revenue converted in a finance report and revenue converted in a product analysis produce the same number rather than two defensible ones.
The second is historical conversion inside transformations you already run here. If what you want is a rate table for SQL reporting rather than modelling, Exchange Rates API to Snowflake achieves that with less to operate.
What do you need before you start?
Four things, and the first depends on what you are paying:
An access key, and clarity about your plan. A free subscription limits you to a thousand calls a month and to EUR as the base currency. The key is also case sensitive. The Exchange Rates API source documentation sets out both limits.
A decision about your base currency. If your organisation reports in something other than EUR and you are on the free plan, you will be converting through EUR rather than reading your own rates directly.
Permission to create Volumes in Unity Catalog. Staging goes through Avro files written into a Volume, which is separate from creating tables and worth requesting early.
A view on weekends and holidays. Rates are not published every day and your transactions are, so something has to decide which rate a Saturday sale uses.
If your workspace restricts traffic by IP, add the Airbyte Cloud IP addresses to the allow list before you begin.
How do you build an Exchange Rates API to Databricks pipeline in Airbyte?
Step 1: Check your base currency against your plan
Establish which currency your organisation reports in and whether your subscription lets you ask for it, because on a free plan the answer is EUR regardless of what you wanted. That is workable and it is not neutral: converting through an intermediate currency introduces rounding and a decision about precision that somebody should make deliberately rather than inherit.
Step 2: Configure the Exchange Rates source
Click Sources in the left navigation, then New Source, and select Exchange Rates API, following adding a source. Supply the access key exactly as issued, a start date and a base currency if your plan allows one. Set a start date you actually need, since a long backfill spends monthly calls you may not have.
Step 3: Configure the Databricks destination
Click Destinations, then New Destination, and select Databricks, following adding a destination. Supply the workspace details, warehouse or cluster, catalogue and schema. This is one of the smallest datasets you will ever load, so nothing about sizing is interesting here.
Step 4: Create the connection and reshape immediately
Click Connections, then New connection, select the stream and a sync mode. Daily is right. Then build the silver table before anybody writes a query against bronze, because what lands is not the shape anyone wants to join to.
Alert on failure, since a missing day is a gap that every conversion afterwards has to work around.
Why does the plan decide your base currency?
Because source currency switching is a paid feature, and the free tier fixes the base at EUR. The connector exposes a base setting and your subscription decides whether it does anything, which is an unusual place for a commercial limit to appear in a configuration screen.
For an organisation reporting in sterling or dollars that means an extra step. Rates arrive relative to EUR, so converting a dollar amount to pounds goes through EUR, and each conversion rounds. On a single transaction that is invisible; across a year of consolidated reporting it is the sort of small persistent discrepancy that finance teams notice and ask about.
So make it explicit rather than incidental. Decide the precision you carry through intermediate conversions, do the arithmetic in one silver model rather than in every downstream query, and record which base your tables hold. If the discrepancy matters to whoever signs off the numbers, a paid plan removing the intermediate step is a cheaper answer than reconciling it repeatedly.
Why is the landing shape awkward?
Because a record is a date with a field for every supported currency, which is one wide row rather than a row per rate. That mirrors the API and it is the opposite of what a join wants, since converting a transaction means looking up one currency on one date and the table is organised the other way round.
Unpivoting into date, currency and rate is the fix and it belongs in silver, done once. Three columns join cleanly to anything, a new currency appearing adds rows rather than widening a table, and nobody has to write a query naming a currency as a column. It is a small transformation and the difference between a table people use and one they copy figures out of.
Handle the gaps in the same model. Weekends are skipped by default because exchanges do not trade, and public holidays go missing too, while your sales happen every day. So decide the rule, usually carrying the last published rate forward, and implement it once with the date it came from recorded, because a conversion nobody can explain is worse than one somebody disagrees with.
Frequently asked questions
Why can I not change the base currency?
Source currency switching is not included on the free plan, which fixes the base at EUR. The setting exists but your subscription decides whether it applies.
Why are there no rates for Saturday?
Weekends are ignored by default because exchanges do not trade then. Carry the last published rate forward in your model and record which date it came from.
How should I model the rates table?
Unpivot the wide record into date, currency and rate. Three columns join cleanly and a new currency adds rows rather than changing the table's shape.
My backfill stopped partway.
A free plan allows a thousand calls a month, and a long daily history spends them quickly. Shorten the start date or move to a paid plan.
Can I do this without writing code?
The pipeline, yes. The unpivot and the rule for missing days are transformation work, and they are what makes the rates usable.
Get your Exchange Rates API data into Databricks
Check whether your plan lets you set the base currency, because a free key fixes it at EUR and everything else converts through it with rounding you should decide about. Watch the monthly call allowance on a long backfill. Then unpivot the wide record into date, currency and rate in one silver model, and settle there how weekends and holidays are filled.
Airbyte's connector catalog includes 600+ pre-built connectors, so everybody converting currency can use the same rates. For the same source into a warehouse, see Exchange Rates API to BigQuery, and for the same source into a column store, Exchange Rates API to ClickHouse.
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.