Skip to main content
Stripe is available as a source connector for PostgreSQL or Airtable delivery. It supports connection testing, typed discovery, preview, pagination, full and incremental stream extraction, empty streams, SQL models, and idempotent Upsert delivery.
Validated paths include Stripe → PostgreSQL and Stripe → Airtable. Stripe cannot be selected as a destination.

Supported streams

The following 34 streams are available: Stripe Connect, Issuing, Treasury, Financial Connections, Terminal, and the broader Tax API are not currently exposed as selectable streams.

Authentication

Use a Stripe secret key or a restricted key with read access to every stream you plan to select. Supported key prefixes are sk_test_, rk_test_, sk_live_, and rk_live_. Use a restricted read-only key when possible. Never place a Stripe key in SQL, pipeline names, screenshots, logs, issue reports, or support messages.

Create a Stripe connection

  1. Open Connections and click + New Connection.
  2. Select the Source role and choose Stripe.
  3. Enter a descriptive connection name.
  4. Paste the secret or restricted key.
  5. Click Test Connection.
  6. Save the connection after the test succeeds.
The connection test validates authentication without copying Stripe records.

Discover and select streams

  1. Create a pipeline with the saved Stripe source.
  2. Open Source.
  3. Click Discover catalog.
  4. Search or filter the discovered stream catalog.
  5. Select only the streams the pipeline will model and deliver.
  6. Preview representative rows and click Save stream settings before configuring destinations.
A valid empty Stripe response is successful. New or lightly used accounts commonly return zero rows for charges, refunds, subscriptions, or disputes. Empty streams still complete with a typed staging relation.

Sync modes

Streams with a stable created cursor can use Incremental sync. Cursorless singleton, catalog, and child streams use Full Table mode. Use Full Table for the first validation run. Move eligible streams to Incremental only after the initial run succeeds and the destination key is verified.

Destination requirements

Create or explicitly reconcile PostgreSQL destination tables before delivery. For Airtable, create the destination table and writable fields in Airtable, then configure field mappings and a stable merge key. The runner does not create final tables while a pipeline run is executing.
  • Use a stable Stripe id as the primary key where the resource exposes one.
  • Keep model output columns aligned with destination names and types.
  • Use Upsert for repeatable runs.
  • Exclude internal _dlt_* columns from final models.
  • Prefer explicit columns over SELECT * because Stripe may add optional fields to API responses.
For singleton resources such as account, use a stable identifier returned by discovery or an explicitly modeled account key.

Sample stable model

This account model selects a stable contract while retaining useful lineage:
Validate and preview the model before creating or reconciling its destination table. See the complete Stripe-to-PostgreSQL example.

Errors and retries

  • AUTHENTICATION_ERROR: Stripe rejected the key.
  • PERMISSION_ERROR: the key cannot read a selected endpoint.
  • RATE_LIMIT_ERROR: retry after the requested delay.
  • SCHEMA_ERROR: a response did not match the supported shape.
  • Destination validation errors identify a missing schema, table, column, or incompatible key before delivery.
When reporting an issue, include the pipeline run ID, stream, approximate timestamp, Stripe test or live mode, and displayed error code. Do not include the key or authorization headers.

Current limitations

  • Stripe is source-only.
  • Validated destination paths are PostgreSQL and Airtable.
  • Webhook ingestion and write-back to Stripe are not supported.
  • Feature-gated stream families listed above are not selectable.
  • API fields can vary by account and API version; refresh discovery before adopting new fields.