Clerk webhooks can synchronize identity events into an email system, but identity state is not the same as marketing permission. A safe implementation verifies the Svix signature, stores each event once, maps it to current application state, and sends only the message the user is eligible to receive.
Use the webhook signing secret and the raw request body to verify the Svix headers before parsing the event. Reject failed verification and keep test and production secrets separate. Verification belongs at the first server boundary, not in a later queue worker.
Insert the webhook message ID into a table with a unique constraint, store the event payload or normalized fields, and return a successful response. Duplicate delivery should resolve to the existing record instead of scheduling another email.
A user.created event may mean account creation, an invitation acceptance, or an identity record created before onboarding begins. Read the application database before choosing a message. Emit a product event such as onboarding_started only when the product state supports it.
Clerk owns identity. The application owns eligibility, account state, and consent. Keep those responsibilities separate in the event model.
Resolve the current primary email address, membership role, organization state, and marketing preference in the worker. Authentication and requested account messages may be necessary, while product announcements require the appropriate consent and suppression checks.
Record the Clerk or Svix event ID, normalized product event, internal job ID, provider message ID, template version, and delivery status. This makes retries safe and gives support a complete explanation when a user reports a missing invitation or duplicate welcome email.
The question here is which one a backend engineer would rather operate. That means SDK depth in the language already in use, whether a retry can safely be replayed, how much the event log tells you when a customer says the email never arrived, and whether the pricing curve stays sane as volume grows.
Applied to how to send emails from clerk webhooks (2026), that means weighing developer experience, SDK breadth, idempotency keys, and operating track record ahead of the rest, against password resets, receipts, and magic links shipped from application code.