Question 1

Which Stripe objects can be replicated?

Accepted Answer

Accounts, application fees, balance transactions, charges, checkout sessions, coupons, credit notes and their line items, customers, disputes, invoices along with invoice items, line items and payments, meters, payment intents and methods, payouts, plans, prices, products, refunds, subscriptions with items and schedules, tax rates, transfers and reversals, Capital objects where enabled, and Stripe reports. Events is also selectable as a table in its own right.

Question 2

Do you read the events API or paginate objects?

Accepted Answer

Both, and which one applies depends on the object. Initial and full reads paginate each object list endpoint. For incremental runs, many objects use filtered event reads and then extract or refetch the changed object, while others stay on the object or report APIs because events do not give a complete picture for them. You do not configure this per object, but it is useful to know when reasoning about how quickly a change appears. Either way it is one ETL configuration rather than two pipelines to keep in step.

Question 3

Can we backfill full history?

Accepted Answer

Yes, and the first run does exactly that by paginating the complete collection for each selected object. The constraint to understand is on the incremental side: Stripe retains events for roughly thirty days, so event based reads cannot substitute for object pagination when reaching back further than that. This is the usual reason a long paused sync needs a full resync rather than simply resuming from where it left off.

Question 4

How are refunds and disputes handled?

Accepted Answer

Charges are never deleted in Stripe, so a refund does not remove a row. Refund activity updates the state of the charge, and refunds are also available as a standalone object, which is usually the better one to model against because it carries its own amounts and timestamps. Disputes are read through dispute events on incremental runs. For objects that do support deletion, customers being the common case, deletion markers are emitted rather than rows being left behind.

Question 5

Why replicate Stripe into a data warehouse?

Accepted Answer

Because revenue questions are rarely only about billing. Net revenue retention, expansion and churn need subscription state joined to product usage and account ownership, and none of those live in Stripe. ETL into a data warehouse puts the billing objects next to everything else, at a grain you control, and gives finance and analytics one definition of a customer instead of two that disagree at month end.

Sync Stripe to Snowflake

Sync Stripe to Snowflake with Polytomic

The full billing surface

Events where available

Deletion markers emitted

Or sync Snowflake to Stripe

Trusted by businesses worldwide

Step-by-step integration guide

Connect Stripe in Polytomic

Connect Snowflake in Polytomic

Create a sync between Stripe and Snowflake

Map fields and enable the sync

Frequently asked questions

The sync and ETL platform that does it all

Powerful data sync

Advanced analytics

Enterprise security

Easy setup

Ready to connect Stripe with Snowflake?