Moving Auth0 Rules and Hooks to Actions before Auth0 switches them off
Auth0 Hooks stop running after 30 April 2027 and Rules after 31 January 2028, and both have been read-only since November 2024. We export every rule and hook and rebuild each one as an Action on the right trigger. A machine-to-machine client replaces the built-in Management API token. Then we check that your tokens carry the same claims as before.
- 01Export and read every rule and hook
- 02Map to triggers
- 03Replace what Actions don't provide
- 04Rebuild redirects and claims
- 05Test and switch in one deploy
The story
Told without the client's name or anything that could identify them.
A software company's customer identity team had an Auth0 tenant that predated Actions, still full of Rules and Hooks, with the Hooks end-of-life date of 30 April 2027 coming first. Several rules used the global object, called the Management API with the built-in token, or redirected users with context.redirect, and nobody was sure which rules still mattered. We exported every rule and hook with the Deploy CLI into source control and marked each one keep, merge or delete. The survivors were rewritten as Actions on the right triggers, with a machine-to-machine client and Action secrets for Management API calls. Each cut-over disabled the rule and bound the Action in the same deploy, and ID and access token claims matched the captured tokens from the old rules.
why it was urgentAuth0's docs now give two end-of-life dates: 30 April 2027 for Hooks and 31 January 2028 for Rules. Both went read-only on 18 November 2024. Active ones still run, and you can switch them on or off or change their settings, but nobody can edit the code. So a rule that breaks can be disabled or reconfigured, but its code can't be patched. Tenants created since 16 October 2023 never had either.
- openThe dashboard still lists Rules or Hooks that are switched on, and someone has to own them.
- recurringRules use the global object or call the Management API with the built-in token. Actions give you neither.
- blockedA rule sends users to a consent, profile or MFA page with context.redirect. Those flows take the most testing after the move.
- openNobody really knows which rules still matter. The tenant has been running since before Actions existed.
The estate, before and after
Before: Rules and Hooks ran every login
This is what gets switched off. Every login ran the rules one by one, passing state through shared objects and calling the Management API with the built-in token. Hooks handled client credentials and registration. The hooks stop after 30 April 2027 and the rules after 31 January 2028, whether or not anything replaced them.
After: Actions bound to the right triggers
Rules and Hooks are gone. Post-login and credentials-exchange Actions do their job, deployed from source control with the Deploy CLI. A dedicated machine-to-machine client makes the Management API calls, and its secret sits in Action secrets.
How we run it, phase by phase.
5 phases take you from Auth0 Rules and Hooks to Auth0 Actions. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Export and read every rule and hook
We export Rules, Hooks, their configuration values and execution order into source control with the Auth0 Deploy CLI. Then each one gets marked keep, merge or delete. Old tenants tend to carry rules that do nothing now.
- phase 02
Map to triggers
Rules become post-login Actions. Each hook goes to the trigger that matches its old extension point. Client Credentials Exchange hooks move to credentials-exchange, and the pre-registration, post-registration, post-change-password and send-phone-message hooks map across one for one.
- phase 03
Replace what Actions don't provide
Actions don't get a Management API token or a global object. Anything that needs the Management API goes through a machine-to-machine application whose credentials sit in Action secrets. We also cut the number of calls, because tokens can't be cached between executions.
- phase 04
Rebuild redirects and claims
Any context.redirect flow is rebuilt as an api.redirect call with an onContinuePostLogin handler. Custom claims get set with the Actions API, and we check them against tokens we captured from the old rules.
- phase 05
Test and switch in one deploy
Each Action is tested in a development tenant against recorded logins. In production, the same deploy disables the rule and binds the Action to its flow, and we keep the export for rollback until Auth0 removes Rules and Hooks.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Logins run on Actions before the deadline
We turned Rules into post-login Actions and moved Hooks to their matching triggers. So when Rules and Hooks hit end of life, nothing stops adding claims or blocking logins.
- result 02
Applications see the same tokens
ID and access token claims were checked per application against tokens we captured from the old rules. Nothing downstream had to change.
- result 03
Management API calls use a scoped client
The built-in token is gone. A machine-to-machine application with its credentials in Action secrets does that job now, and per-login calls were cut back to stay under the rate limits.
- result 04
Tenant logic lives in source control
Actions code and Deploy CLI configuration are in version control now. Dead rules from earlier years were deleted, not carried forward.
- result 05
Redirect flows were tested in a browser
We rebuilt consent and profile completion redirects with api.redirect and onContinuePostLogin and tested each one through the continue step.
Risks we plan for
-
Shared state between rules
A lot of rules hand data to the next rule through the user or context objects. That doesn't carry over. Auth0 says data changed on the event object isn't visible to other Actions, so chained logic gets redesigned.
-
Management API rate limits
A rule that called the Management API on every login can start hitting rate limits once each Action fetches its own token. We cut those calls, or move the data to app metadata, before go-live.
-
Redirect flows that half work
Auth0's own guide says getting every redirect right in Actions is beyond its scope. So consent and profile completion flows get full browser tests, continue step included.
-
Two deadlines, and Hooks go first
Hooks stop running and get removed after 30 April 2027. Rules follow after 31 January 2028. Whatever hasn't been migrated stops adding claims or blocking logins on that day, and it can fail open or fail closed. A plan built only around the 2028 date misses the hooks.
Where AI helps, and where it needs guardrails
Auth0 for AI Agents went GA on 19 November 2025 with Token Vault and asynchronous authorization, and Auth for MCP followed on 6 May 2026. If you're wiring agents into this tenant, their claims and checks will sit in Actions too, so leave room for them. A coding assistant will turn rule JavaScript into Actions syntax fast. We still judge each translation by comparing real token claims against the old ones.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
An inventory of every rule and hook, so you know which ones still do real work before anything gets rewritten
yours to keep - code02
Actions code and Deploy CLI config kept in source control, so the next change gets reviewed
yours to keep - code03
Management API calls moved to a machine-to-machine client, with its credentials stored as Action secrets so they never sit in code
yours to keep - runbook04
Token claims compared before and after for each application. Any difference gets explained or fixed before cut-over.
yours to keep - runbook05
Cut-over and rollback runbook
yours to keep
Platforms and services on this move
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01Rules
- The JavaScript snippets Auth0 used to run at login. Someone would write one to add a role to the token or block a sign-in, and each one ran after the last.in context →
- 02Hooks
- Older Auth0 scripts for moments outside login. Someone might have used one to stamp machine-to-machine tokens or check sign-ups, and then forgotten about it.in context →
- 03Actions
- The replacement for both. Each one is a small JavaScript function you attach to a trigger such as post-login. It carries its own secrets, and other Actions can't read them.in context →
- 04Extension
- Your own code sitting on top of the standard product, which stays untouched underneath. Business Central extensions are written in AL, Finance and Operations ones in X++.in context →
- 05tenant
- Your company's Microsoft account. Every environment draws on one shared pool of storage, so a bloated test copy hits everyone.in context →
- 06API token
- A long-lived Zendesk secret that, sent with an admin's email address, lets a program call Zendesk's APIs. Zendesk is retiring them.in context →
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01When do Auth0 Rules and Hooks stop working?
Hooks stop running after 30 April 2027 and Rules after 31 January 2028, and Auth0 removes them at that point. Any claim, block or redirect still sitting in them goes too. Hooks go first, so get those done early in 2027.
02Can we still edit our Auth0 Rules?
Not the code. Rules and Hooks have been read-only since 18 November 2024. Active ones keep running, and you can still switch them on or off or change their configuration values and secrets. The Dashboard, the Management API and the Auth0 CLI won't take code edits, though. A bug in a rule's code stays there until you disable the rule or migrate it.
03Can Rules and Actions run side by side?
Yes, during the migration. We move one rule at a time, disabling it and binding its Action in the same deploy, which keeps any window where both or neither run as short as we can make it.
04How long does the rewrite take?
It depends on how many rules and hooks you have, how many call the Management API or external services, and how many redirect. Simple claim rules convert quickly; redirect and enrichment flows take longer to test.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyCentrify alternatives, and how we untangle Server Suite zones
Untangling Centrify and Delinea Server Suite zones, UID maps and dzdo roles, and moving Linux and Windows servers to a server identity model you can run.
read the case studyee0c23e0 - 01Book a 30-minute working sessionsenior engineer
- 02Talk to an engineer about your setupreply within 24 hours
- 03See how similar projects wentcase studies
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it