# Syncing organization memberships via webhooks
## Subscribe to the right events
In the dashboard webhook endpoint, subscribe to the org lifecycle set:
organization.created, organization.updated, organization.deleted, and
organizationMembership.created, organizationMembership.updated,
organizationMembership.deleted. Membership changes are the events; the
invitation events are not.
## The missing-user race
A user invited to an org who has never signed in to your app has no local
users row. When organizationMembership.created arrives, its user id foreign
key points at nothing.
The safe handling:
1. Look up the local user by Clerk user id.
2. If missing, do NOT fabricate a row. Log it (a pending-memberships table
works well) and return 200.
3. On first sign-in, after your user provisioning creates the row, replay
any pending memberships for that Clerk user id.
4. Membership updated and deleted events for an unknown user are safe to
drop with a log line; there is nothing local to update.
## The order in your handler
1. Verify the Svix signature first, as with user webhooks.
2. Dedupe by svix-id.
3. Route by event type: org events update your orgs table, membership events
update your memberships table keyed by (org id, user id).
4. For membership events, check the local user row exists before writing the
membership. If it does not, park it as pending.
5. Return 200 only after the write (or the parking) commits.
## Checklist
- The pending-memberships replay runs on every sign-in, not just the first
one ever, because a user can be invited to a second org later.
- Membership role changes (member to admin) flow through
organizationMembership.updated. If your app caches roles, invalidate on
this event.
- Deleting an org locally on organization.deleted is a business decision:
soft-delete if any billing or audit data references it.