Square to Snowflake integration for analytics-ready sales data
The Square to Snowflake integration from Adapters loads payments, orders, line items, refunds, and processing fees from the Square API into Snowflake tables on an incremental schedule, so sales, margin, and reconciliation models read a full history across every location instead of exporting reports by hand. Field mapping is no-code.
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 Snowflake by hand costs you
- Square scopes payments and orders per location and paginates by cursor, so pulling a full multi-location history into a warehouse means chaining many throttled API calls.
- Processing fees and refunds arrive as separate objects, and tying them back to the original payment in a spreadsheet is slow and easy to miscount.
- Comparing Square in-store sales against online channels and ad spend needs one warehouse table, not a stack of per-location CSV exports.
The field mapping, out of the box
All 6 of these Square to Snowflake 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 / SNOWFLAKE
Transforms included
Incremental loads use the Square updated_at watermark per location so only new and changed payments come through each run; minor-unit amounts (cents) cast to Snowflake NUMBER dollars, ISO 8601 timestamps become TIMESTAMP_NTZ in UTC, and processing fees and refunds join back to their payment so gross, fee, and net models read one deduplicated table.
Square to Snowflake in depth
Payments into a warehouse for analysis rather than bookkeeping. The trap is not throughput, it is that Snowflake will quietly round your money column to whole dollars if you let it. Read from Square and Snowflake 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.
Snowflake NUMBER defaults to zero decimal places
A column declared as plain NUMBER in Snowflake is NUMBER(38,0). Load a dollar amount into it and the cents are gone, silently, with no error and no warning. Because Square sends integer cents, a pipeline that divides by 100 and lands the result in a default NUMBER column rounds every transaction to the nearest dollar. Declare NUMBER(18,2) explicitly, or keep the integer cents and divide at query time.
Unquoted identifiers fold to uppercase
Snowflake folds unquoted identifiers to uppercase, where Postgres and Redshift fold to lowercase. A script that works against one target returns nothing against the other, and the error reads as missing data rather than a naming problem. Pick a convention before the first load and apply it everywhere, because changing it later means rewriting every downstream query.
Stage files at the size Snowflake actually wants
Snowflake recommends compressed data files of 100 to 250 MB, and explicitly does not recommend files of 100 GB or more. Payments data naturally arrives as a very large number of very small records, so the failure mode here is thousands of tiny files rather than one enormous one. Batch the writes into files in the recommended range. Snowpipe lands data within about a minute once the file is staged.
Reconcile on sums, not on row counts
Row counts reconcile perfectly on a load that has rounded every amount to the nearest dollar. Compare the sum of the gross amount per day on both sides, in integer cents, and alert on any difference at all. That is the only check that catches the NUMBER precision problem, and it catches it on day one rather than during a quarterly review. Related route: Stripe to Snowflake.
How it goes live
Moving Square data into Snowflake 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 Snowflake, 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 → SNOWFLAKE schedule; failed records retry and every run is logged.
Square to Snowflake sync common questions
How do you get Square data into Snowflake?
Through the Square API, reading orders, payments, refunds, customers, catalog items and settlements per location, then staging the results and merging them into Snowflake tables. Square has no native warehouse export, so a connector holds the OAuth credentials and owns the incremental read on updated_at.
Which Square data matters most for analytics?
Payments and orders with their line items, plus settlements if you need to reconcile deposits. Line items are what allow product and category analysis, and settlements are what let you tie Square activity back to the bank. Customers and catalog are useful but rarely the reason the project gets funded.
How do you handle multiple Square locations in Snowflake?
Carry the location ID on every row and load into a single set of tables rather than one table per store. Square location IDs are stable, so a location dimension joins cleanly for store level reporting, and adding a new store then needs no schema change at all.
How are Square refunds represented in Snowflake?
As their own records linked to the original payment, not as edits to it. If refunds overwrite the original payment row, gross sales and refund rate both become unreportable. Load refunds into their own table with the payment ID as the key, then net them in the model rather than in the pipeline.
How does the Square to Snowflake sync work?
The Square to Snowflake integration from Adapters loads payments, orders, line items, refunds, and processing fees from the Square API into Snowflake tables on an incremental schedule, so sales, margin, and reconciliation models read a full history across every location instead of exporting reports by hand. Field mapping is no-code.
How much does the Square Snowflake integration cost?
The Square to Snowflake 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 Snowflake?
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 per location so only new and changed payments come through each run; minor-unit amounts (cents) cast to Snowflake NUMBER dollars, ISO 8601 timestamps become TIMESTAMP_NTZ in UTC, and processing fees and refunds join back to their payment so gross, fee, and net models read one deduplicated table.
Related Square and Snowflake connectors
Browse the full api connector library, or request a pair you do not see.
Square and Snowflake, 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.