Magic Link Webhooks: Get Notified When a Link Is Used

Want another tool to know the instant someone uses, or fails to use, a magic link — without anyone watching a screen? Magic Link PRO can send an outbound webhook for every login event. Open Magic Link → Webhooks, add the address of a service that should hear about activity, choose which events to send, and your site notifies that service as things happen. It works with Zapier, Make, n8n, Slack, and any endpoint that accepts an HTTP POST.

What is a Magic Link webhook?

A webhook is a message your site sends to another tool the moment something happens, so that tool can react without polling or checking a screen. Magic Link fires webhooks from its audit-log events, which turns magic link activity into something you can act on:

• Connect to tools you already use. Zapier, Make, and n8n all accept webhooks, so from one event you can post to Slack, add a spreadsheet row, or update a CRM without writing code.
• Notice trouble early. Repeated failed events are a sign of a problem worth investigating while it is happening.
• Trigger your own follow-up. Someone used their link for the first time — send a welcome message, tag them, start onboarding.
• Keep records outside WordPress. Send events straight to a helpdesk or data warehouse instead of asking people to log in and look.

The Audit Log answers "what happened?" when you go and look. Webhooks answer "tell me when it happens" without you looking.

Events you can send

The delivered and bounced events are about the email, not the link. Subscribe to them if you are chasing "the member says they never got it" — a bounce tells you the message never arrived, a completely different problem from a link that went unused.

How to add a webhook

1. In WordPress, go to Magic Link → Webhooks.
2. Add a new endpoint.
3. Enter the destination URL given to you by the receiving service. In Zapier or Make, create the "Webhook" trigger first and copy the address it shows you.
4. Set a secret — a long random string used to sign each message (see below).
5. Choose which events the endpoint should receive.
6. Save the endpoint.
7. Use the Test Fire button to send a sample message immediately and confirm the other end receives it.

Test Fire is the fastest way to know your setup works — use it before you rely on the connection.

Payload and signature

Each webhook is an HTTP POST with a JSON body in this shape:

{
  "id": 1234,
  "event": "used",
  "occurred": "2026-09-04T10:15:00+00:00",
  "data": {
    "user_id": 42,
    "email": "alex@example.com",
    "ip": "203.0.113.10",
    "meta": {}
  }
}

Every request is signed with HMAC using your endpoint secret and carries these headers so the receiver can verify it is genuine and unaltered:

Why the secret matters

Your webhook address is just a URL, and anyone who learns it could send messages pretending to be your site. The secret prevents that: every message is signed with it, so the receiving service can verify the message genuinely came from your site and was not altered in transit.

• Use a long random string, not a word.
• Use a different secret for each endpoint.
• Treat it like a password — anyone with it can impersonate your site to that endpoint.

If the service you are connecting to supports signature verification, turn it on and give it this secret.

Delivery and retries

Magic Link posts each event to your endpoint immediately. If the receiving service returns a 5xx error or the request fails at the transport level, delivery is retried with exponential backoff — after 30, 60, 120, 240, and 480 seconds — for up to 5 attempts before giving up. A short outage on the other end therefore does not necessarily lose the message. The X-KCML-Attempt header tells the receiver which try it is looking at.

If messages are not arriving

• Use Test Fire first. It isolates the connection from everything else.
• Check the URL is exactly right. A trailing character, or an http that should be https, is enough to break it.
• Check the receiving service is listening. Zapier and Make webhooks sometimes need the scenario switched on before they accept anything.
• Check the event is subscribed. If you only subscribed to used, nothing happens when a link is merely generated.
• Check whether your host blocks outbound requests. Some managed hosts restrict them; if Test Fire never arrives and everything else looks right, ask your host.

Conclusion

Magic Link PRO webhooks push every login event — from generated to used, failed, and bounced — to Zapier, Make, n8n, Slack, or your own endpoint the moment it happens, signed with HMAC and retried on failure. Add an endpoint under Magic Link → Webhooks, confirm it with Test Fire, and you can automate follow-ups and monitoring outside WordPress. To create links from those same external systems, see the REST API.

FAQs

Are Magic Link webhooks free?

No. Outbound webhooks are a Magic Link PRO feature. The free plugin records the same events in the Audit Log, which you review on demand under Magic Link → Audit Log, but it does not push notifications to external services. Webhooks add the "tell me the moment it happens" layer on top of that log.

How do I verify a webhook really came from my site?

Every request is signed with HMAC using your endpoint secret and sent with an X-KCML-Signature header, plus X-KCML-Timestamp and X-KCML-Event. Recompute the HMAC of the payload with your secret and compare it to the signature header. A match confirms the message came from your site and was not altered in transit.

What happens if my endpoint is temporarily down?

Magic Link retries. If your endpoint returns a 5xx error or the connection fails, delivery is retried with exponential backoff — after 30, 60, 120, 240, and 480 seconds — for up to 5 attempts. A brief outage on the receiving side usually will not lose the event. The X-KCML-Attempt header shows which attempt each request is.

Can I send Magic Link events to Zapier or Make?

Yes. Create a "Webhook" trigger in Zapier, Make, or n8n, copy the address it gives you, and paste it as the endpoint URL under Magic Link → Webhooks. Use the Test Fire button to send a sample so the platform captures the payload shape, then build your automation from the events you subscribed to.

What is the difference between the delivered and used events?

delivered means the email carrying the magic link was accepted for delivery to the recipient's mail server — it concerns the email. used means someone actually clicked the link and was logged in — it concerns the link. A bounced event (the email failed to arrive) points to a deliverability problem, which is different from a delivered link that simply went unused.