# 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.