Linking Stytch as a source
Let AI connect your sources for you
Skip the manual setup — run this in your project and the wizard auto-detects your databases and APIs and connects them to PostHog.
Contents
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, sessions, and rbac_policy tables; B2B projects also sync organizations, members, sso_connections, organization_connected_apps, and member_connected_apps.
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_attimestamp). 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.
Several tables are off by default because of their API cost or because they only apply to certain project types:
| Table | Reason | When to enable |
|---|---|---|
sessions | One API request per user | When you need active session data and the per-user cost is acceptable |
organizations | B2B-only | When your Stytch project is a B2B project |
members | B2B-only | When your Stytch project is a B2B project |
rbac_policy | Off by default | When you need to resolve role IDs on members or users |
sso_connections | B2B-only; one request per organization | When you need to analyze SSO connection setup across organizations |
organization_connected_apps | B2B-only; one request per organization | When you need organization-level connected app data |
member_connected_apps | B2B-only; one request per member | When you need member-level connected app data with granted scopes |
Note: The
sso_connectionstable filters out OIDC client secrets and SAML encryption private keys for security.
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 | — | — |
rbac_policy | The project's RBAC policy, one row per role, resource and scope (entry_type tells them apart). Resolves the role IDs on members and the scopes granted to connected apps | Full refresh | — | — |
sso_connections | SAML, OIDC and external SSO connections of every organization, fetched one request per organization. OIDC client secrets and SAML encryption private keys are not synced. Errors on consumer (B2C) projects | Full refresh | — | — |
organization_connected_apps | Connected apps that members of each organization have authorized, fetched one request per organization. Errors on consumer (B2C) projects | Full refresh | — | — |
member_connected_apps | Connected apps each member has authorized, with the scopes granted. Fetched one request per member, so it is off by default because of the API cost on large projects. 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,members,sso_connections,organization_connected_apps, ormember_connected_appstables 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.