Collection Name | Read | Write |
---|---|---|
account | ✅ | ✅ |
application | ✅ | |
balance_transaction | ✅ | |
bank_account | ✅ | ✅ |
billing_portal.configuration | ✅ | ✅ |
billing_portal.session | ✅ | ✅ |
charge | ✅ | |
checkout.session | ✅ | ✅ |
country_spec | ✅ | |
credit_note | ✅ | ✅ |
customer | ✅ | ✅ |
customer_balance_transaction | ✅ | ✅ |
dispute | ✅ | ✅ |
event | ✅ | |
fee_refund | ✅ | ✅ |
file_link | ✅ | ✅ |
invoice | ✅ | ✅ |
invoiceitem | ✅ | ✅ |
issuing.card | ✅ | ✅ |
issuing.cardholder | ✅ | ✅ |
issuing.dispute | ✅ | ✅ |
issuing.transaction | ✅ | ✅ |
item | ✅ | ✅ |
line_item | ✅ | ✅ |
mandate | ✅ | ✅ |
order | ✅ | ✅ |
order_return | ✅ | ✅ |
payout | ✅ | ✅ |
person | ✅ | ✅ |
plan | ✅ | ✅ |
price | ✅ | ✅ |
product | ✅ | ✅ |
promotion_code | ✅ | ✅ |
radar.early_fraud_warning | ✅ | |
radar.value_list_item | ✅ | ✅ |
refund | ✅ | ✅ |
reporting.report_run | ✅ | |
reporting.report_type | ✅ | |
reserve_transaction | ✅ | ✅ |
scheduled_query_run | ✅ | |
setup_intent | ✅ | ✅ |
sku | ✅ | ✅ |
source | ✅ | ✅ |
source_mandate_notification | ✅ | |
subscription | ✅ | ✅ |
tax_deducted_at_source | ✅ | |
tax_id | ✅ | ✅ |
tax_rate | ✅ | ✅ |
terminal.location | ✅ | ✅ |
three_d_secure | ✅ | ✅ |
transfer | ✅ | ✅ |
upcoming_customer_invoice | ✅ | |
upcoming_subscription_invoice | ✅ | |
usage_record | ✅ | ✅ |
usage_record_summary | ✅ | |
webhook_endpoint | ✅ | ✅ |
Upcoming Invoices
, which are only generated on-demand as previews.
Since these objects are not persistent in Stripe, they don’t have an id
. In this case, Sequin uses the customer_id
or subscription_id
as a proxy for primary key. For example, the upcoming_customer_invoice
table uses customer_id
as the primary key. The upcoming_subscription_invoice
table uses subscription_id
as the primary key.
Unlike most objects, Stripe doesn’t create Events
for changes to these objects. Instead, Sequin detects other events that are likely to trigger updates on these objects and immediately fetches an updated version from Stripe’s /v1/invoices/upcoming
endpoint to keep your synced data up-to-date.
1000
in your Sequin database.
JSONB
in your Sequin database.
/events
endpoint twice per second to ingest any creates, updates, or deletes.
You can read more about how Sequin’s syncing process for Stripe works on our blog.
insert
, update
, or delete
rows in your Postgres database.
When you’re connected to your database through the Sequin Proxy, the Proxy listens for changes. When you make a mutation, the Proxy applies the mutation to Stripe’s API first. If the mutation succeeds, your database is updated as well. If it fails, your database mutation will be rolled back, and you’ll receive a Postgres error.
Data flows from Stripe to your Postgres database. Your code or SQL client then reads from the database. To mutate your data, you update records in your database. Those mutations are applied to Stripe then to your database.
With this architecture, Stripe remains the source of truth and your database never gets out-of-sync.
insert
to create a new entry in the “Orders” table on Stripe.200
. The body contains the new order.orders
table in your Sequin database.