Source connector

Stripe connector

Stripe integration for databases, warehouses and BI tools

Payments infrastructure for charges, subscriptions, and payouts. Datrise captures Stripe entities such as charges, customers, subscriptions, invoices, and balance transactions, then lands normalized and typed models for warehouse reporting, attribution, and AI workflows.

The Stripe API (dated versioning via the Stripe-Version header, set per account/request) authenticates with API key, OAuth 2.0, incremental runs key on created timestamp filter on list endpoints, or the Events API, and Stripe caps calls at 100 requests/second in live mode (25 requests/second in test mode); many individual endpoints are capped lower, e.g. the Search API at 20 read requests/second.

Of the 5 objects, 2 sync as upserts keyed on the primary key and 3 as append-only streams, so each incremental run moves only what changed since the last watermark. Every object lands in its own table (for example `stripe_charges`) with a schema derived from the Stripe API rather than a flattened CSV, in any of the 43 supported destinations.

Datrise is in early access: pick a destination below to open the Stripe pipeline page, and join the waitlist to get the Stripe connector (ERP) with guided onboarding.

Incremental syncSchema-aware mapping43 destinations available

What Stripe data Datrise extracts

Each object lands in its own typed table. Sync mode is derived from the object: history-style objects append, everything else upserts.

Object	Landing table	Sync mode
charges	stripe_charges	Append-only, incremental by timestamp
customers	stripe_customers	Upsert by primary key, incremental on updated-at
subscriptions	stripe_subscriptions	Upsert by primary key, incremental on updated-at
invoices	stripe_invoices	Append-only, incremental by timestamp
balance transactions	stripe_balance_transactions	Append-only, incremental by timestamp

Stripe API: setup facts for the connector

Verified against the vendor documentation on 2026-09-02. Unknown values are left blank rather than guessed.

API	Stripe API (dated versioning via the Stripe-Version header, set per account/request)
Authentication	API key, OAuth 2.0 — Requests authenticate with a Bearer secret key (sk_live_/sk_test_, unrestricted) or a scoped restricted key (rk_); Stripe Connect platforms additionally use OAuth to access connected accounts.
Pagination	cursor — List endpoints use starting_after/ending_before referencing an existing object ID as the cursor, with limit defaulting to 10 and capped at 100; there is no offset-based random access.
Rate limit	100 requests/second in live mode (25 requests/second in test mode); many individual endpoints are capped lower, e.g. the Search API at 20 read requests/second
Incremental cursor	created timestamp filter on list endpoints, or the Events API — Events are retrievable via the API for only 30 days and delivery order is not guaranteed, so dedupe by event ID rather than by the created timestamp.
Webhooks	Yes — Webhooks / Events (HMAC-signed via Stripe-Signature)
Bulk export	Yes — Sigma (SQL reporting with CSV export) and Data Pipeline
Deletes detectable	Yes — Most objects are never hard-deleted; Customers are the exception — DELETE /v1/customers/:id marks deleted=true and fires a customer.deleted event

Official API reference

What bites when replicating Stripe

The global live-mode rate limit is 100 requests/second per account, but most individual endpoints are independently capped lower (e.g. 25 requests/second) regardless of the account's global headroom.
starting_after/ending_before pagination requires an actual object ID from the previous page; there is no page-number or offset-based random access into a list.
The Events API retains events for only 30 days and does not guarantee delivery order, so incremental sync logic must dedupe by event id, not by the created timestamp.
Most Stripe objects are never hard-deleted; only the Customer object supports a real `DELETE /v1/customers/:id` call and fires a `customer.deleted` event, so other resources have no delete signal to poll for.

Compare this against every other documented API

Popular destinations for Stripe

Choose a destination below to open the ready pipeline page.

A
Airtable
Relational spreadsheet destination for ops and go-to-market teams.
View pipeline
A
Amazon Athena
Serverless SQL over S3 data lake tables.
View pipeline
A
Amazon DynamoDB
Serverless key-value and document store on AWS.
View pipeline
A
Amazon QuickSight
AWS serverless BI with SPICE and embedded analytics.
View pipeline
A
Amazon Redshift
AWS petabyte-scale warehouse with Spectrum.
View pipeline
A
Amazon S3 Data Lake
Object storage landing zone for parquet and snapshots.
View pipeline
A
Apache Superset
Open-source BI for SQL exploration, charts, and dashboard publishing.
View pipeline
A
Azure Data Lake Storage
ADLS Gen2 object storage for analytics workloads.
View pipeline
A
Azure Synapse
Microsoft analytics workspace with SQL pools.
View pipeline

Stripe connector FAQ

What Stripe data does the connector extract?: 5 objects: charges, customers, subscriptions, invoices and balance transactions. Each lands in its own table with types preserved; history-style objects (3: charges, invoices and balance transactions) load as append-only streams.
Is the Stripe integration incremental?: Yes. After the initial full load, every run reads only records changed since the last watermark (updated-at or event timestamp) and applies an upsert or an append depending on the object.
Where can I load Stripe data?: Into 43 destinations: relational databases, cloud warehouses, data lakes, spreadsheets and BI tools. Each Stripe → destination pair has its own page with the object-to-table mapping.

Related ERP sources

Other sources in the same category, each with its own connector page.

Early access

Launch your Stripe pipeline with guided onboarding

Join the waitlist to get priority access for Stripe integrations with guided setup, schema-aware mapping, and production-grade incremental sync.