WorkOS Integration
This is an implementation guide, not a native integration. Schematic does not offer a turnkey WorkOS connector. WorkOS still works with Schematic today through Schematic’s keys system: you bring the WorkOS organization and user IDs as keys, and everything else behaves normally. This page describes exactly what you would set up.
WorkOS is an authentication and directory provider. Because
Schematic identifies companies and users by your own keys rather than by
Schematic-generated IDs, you can use WorkOS as the source of truth for identity
and layer Schematic entitlements, feature flags, and embeddable components on top
of it without storing any Schematic IDs.
There are three pieces to a complete WorkOS implementation:
- Create companies and users in Schematic keyed by their WorkOS IDs. This happens either inline in your own signup/provisioning flow or from WorkOS webhooks. From then on you address those entities by their WorkOS IDs in every API/SDK call and usage event, so you never need to store or look up a Schematic ID.
- A one-time backfill from WorkOS into Schematic when you deploy, so existing organizations and users don’t have gaps.
- Optionally (recommended), WorkOS webhooks to keep Schematic in sync as your user base changes over time. Not every WorkOS customer needs this; whether it’s worth it depends on how much your organizations and users churn.
How WorkOS maps to Schematic
A WorkOS Organization becomes a Schematic company, a WorkOS User becomes a
Schematic user, and a WorkOS Organization Membership tells you which company
a user belongs to. The WorkOS IDs are stable and globally unique, which makes
them good primary keys. Review
Key Management for background on how
keys work.
This guide assumes you use WorkOS User Management (AuthKit): durable
user_... users, org_... organizations, and om_... memberships. If you use
WorkOS only for standalone SSO, each login gives you a profile rather than a
persistent User Management user, so the user and membership webhooks and list
endpoints below do not apply. In that case, upsert the company and user from your
own callback using whatever stable identifiers you keep, and the rest of this
guide works the same.
The key names workos_organization_id, workos_user_id, and email used
throughout this guide are recommendations, not requirements. Schematic key names
are arbitrary strings, so you can choose names that fit your own conventions.
What matters is that you pick a name for each and use it consistently in every
call. Storing more than one key per entity is encouraged: Schematic resolves
between keys, so a user keyed by both workos_user_id and email can be
addressed by whichever value you have on hand in a given context.
1. Create companies and users keyed by WorkOS IDs
When an organization or user is created in WorkOS, upsert the matching entity
into Schematic and store the WorkOS IDs as keys. Because Schematic upserts are
idempotent, the same call safely creates the entity the first time and updates
it on every call after that.
This guide associates each user with a single company through the company
field, which fits the common case of one user belonging to one organization.
WorkOS users can belong to multiple organizations. If yours do, use the
plural companies field instead and pass the user’s full set of organizations.
Schematic treats companies as the exhaustive list, so it adds new memberships
and removes any you leave out. The webhook handler in section 3 uses this
exhaustive pattern.
Where to make these calls
WorkOS does not run arbitrary custom code for you after a signup. WorkOS Actions are synchronous allow/deny gates for authentication and registration, so they are the wrong tool for syncing to an external system. That leaves two practical places to make the Schematic upserts, and you can use either or both:
- In your own signup/provisioning flow. Wherever your application already creates the organization or user, for example your AuthKit callback handler or the code that provisions a tenant in your database, add the Schematic upsert immediately after. This is something you wire into your own code. It has the lowest latency and keeps creation in your control.
- From WorkOS webhooks. Subscribe to
organization.created,user.created, andorganization_membership.createdand do the upserts in the webhook handler. This is the same handler used for ongoing sync in section 3, so if you handle those events, signup creation is already covered and you may not need any inline calls at all.
Many teams route everything through webhooks so there is a single sync path for creation, updates, and deletes. Wiring the upserts into your provisioning flow is a good choice when you want the company or user to exist in Schematic before the user’s first request completes.
Use the WorkOS IDs in every subsequent call
Once the WorkOS IDs are stored as keys, you address companies and users by
those same IDs everywhere. You never store a Schematic ID.
Checking a feature flag or entitlement:
Tracking usage of a metered feature:
The same WorkOS IDs work for identify events, trait updates, usage retrieval, and embeddable components, which become aware of the logged-in WorkOS user automatically.
2. One-time backfill when you deploy
Creating entities going forward only covers organizations and users created
after you ship. To avoid gaps for everyone who already exists in WorkOS, run a
one-time backfill that pages through WorkOS and upserts each organization, user,
and membership into Schematic using the same keys.
WorkOS list endpoints are cursor-paginated: pass limit (up to 100) and follow
the after cursor from listMetadata until it is empty.
Because upserts are idempotent and matched on keys, the backfill is safe to
re-run. If a company or user already exists with a matching
workos_organization_id or workos_user_id, the record is updated rather than
duplicated.
3. (Recommended) Keep Schematic in sync with WorkOS webhooks
The backfill is a point-in-time snapshot, and creating entities only covers new ones. WorkOS webhooks close the gap for everything that changes afterward: profile and name updates, users moving between organizations, and deletions. Not every WorkOS customer wires this up. If your organizations and users rarely change, the backfill plus signup-time creation may be enough. If your user base churns meaningfully, webhooks keep Schematic accurate without manual cleanup.
Subscribe to the relevant events
In the WorkOS Dashboard, create a webhook endpoint pointing at a public HTTPS URL in your application and subscribe to the events you care about:
user.created,user.updated,user.deletedorganization.created,organization.updated,organization.deletedorganization_membership.created,organization_membership.updated,organization_membership.deleted
Verify and handle each event
WorkOS signs every webhook request with a WorkOS-Signature header. The WorkOS
Node SDK verifies the signature and constructs the event for you with
workos.webhooks.constructEvent. Always verify before acting on a payload, then
translate the WorkOS event into the matching Schematic upsert or delete keyed by
the WorkOS ID.
WorkOS retries on non-2xx responses or timeouts. The handler above does the
Schematic work first and returns 200 only once it succeeds, so a transient
failure returns 500 and WorkOS retries it. Keep the work fast and idempotent.
If processing is heavy, enqueue the verified event, return 2xx immediately, and
do the Schematic work from the queue with its own retries instead. Logging the
WorkOS event id lets you safely skip duplicates.