Question 1

Which Stripe objects can be replicated?

Accepted Answer

The billing surface people actually report on: customers, subscriptions and subscription items, invoices and invoice line items, charges, payment intents, payment methods, refunds, disputes, credit notes, coupons, discounts, products, prices, plans, balance transactions, payouts and events. Between them these cover recognised revenue, failed payments and churn, which is most of what finance and growth teams ask for.

Question 2

Do you read the events API or paginate objects?

Accepted Answer

Both, and which 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 fetch 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 context when reasoning about how quickly a change appears in the data warehouse.

Question 3

Can we backfill full history?

Accepted Answer

Yes. The first run paginates each object from the beginning rather than starting at the connection date, so historical invoices and charges come across. This matters for Stripe more than for most sources, because revenue reporting is inherently retrospective and a billing dataset that starts on the day you connected is not much use for cohort or retention analysis. Large backfills stage through S3 and load with COPY, which keeps the initial load practical. Once the backfill is done, ongoing ETL runs move only the changes.

Question 4

How do Stripe amounts and metadata land in Redshift?

Accepted Answer

Amounts are integers in Stripe's smallest currency unit and arrive that way, so dividing by a hundred is a modelling decision you make downstream rather than something applied for you. Timestamps become TIMESTAMP columns. Metadata and other nested objects map to SUPER, Redshift's semi structured type, so custom keys your application writes into Stripe metadata remain queryable instead of being flattened away or dropped.

Question 5

Why replicate Stripe into a data warehouse?

Accepted Answer

Because revenue questions almost always need a join. Tying subscription changes to product usage, or failed payments to support tickets, means billing data has to sit beside the rest. Stripe's own reporting is good at Stripe and unaware of everything else. ETL into a data warehouse gives you a queryable billing history you can model to your own revenue definitions rather than accepting the ones the dashboard offers.

Sync Stripe to Redshift

Sync Stripe to Redshift with Polytomic

The full billing surface

Events where available

Metadata kept intact

Or sync Redshift to Stripe

Trusted by businesses worldwide

Step-by-step integration guide

Connect Stripe in Polytomic

Connect Redshift in Polytomic

Create a sync between Stripe and Redshift

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 Redshift?