Linking Stytch as a source

Alpha release

This source is currently in alpha. The interface and available tables may change.

The Stytch connector syncs your authentication data into the PostHog Data warehouse, so you can analyze signup cohorts, authentication method adoption (MFA, OAuth, passkeys), and account security signals alongside your product data.

Prerequisites

You need a Stytch project and its API credentials: a project ID and a secret. Consumer (B2C) projects sync the users and sessions tables; B2B projects also sync organizations and members.

Stytch's event logs are not available through its API, so they cannot be synced.

Adding a data source

In PostHog, go to the Sources tab of the data pipeline section.
Click + New source and click Link next to this source.
Enter your credentials (see Configuration below) and click Next.
Select the tables you want to sync, choose a sync method and frequency, then click Import.

Once the syncs are complete, you can start querying this data in PostHog.

When linking Stytch, you'll need:

Project ID – find it under API keys in your Stytch dashboard.
Secret – from the same API keys page.

Stytch's live and test environments are separate: live credentials (project-live-...) sync your live data, while test credentials (project-test-...) sync your test environment's data.

Sync modes

Each table can be synced in one of several modes, depending on what the source supports:

Webhook (when available) – the source pushes changes to PostHog in real time. Fastest freshness, lowest ongoing cost, and the only mode that reliably captures updates and deletes.
Incremental – only new or updated rows are synced on each run, using a cursor field (such as an updated_at timestamp). Cheaper than a full refresh, but deletes aren't captured.
Append only – new rows are appended using a cursor field; existing rows are never updated. Ideal for immutable, append-only tables like event logs.
Full refresh – the whole table is reloaded on every sync. Use it when a table has no reliable cursor or when you need deletions reflected.

See sync methods for a full explanation of how each mode works and how to choose between them.

The users table supports incremental sync on created_at. Stytch exposes no updated-at filter, so incremental syncs only pick up newly created users; run a periodic full refresh to capture changes to existing users. All other tables are full refresh only.

The sessions table only contains currently active sessions (Stytch's API doesn't return expired ones) and is fetched one request per user, so it's off by default – enable it only if the per-user API cost is acceptable for your project size.

Configuration

Option	Type	Required
`Project ID`	text	Yes
`Secret`	password	Yes

Supported tables

Table	Description	Sync method	Incremental field	Primary key
`users`	All users in the project with their auth methods (emails, phone numbers, OAuth providers, TOTPs, passkeys). Stytch exposes no updated-at filter, so incremental syncs only pick up newly created users; run a periodic full refresh to capture changes to existing users	Incremental, Full refresh	created_at	—
`sessions`	Active sessions, fetched one request per user (expired sessions are not returned by the Stytch API). Off by default because of the per-user API cost on large projects	Full refresh	—	—
`organizations`	Organizations in a Stytch B2B project. Errors on consumer (B2C) projects	Full refresh	—	—
`members`	Members across all organizations in a Stytch B2B project. Errors on consumer (B2C) projects	Full refresh	—	—

Troubleshooting

If you get an authorization error, your Stytch project ID or secret is invalid. Create a new secret under API keys in your Stytch dashboard, then reconnect.
If the organizations or members tables fail to sync, your project is likely a consumer (B2C) project – those tables are only available for Stytch B2B projects.

If your sync is failing or data looks wrong, see the Data warehouse troubleshooting guide. If that doesn't help, contact support – we're happy to help.