Prestashop to BigQuery: How to Move Your Data
Move PrestaShop into BigQuery with Airbyte. Enabling the webservice, why per-resource key permissions cause missing streams, and pacing syncs against your shop.
Moving PrestaShop into BigQuery lets you analyse commerce data alongside everything your shop does not know about: acquisition cost, support load, lifetime value. PrestaShop records what was ordered and by whom, and the commercially interesting questions all need something it has never seen.
This guide covers the managed path with Airbyte. Two things shape it, and both come from PrestaShop being software you host yourself: the API is switched off until you enable it, and every access key carries its own permissions.
PrestaShop to BigQuery at a glance:
Why move data from PrestaShop to BigQuery?
Two situations account for most of these pipelines.
The first is joining orders to acquisition data. What a customer cost to acquire, whether they came back, and what they were worth over two years are questions your shop cannot answer alone, and a warehouse is where the advertising and support data meet the transactions.
The second is reporting that does not touch the production shop. Running analytical queries against the database serving your storefront is a reliable way to make the storefront slow, and a warehouse copy removes that risk entirely.
What do you need before you start?
The first two are settings inside PrestaShop rather than anything to do with Airbyte:
The webservice feature enabled. It is disabled by default and needs switching on before first use, under Configure, Advanced Parameters and then Webservice. Nothing will connect until you do. The PrestaShop source documentation covers the setup.
An access key with the right permissions. Created on that same page, and PrestaShop lets you choose which resources each key can reach, by section or by type of access. Grant read on everything you intend to sync, because a resource you did not tick simply will not be available.
Your shop URL in the right form. Without a trailing slash, and over HTTPS, since only HTTPS URLs are supported. Both catch people, and both produce a connection failure rather than a helpful message.
A BigQuery service account and dataset. With the BigQuery User and BigQuery Data Editor roles. Set the dataset location to match your advertising and support datasets, since joining them is the point and it cannot be changed after creation.
Finally, know when your shop is quiet, because PrestaShop runs on a server you pay for and this pipeline competes with your customers for it.
How do you build a PrestaShop to BigQuery pipeline in Airbyte?
Step 1: Enable the webservice and scope the key
Switch the webservice on, then create a key granting read access to the resources you actually need rather than everything available. Write down what you granted, because the permission list is the thing you will check when a stream turns out to be missing later.
Step 2: Configure the PrestaShop source
Click Sources in the left navigation, then New Source, and select PrestaShop, following adding a source. Enter the access key, the shop URL without a trailing slash, and a start date in year, month and day form. Data added on and after that date is replicated.
Step 3: Configure the BigQuery destination
Click Destinations, then New Destination, and select BigQuery, following adding a destination. Supply the project, dataset and service account key. Batched standard inserts is the default and is adequate, because even a busy shop produces modest volumes by warehouse standards.
Step 4: Select streams deliberately and schedule off-peak
Click Connections, then New connection, and select streams with a sync mode each. The catalogue is very large and most of it describes shop configuration rather than trading activity, so take what your analysis needs rather than everything on offer.
Schedule the first sync overnight. A full read across orders, order details and products is real load on a PHP application, and the initial one is by far the heaviest.
Which streams actually matter?
The catalogue runs to dozens of streams, and the split is stark. Orders, order details, order histories, order payments, customers, products and stock availables carry your trading activity. Zones, weight ranges, tax rules, image types, price ranges and languages describe how the shop is configured.
That second group is not useless, since a handful of them turn identifiers into names. Countries, currencies and order states are worth taking as reference tables precisely because without them your order rows carry codes nobody recognises. The rest earn their place only if a specific question needs them.
The reason to be selective is not warehouse cost, which is negligible here. It is the load on your own server, since every stream is more requests against the application serving your customers. On a hosted platform you would be spending somebody else's capacity, and here you are spending your own.
Why is a missing stream usually a permission?
Because PrestaShop grants access per resource on each webservice key. You choose among a wide array of permissions, either by section or by type of access, so a key can legitimately read orders and be unable to see customers.
That is a good security model and an awkward failure mode, because the symptom is an absent or empty stream rather than an error naming the permission. Somebody eventually notices a table that never filled, and by then the connection between cause and effect is not obvious.
So keep the record of what you granted, and check every selected stream produced rows after the first sync. It is also worth using a key dedicated to this pipeline rather than one shared with a plugin, since somebody adjusting permissions for another tool should not quietly change what your warehouse receives.
Frequently asked questions
The connection fails and my key looks right. What now?
Check the webservice is enabled in PrestaShop, since it is off by default. Then check the shop URL is HTTPS with no trailing slash.
Why is one stream empty when others work?
Almost certainly a permission on the webservice key, since PrestaShop grants access per resource. Add the permission and refresh the source schema.
Should I sync all the streams?
No. Most describe shop configuration rather than trading activity. Take your order and customer streams plus the few reference tables that resolve identifiers to names.
Will syncing slow my shop down?
It can, because PrestaShop runs on your own server. Schedule syncs outside peak shopping hours, and run the first one overnight.
Can I do this without writing code?
Yes. The setup above is UI-driven on both sides. You will want BigQuery views joining orders to your advertising and support data, which is where the analysis lives.
Get your PrestaShop data into BigQuery
Enable the webservice first, scope a dedicated key and record what you granted, then select streams against what your analysis needs rather than what the catalogue offers. Schedule around your shop's traffic, and check every stream produced rows before anyone builds on the data.
Airbyte's connector catalog includes 600+ pre-built connectors, so commerce data can sit beside the marketing and support sources that explain it. For another self-hosted shop platform, see WooCommerce to Elasticsearch, and for the paid media side of acquisition, Facebook Ads 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.