Square to BigQuery integration for analytics-ready sales data
The Square to BigQuery integration from Adapters loads payments, orders, line items, refunds, and processing fees from the Square API into partitioned BigQuery tables on an incremental schedule, so cohort, margin, and reconciliation models run on a full multi-location history instead of a manual export. Field mapping is no-code, so try it against sample records in the live demo.
The live demo needs no card, and Starter is $49 a month.
Field mapping auto-plugged · tap a port to rewire
Plug a source port into
Transform on this cable
JSON in
JSON out
5 sample records ready
What running Square to BigQuery by hand costs you
- The Square API scopes data per location and paginates by cursor with rate limits, so backfilling every location into BigQuery by hand is slow to script and brittle.
- Order edits, refunds, and voided payments change records after the sale, and a naive nightly dump into BigQuery misses those updates.
- True margin blends Square sales with cost of goods, fees, and ad spend, which needs a partitioned warehouse table, not a folder of exported reports.
The field mapping, out of the box
All 6 of these Square to BigQuery fields arrive mapped. Rewire any of them, or add your own, in the same visual data mapping tool you use for every adapter.
Input / SQUARE
Output / BIGQUERY
Transforms included
Incremental loads use the Square updated_at watermark so edits, refunds, and voids flow through on the next run; minor-unit amounts (cents) cast to BigQuery NUMERIC dollars, ISO 8601 timestamps land as TIMESTAMP in UTC, tables partition by payment date, and line items land in their own table so margin and cohort models read one clean, deduplicated sales history.
Square to BigQuery in depth
Payments into BigQuery, where the quota that stops you is not the one you were watching and floating point is the thing that quietly costs money. Read from Square and Google documentation, facts current as of 1 September 2026.
Square money is an integer in the smallest denomination
Square documents that a monetary amount is specified in the smallest denomination of the currency, so USD amounts are cents and 4250 means $42.50. Currencies such as the Japanese Yen are zero-decimal, where the smallest unit is one yen and no division applies. Any pipeline that hardcodes a divide by 100 misstates every zero-decimal currency by a factor of one hundred, with no error raised anywhere. Branch on the currency code.
The last page of a Square result set has no cursor
Square paginates with an opaque cursor. The first call omits it, each response carries the cursor for the next page, and the last page does not include one. That absence is the terminator, and it is the single most common place this integration breaks: code that loops while a cursor is truthy works, code that loops on a fixed page count silently drops the tail of the data. Default and maximum page sizes vary per endpoint, so read the limit for each one rather than assuming a shared value.
Square does not publish a rate limit number, so do not hardcode one
We are not going to print a figure here, because Square does not publish one and its own developer forums carry unanswered questions asking for it. That is worth stating plainly rather than repeating a number from a blog post. The correct design is to treat the rate limit as unknown and discoverable: handle the rate limit error explicitly, back off exponentially with jitter, and let observed throughput settle wherever it settles rather than tuning to a constant that was never documented.
Use NUMERIC for money, never FLOAT64
BigQuery NUMERIC carries 38 digits of precision and 9 decimal places and is exact. FLOAT64 is binary floating point, where most decimal fractions have no exact representation, so sums drift by small amounts that grow with volume. On payments data that produces a revenue total which is almost right and never reconciles. Choose NUMERIC at table creation, because changing it later means reloading everything.
The load job quota is per table, per day
BigQuery allows 1,500 load jobs per table per day and 100,000 per project per day. A pipeline that loads Square payments every minute needs 1,440 jobs a day for one table, which is inside the limit with almost nothing to spare, and any retry or backfill pushes it over. Batch to a handful of loads per hour, or use streaming, rather than designing a per-minute load and discovering the ceiling during an incident.
File and row limits fail a load rather than warning
A single load job accepts at most 15 TB and runs for at most 6 hours. CSV and newline-delimited JSON have a 100 MB maximum row size, and compressed CSV or JSON files are capped at 4 GB against 5 TB uncompressed. Batch load jobs are free and run on a shared slot pool, so the cost argument favors batching anyway. Nested payment objects are what push a row towards the size ceiling.
Reconcile on sums in integer cents
Compare the daily count of payments and the sum of gross amounts on both sides, in integer cents rather than converted dollars, and alert on any non-zero difference. Doing the comparison in cents means a float precision problem shows up as a mismatch instead of hiding inside a rounding tolerance. Related route: Stripe to BigQuery.
How it goes live
Moving Square data into BigQuery on flat data integration pricing from $49 a month.
STEP 01
Pick the pair
Authorize a read scope on Square and a write scope on BigQuery, nothing wider.
STEP 02
Confirm the mapping
Check that payment.id lands in fct_payment.payment_id and payment.updated_at in fct_payment.loaded_at on a sample record.
STEP 03
Schedule the sync
Turn on the SQUARE → BIGQUERY schedule; failed records retry and every run is logged.
Square to BigQuery sync common questions
How do you connect Square to BigQuery?
Through the Square API rather than a direct link, because BigQuery cannot query Square. A connector authenticates with OAuth, reads payments, orders, line items, refunds, customers and settlements, then loads them into partitioned BigQuery tables and merges on the Square object ID.
How should Square tables be partitioned in BigQuery?
Partition on the transaction or created date and cluster on location ID. Retail queries almost always filter by date range and store, so that combination cuts the bytes scanned dramatically. Since BigQuery bills on bytes processed, partitioning here has a direct and visible effect on the monthly bill.
How do you reconcile Square deposits in BigQuery?
Load settlements alongside payments. A Square deposit is the net of gross sales, processing fees, refunds and adjustments in the settlement period, so reconciling against payments alone never balances. With both tables loaded, a settlement joins to its component payments and the bank line ties out.
How often should Square sync to BigQuery?
Hourly covers most retail reporting, and daily is enough if the only consumer is a next morning dashboard. Sub hourly is rarely worth the API traffic unless something operational depends on it, because Square data settles over hours anyway as tips, refunds and adjustments land.
How does the Square to BigQuery sync work?
The Square to BigQuery integration from Adapters loads payments, orders, line items, refunds, and processing fees from the Square API into partitioned BigQuery tables on an incremental schedule, so cohort, margin, and reconciliation models run on a full multi-location history instead of a manual export. Field mapping is no-code, so try it against sample records in the live demo.
How much does the Square BigQuery integration cost?
The Square to BigQuery pair is included on every plan: Starter $49, Growth $149, Scale $399 a month. You pay per plan, not per row or task, so a busier month costs the same.
Do I need to write code to connect Square and BigQuery?
No. Fields are auto-mapped the moment you pick the pair, and you can rewire any mapping visually before the first sync. Incremental loads use the Square updated_at watermark so edits, refunds, and voids flow through on the next run; minor-unit amounts (cents) cast to BigQuery NUMERIC dollars, ISO 8601 timestamps land as TIMESTAMP in UTC, tables partition by payment date, and line items land in their own table so margin and cohort models read one clean, deduplicated sales history.
Related Square and BigQuery connectors
Browse the full api connector library, or request a pair you do not see.
Square and BigQuery, finally in agreement
Map the pair once and let it sync on schedule. Flat price from $49 a month, no per-task fees.
The live demo needs no card, and Starter is $49 a month.