> ## Documentation Index
> Fetch the complete documentation index at: https://notifizz.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Send your Clerk authentication emails with Notifizz

> Take over the verification codes, sign-in links, invitations and security alerts Clerk sends today. One template at a time, reversible in one click.

# Clerk connector

Your authentication emails are the ones your users see most: the verification code at sign-up, the sign-in link, the invitation to join a workspace, the alert when someone signs in from a new device. They are also, usually, the only emails that escape your product — composed and sent by Clerk, in Clerk's template, with no way to change a word without leaving your own dashboard.

The Clerk connector turns each of them into a Notifizz event. From there they are emails like any other: your branding, your copy, your statistics, and no deploy to change them.

## TL;DR

* Connect Clerk with a webhook URL and a signing secret. No API key — Clerk's is all-powerful and we do not ask for it.
* Clerk sends `email.created` **before** each email it is about to send. Notifizz turns it into one event per template — `email.created.verification_code`, `email.created.invitation`, and so on.
* **Nothing changes for your users until you flip a switch.** Clerk keeps sending its own emails while you build and test.
* You take over one template at a time, and every step is reversible in one click.

## Before you start

You need admin access to your Clerk instance, and you should do this on your **production** instance if you intend to take over real emails. Slugs and variables are identical between instances, so anything you build against a development instance carries over.

## Connect Clerk

The order below is not the obvious one, and it matters: the webhook URL only exists once the source is created in Notifizz, and the signing secret only exists once the endpoint is created in Clerk. So you start here, finish there, and come back.

<Steps>
  <Step title="Create the source in Notifizz">
    Connectors → New connector → Clerk. Pick the environment, name it, and create. Notifizz generates your webhook URL — leave the signing secret empty for now.
  </Step>

  <Step title="Add the endpoint in Clerk">
    **Clerk Dashboard → Configure → Webhooks → Add Endpoint.** Paste the Notifizz webhook URL.
  </Step>

  <Step title="Subscribe to `email.created`">
    Tick that one event and nothing else. It carries every authentication email; the other Clerk events are not used by this connector.
  </Step>

  <Step title="Copy the signing secret back">
    Clerk shows a **Signing Secret** starting with `whsec_`. Paste it into the Notifizz source. This is what proves each webhook really comes from Clerk — without it every call is rejected.
  </Step>

  <Step title="Check it arrives">
    Trigger a real authentication email — ask for a verification code on your own account. Clerk's **Webhooks → Logs** should show a `Succeeded` delivery. You still receive Clerk's email at this stage: that is expected.
  </Step>
</Steps>

## The events you get

Connecting the source adds these events to your catalogue, each with its own typed properties:

| Event                                            | The email it replaces          |
| ------------------------------------------------ | ------------------------------ |
| `email.created.verification_code`                | Verification code              |
| `email.created.reset_password_code`              | Password reset code            |
| `email.created.magic_link_sign_in`               | Email link — sign in           |
| `email.created.magic_link_sign_up`               | Email link — sign up           |
| `email.created.magic_link_user_profile`          | Email link — verify email      |
| `email.created.invitation`                       | Invitation to your application |
| `email.created.organization_invitation`          | Invitation to an organization  |
| `email.created.organization_invitation_accepted` | Invitation accepted            |
| `email.created.password_changed`                 | Password changed               |
| `email.created.password_removed`                 | Password removed               |
| `email.created.primary_email_address_changed`    | Primary email address changed  |
| `email.created.account_locked`                   | Account locked                 |
| `email.created.new_device_sign_in`               | Sign in from a new device      |

A template with no dedicated event falls back to `email.created` rather than disappearing, so nothing is silently lost if Clerk adds one.

<Note>
  Clerk sends every one of these under a single webhook type, with the template in the payload. Notifizz splits them into one event per template so a campaign listens on the email it actually concerns — you never write a condition to tell a login code apart from a security alert.
</Note>

### What each event carries

Every event carries `recipientEmail` — which is what routes the notification — plus `emailId`, the originating template `slug`, your application's name, URL and logo, and the request context Clerk knows (`requestedAt`, `requestedFrom`, `requestedBy`).

On top of that, each family carries what makes it useful:

* **Codes** — `otpCode`.
* **Email links** — `magicLink` and `ttlMinutes`.
* **Invitations** — `actionUrl`, `inviterName`, `organizationName`, `role`, `expiresInDays`.
* **Sign in from a new device** — `browserName`, `deviceType`, `operatingSystem`, `ipAddress`, `location`, `signInMethod` and `revokeSessionUrl`, the link that lets someone kill a session that is not theirs.

Anything else Clerk puts in the template is preserved verbatim under `clerkTemplateData`, so a new variable on their side is never lost.

Clerk's own HTML and theme are **dropped at the boundary**. The email is rebuilt entirely by your campaign — otherwise Notifizz would just be relaying Clerk's design, which is the opposite of the point.

## Take over your first template

<Steps>
  <Step title="Build the campaign">
    Create a campaign on the event for the template you want — start with one, `email.created.verification_code` is the usual first. Send it to Review, check the rendering, publish it Live.
  </Step>

  <Step title="Check your sender">
    Your Notifizz emails go out from your own verified sending domain, which is probably not the address Clerk uses today. That change is fine, but it is a change: an authentication email arriving from a new address can slip past the filters your users made for themselves.
  </Step>

  <Step title="Turn off Delivered by Clerk">
    In Clerk, open the template and turn off **Delivered by Clerk**. Clerk stops sending it; your campaign takes over from the very next email.
  </Step>

  <Step title="Verify, then move on">
    Trigger the email again and check it arrives. Then repeat for the next template.
  </Step>
</Steps>

<Warning>
  Before turning off a switch, make sure the campaign for that template is **Live**. Turning it off without one does not fall back to Clerk — it removes the email entirely, and a user waiting for a login code stays locked out.
</Warning>

### Rolling back

Turn **Delivered by Clerk** back on. Clerk resumes sending its own version immediately — no deploy, no code, no waiting. That is why taking over one template at a time is worth the extra rounds.

## FAQ

<AccordionGroup>
  <Accordion title="Will my users get two emails during the switchover?">
    No. As long as **Delivered by Clerk** is on for a template, Clerk sends the email and Notifizz deliberately emits nothing. Only when you turn it off does the event fire. And if Clerk ever stops telling us which mode a template is in, Notifizz assumes Clerk is still delivering — the safe side, because the other one duplicates every authentication email you send.
  </Accordion>

  <Accordion title="Why does Notifizz not ask for my Clerk API key?">
    Because Clerk's secret key is all-powerful: it can read every user, create sessions, delete accounts. Clerk offers no restricted or partner-scoped version of it. A webhook signing secret is enough to receive events, so that is all we ask for.
  </Accordion>

  <Accordion title="Can a retried webhook send a second code?">
    No. Each event is keyed on the identifier of the Clerk email that triggered it, so a redelivery — automatic retry or a manual replay from Clerk's dashboard — resolves to the same email and does not send twice.
  </Accordion>

  <Accordion title="Clerk shows my webhook as failing. What now?">
    A `401` means the signing secret in Notifizz is not the one on that Clerk endpoint — copy it again from Clerk. A `404` means the source was deleted or the URL points at the wrong one. Anything else is worth reporting to us with the message id from Clerk's log.
  </Accordion>

  <Accordion title="Do I have to take over all thirteen?">
    No. Each template is independent. Take over the ones where your branding matters and leave the rest to Clerk for as long as you like.
  </Accordion>

  <Accordion title="What about Clerk's other events, like user.created?">
    Not yet. This connector covers authentication emails. Tell us what you would build with the others and it will help us prioritise.
  </Accordion>
</AccordionGroup>

## See also

* [Connector webhooks](/docs/sdks/how-to/connector-webhooks) — signature schemes and the shared webhook contract.
* [Events](/docs/concepts/events) — how an event becomes a notification.