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.

Try it in the live demo

No credit card required.

Input

Output

Field mapping auto-plugged · tap a port to rewire

5 sample records ready

Last updated September 2026

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

These cables are pre-wired when you pick the pair. Rewire any of them, or add your own, in the same visual data mapping tool you use for every adapter.

Input / SQUARE

Output / BIGQUERY

payment.id

fct_payment.payment_id

payment.amount_money.amount

fct_payment.amount

payment.created_at

fct_payment.created_at

order.line_item.uid

fct_order_line.line_id

payment.location_id

dim_location.location_id

payment.updated_at

fct_payment.loaded_at

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

Three steps, minutes end to end, covered by flat data integration pricing from $49 a month.

STEP 01

Pick the pair

Connect Square and BigQuery with scoped credentials. About a minute each.

STEP 02

Confirm the mapping

The cables above are pre-wired. Adjust any field, preview the transform on sample records, done.

STEP 03

Schedule the sync

Hourly down to every minute, with retries, alerting, and a full log on every run.

Try it in the live demo Preloads SQUARE → BIGQUERY with sample records

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?

Is there a prebuilt Square connector for BigQuery?

Yes. This Square to BigQuery connector ships prebuilt: the field mapping is wired the moment you pick the pair, transforms are included, and you can try it against sample records in the live demo. No code or engineering sprint required.

How much does the Square BigQuery integration cost?

Pricing is flat and monthly: Starter at $49, Growth at $149, Scale at $399. Every plan includes this pair, visual field mapping, and per-record logs. There are no per-task or per-row fees, so the bill stays the same as volume grows.

How often can Adapters sync Square to BigQuery?

Hourly on Starter, every 5 minutes on Growth, and down to every minute on Scale. Failed records retry automatically with backoff, and alerting plus a full per-record log come standard on every run.

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.

More pairs from the API connector library

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.

Try the live demo

No credit card required.