Configuration
Resources
The two fan-out children exist because Stripe embeds
lines and items as
lists that truncate at 10 with their own has_more. The parent keeps the
embedded copy as raw JSON for reference, and the child resource is the
complete set.
Modes
All resources support full reads. If interrupted, a full read of a top-level resource resumes after its last completed page. The incremental resources arecharges, payment_intents, refunds,
disputes, balance_transactions, payouts, invoices, credit_notes,
checkout_sessions, and events. All follow the same pattern.
The cursor field is fixed by the manifest. Only a lookback window is
user-configurable, which the numeric comparator supports. A lookback matters
here because
created never changes. A refund that settles from pending to
succeeded, or a dispute that resolves, is not re-read by an incremental run
unless a lookback window covers it. Use full runs or the events feed to
capture post-creation mutations.
Behavior
- Auth: HTTP basic with the API key as the username and no password,
matching
curl -u sk_test_…:. - Pagination: Stripe returns no next-page token. The cursor is the id of
the last record on the page (
data.-1.id), echoed back asstarting_after, withhas_moreas the terminator andlimit=100per page. - API version: pinned via
Stripe-Version: 2026-07-29.dahlia, so payload response schema is set by the manifest, not the account’s dashboard setting. The exception isevents.data.object, which is rendered at the version current when each event was created. - Rate limiting: a static 8 requests/second limiter, held below Stripe’s 25 rps sandbox ceiling since one limiter is shared across all concurrently extracting resources. Stripe publishes no rate-limit response headers, so there is no dynamic block.
- Timestamps: every Stripe timestamp is a Unix epoch integer typed
int64, nottimestamptz.