Shopify to Convex: How to Move Your Data
Move Shopify into Convex with Airbyte. Why Shopify stays the system of record, and how to design an application around data that is slightly behind.
Moving Shopify into Convex is usually about building something Shopify does not do. A customer portal, a loyalty scheme or a bespoke storefront needs product and order data inside an application backend, while the store itself carries on taking money.
This guide covers the managed path with Airbyte. Two things shape the build: Shopify remains the system of record and this copy must never pretend otherwise, and your application will be showing customers data that is slightly behind.
Shopify to Convex at a glance:
Why move data from Shopify to Convex?
One situation genuinely suits this, and it is worth stating precisely.
The good case is building an application beside your store. Convex is a backend for software you are writing, so a customer portal showing past orders, a loyalty scheme reading purchase history or a custom experience over your catalogue all need that data where your functions can reach it.
The poor case is analysis, since neither Shopify nor an application backend is where you should be aggregating years of trading. If somebody wants revenue trends or cohort behaviour, Shopify to BigQuery answers that far better and leaves your application alone.
What do you need before you start?
Four things, and the first is an architectural decision rather than a credential:
A rule about who owns the data. Shopify stays the system of record for orders and inventory, and this pipeline is one-way, so your application reads this copy and writes to Shopify through its own API rather than into these tables.
A custom app with the scopes your streams need. Shopify grants access per resource and an ungranted scope removes the stream rather than raising an error. The Shopify source documentation lists which scope each stream requires.
Your shop name, which is the subdomain. The portion before myshopify.com rather than the domain customers type, which stores with a long-established custom domain often have to look up.
A Convex deployment with its naming rules checked. The destination is in beta and imports only, so prove it works before anything customer-facing depends on it.
If your organisation restricts access by IP, add the Airbyte Cloud IP addresses to the allow list before you begin.
How do you build a Shopify to Convex pipeline in Airbyte?
Step 1: Decide what the application shows and what it fetches live
Split your application's screens into things that can be slightly behind and things that cannot. A customer's order history from last year is fine from a mirror; whether an item is in stock right now, or whether an order shipped this morning, is not. The first group comes from this pipeline and the second should call Shopify directly, and deciding that now shapes both the sync and the application.
Step 2: Configure the Shopify source
Click Sources in the left navigation, then New Source, and select Shopify, following adding a source. Supply the shop subdomain, credentials and start date. Check the discovered streams against what you expected, because a missing scope produces a missing stream rather than a complaint.
Step 3: Configure the Convex destination
Click Destinations, then New Destination, and select Convex, following adding a destination. Supply your deployment details and access key, checking table names against Convex's rules first. Treat the imported tables as a read model your application queries rather than as its schema.
Step 4: Create the connection and watch the bulk streams
Click Connections, then New connection, select your streams and a sync mode. Rate limit warnings in the logs are normal for this source. A bulk stream that looks stalled on a large store is different, and the bulk job checkpoint setting exists for exactly that.
Then design the application around the lag rather than hoping nobody notices it.
Who owns an order once it is in two places?
Shopify does, and your application has to be built as though that is true. The pipeline runs one way, the Convex destination imports rather than exporting, and nothing your functions write to these tables will ever reach the store. A record updated in Convex is a record that disagrees with the place money actually moves.
That is easy to say and easy to violate accidentally, because the imported tables look exactly like tables your application could own. A developer adding a field to track something useful, or marking a record as handled, has created state that the next sync may overwrite and that Shopify knows nothing about.
So keep two kinds of table apart. The imported ones are a read model, replaced by the pipeline and never written to by your code. Anything your application owns, including its own annotations against a Shopify order, lives in separate tables keyed by the Shopify identifier. Writes that must change the store go through Shopify's own API, and the next sync brings the result back.
What does a customer see when the data is behind?
Whatever was true at your last sync, which is a different standard from the one an internal dashboard is held to. A stale figure in a report annoys an analyst; a customer portal saying an order has not shipped when it shipped this morning generates a support ticket and a small loss of trust.
Order status is the field where this hurts most, because it changes throughout an order's life and customers check it precisely when it is changing. Stock levels are the other one, since showing something as available after it sold out is worse than showing nothing, and both are exactly the values that move between syncs.
Design for it rather than around it. Serve order history, product descriptions and anything else that changes slowly from the imported tables, and call Shopify directly for the handful of values that must be current. Showing when the data was last updated is a small honesty that prevents most of the confusion, and it costs one field your sync already carries.
Frequently asked questions
Can my application write back to Shopify through this?
No. The pipeline is one way and the destination imports only, so writes that must change the store go through Shopify's own API.
Where should my application's own data live?
In separate tables keyed by the Shopify identifier. Writing into the imported tables risks being overwritten by the next sync.
A stream is missing entirely.
A missing scope. Shopify grants access per resource and removes the stream silently, so compare discovery against what you expected.
A stream seems to hang on a large store.
It is probably served by the bulk API, which submits a job and waits. Adjust the bulk job checkpoint setting rather than restarting and losing progress.
Can I do this without writing code?
The pipeline, yes. The application reading it is code, and the decisions about what it serves from the mirror are the part that matters.
Get your Shopify data into Convex
Treat Shopify as the system of record and these tables as a read model your code never writes to, keeping your application's own state in separate tables keyed by the Shopify identifier. Check discovery against your expected streams, since a missing scope is silent. Then split your screens by how fresh they must be, call Shopify directly for order status and stock, and show customers when the rest was last updated.
Airbyte's connector catalog includes 600+ pre-built connectors, so store data can power software your storefront never could. For another application backend into the same destination, see Firebase Realtime Database to Convex, and for analytical results into the same destination, ClickHouse to Convex.
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.