Square to Snowflake integration for analytics-ready sales data

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.

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.

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.

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.

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.

Yes. This Square to Snowflake connector ships prebuilt: the field mapping is wired the moment you pick the pair, transforms are included, and the first sync can run within minutes. No code or engineering sprint required.

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.

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.

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.