Quickbooks to MySQL: How to Move Your Data
Move QuickBooks into MySQL with Airbyte. Why the Realm ID scopes one company per source, why sandbox and production need different keys, and exposing views.
Moving QuickBooks into MySQL puts accounting data where an application or an internal tool can query it. A client portal, an approvals workflow or a management dashboard that needs invoice and payment status is far simpler to build against a database it already connects to than against Intuit's API.
This guide covers the managed path with Airbyte. The structural thing to know first is that a source connects to one QuickBooks company, which matters because the businesses using QuickBooks very often have several.
QuickBooks to MySQL at a glance:
Why move data from QuickBooks to MySQL?
Two situations account for most of these pipelines.
The first is giving an application accounting context without giving it QuickBooks credentials. A portal showing a customer their invoice history reads a local table rather than calling Intuit on every page load, which is faster and removes a dependency from your request path.
The second is joining accounting data to whatever already lives in that database, such as matching invoices to your own order records. If you want multi-year financial analysis or consolidation across many companies, a warehouse is the better destination.
What do you need before you start?
Two of these involve the Intuit developer portal rather than Airbyte, so start them first:
An Intuit app with OAuth credentials. A client identifier, client secret and refresh token. Intuit's OAuth 2.0 playground is the easiest way to obtain them, and the QuickBooks source documentation walks through it.
The right keys for the environment you are targeting. Intuit issues development keys that work against sandbox companies, and production keys for real ones. Those are different credentials, so moving from testing to live is more than flipping the sandbox toggle in Airbyte.
A Realm ID for each company. The Realm ID, also called the company ID, identifies which QuickBooks company the source replicates. It is a required field, so a group or a bookkeeping practice needs one source per company and the IDs are worth collecting up front.
A MySQL user with write access. On the target schema, ideally one dedicated to synced data. Use a schema with its own grants, because invoices and payments are not something to land beside general application tables.
If your organisation restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list on the MySQL side before you begin.
How do you build a QuickBooks to MySQL pipeline in Airbyte?
Step 1: Count your companies and collect Realm IDs
Work out how many QuickBooks companies you need and collect a Realm ID for each. This step sizes the whole project: one company is an afternoon, eight companies is eight sources, eight connections and a consolidation layer on top. Better established now than discovered halfway through.
Step 2: Configure the QuickBooks source
Click Sources in the left navigation, then New Source, and select QuickBooks, following adding a source. Supply the OAuth credentials, the Realm ID and a start date, and set the sandbox toggle to match the keys you are using. Name each source after the company rather than accepting a default.
Step 3: Configure the MySQL destination
Click Destinations, then New Destination, and select MySQL, following adding a destination. Supply the host, port, database and credentials. If you are syncing several companies, decide now whether they share a schema with the company distinguished by a column, or get their own, because retrofitting that is tedious.
Step 4: Create the connection and expose views
Click Connections, then New connection, select your streams and a sync mode. Daily suits accounting data, which changes at the pace of bookkeeping. Then build views over the raw tables so your application reads a stable interface rather than Airbyte's metadata columns.
Compare a period's totals against QuickBooks after the first sync. This is finance data somebody reconciles, and a twenty-minute check now is worth considerably more than the same check after a customer has queried an invoice.
Why does one source mean one company?
Because Intuit's API scopes every request to a company, and the connector takes the Realm ID as a single required configuration value. There is no field for a list, so the company is fixed when you create the source.
For a single business that is invisible. For a group running a company per trading entity, or an accountancy practice managing client books, it is the defining characteristic of the project. Ten companies means ten sources, ten connections, ten sets of credentials to keep working, and a consolidation layer that unions them with a company column.
Two habits make that manageable. Name sources and connections after the company so failures are attributable at a glance, and decide the schema layout before you build the second one. Both are trivial at the start and awkward once several exist.
Why is the sandbox toggle not the whole story?
Because the environment is decided by your Intuit credentials as much as by the Airbyte setting. Intuit issues development keys that work against sandbox companies and production keys that work against real ones, and they are different values obtained through different parts of the developer portal.
So a team that validates the pipeline against a sandbox company cannot simply untick a box to go live. They need production keys, a fresh refresh token authorised against the real company, and the actual Realm ID rather than the sandbox one. That is a small amount of work and a surprise if nobody expected it.
Plan the production credentials early, because obtaining them involves Intuit rather than only your own team. Testing against a sandbox first remains sensible, and it is worth knowing that the transition is a credential change rather than a configuration flag.
Frequently asked questions
Can one source sync several QuickBooks companies?
No. The Realm ID selects a single company, so create one source per company and union them in a consolidation layer with a company column.
Where do I find the Realm ID?
It is the company ID for your QuickBooks company, visible in Intuit's developer tooling and in the OAuth playground when you authorise against a company.
I tested against sandbox. What changes for production?
More than the toggle. You need production keys from Intuit, a refresh token authorised against the real company, and that company's Realm ID.
My syncs started failing on authentication. What should I check?
The refresh token, since Intuit rotates them. Alert on sync failures rather than relying on somebody noticing, because an authentication failure on this source stops the pipeline entirely.
Can I do this without writing code?
Yes. The setup above is entirely UI-driven, apart from obtaining credentials through Intuit's playground. You will want MySQL views so your application reads a stable interface.
Get your QuickBooks data into MySQL
Count your companies first, because that sizes the project. Get production credentials early since the sandbox toggle is not the whole story, name every source after its company, expose views rather than raw tables, and reconcile a period against QuickBooks before anyone relies on it.
Airbyte's connector catalog includes 600+ pre-built connectors, so accounting data can reach an application and a warehouse at once. For another accounting source scoped the same way, see Xero to BigQuery, and for payment data alongside it, Stripe to BigQuery.
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.