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.
No credit card required.
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
Last updated September 2026
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
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 / 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
Three steps, minutes end to end, covered by flat data integration pricing from $49 a month.
STEP 01
Pick the pair
Connect Square and Snowflake 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.
Prefer to understand the moving parts first? Our long-form guide to the Square to Snowflake guide covers the field-by-field detail, the failure cases, and what changes at volume.
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.
Is there a prebuilt Square connector for Snowflake?
Yes. This Square to Snowflake 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 Snowflake 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 Snowflake?
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 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.
More pairs from the API connector library
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.
No credit card required.