Skip to main content
The End of Life (EOL) date of Rules and Hooks will be November 18, 2026, and they are no longer available to new tenants created as of October 16, 2023. Existing tenants with active Hooks will retain Hooks product access through end of life.We highly recommend that you use Actions to extend Auth0. With Actions, you have access to rich type information, inline documentation, and public npm packages, and can connect external integrations that enhance your overall extensibility experience. To learn more about what Actions offer, read Understand How Auth0 Actions Work.To help with your migration, we offer guides that will help you migrate from Rules to Actions and migrate from Hooks to Actions. We also have a dedicated Move to Actions page that highlights feature comparisons, an Actions demo, and other resources to help you on your migration journey.To read more about the Rules and Hooks deprecation, read our blog post: Preparing for Rules and Hooks End of Life.
Because we plan to remove Rules and Hooks functions in 2026, you should create new Rules or Hooks only in your Development environment and only to test migration to Actions.To learn how to migrate your Rules to Actions, read Migrate from Rules to Actions. To learn how to migrate your Hooks to Actions, read Migrate from Hooks to Actions.
You can build your own rule(s) to support your specific functionality requirements. You can modify a pre-existing rule template or choose to start from scratch using one of our samples. Auth0 provides a number of pre-existing rules and rule templates to help you achieve your goal(s). To see a list, visit ourrules repository on GitHub.

​
How rules work

Rules are JavaScript functions that execute when a user authenticates to your application. They run once the authentication process is complete, and you can use them to customize and extend Auth0’s capabilities. For security reasons, your rules code executes isolated from the code of other Auth0 tenants in a sandbox. Rules also run during the token refresh flow. To learn more, read Refresh Tokens. In Auth0, the authentication transaction flow works as follows when you use rules:
Rules in the Authentication Flow diagram
  1. An app initiates an authentication request to Auth0.
  2. Auth0 routes the request to an identity provider through a configured connection.
  3. The user authenticates successfully.
  4. The ID token and/or access token is passed through the rules pipeline, then sent to the application.

​
Prerequisite

If you plan to use global variables in your rule, be sure to configure your rules variables first. To learn more, read Configure Global Variables for Rules.

​
Use the Dashboard

  1. Go to Dashboard > Auth Pipeline > Rules and click Create.
    Dashboard - Auth Pipeline - Rules
  2. Select a rule template.
    Dashboard - Auth Pipeline - Rules - Template
  3. Name the rule, modify the script to suit your needs, and click Save changes.
    Dashboard - Auth Pipeline - Rules - Edit Rule

​
Use the Management API

Make a POST call to the Create Rule endpoint. Be sure to replace MGMT_API_ACCESS_TOKEN, RULE_NAME, RULE_SCRIPT, RULE_ORDER, and RULE_ENABLED placeholder values with your , rule name, rule script, rule order number, and rule enabled value, respectively. 
curl --request POST \
  --url 'https://{yourDomain}/api/v2/rules' \
  --header 'authorization: Bearer MGMT_API_ACCESS_TOKEN' \
  --header 'cache-control: no-cache' \
  --header 'content-type: application/json' \
  --data '{ "name": "RULE_NAME", "script": "RULE_SCRIPT" }'
ValueDescription
MGMT_API_ACCESS_TOKENAccess Token for the Management API with the scope create:rules.
RULE_NAMEName of the rule you would like to create. The rule name can only contain alphanumeric characters, spaces, and hyphens; it may not start or end with spaces or hyphens.
RULE_SCRIPTScript that contains the code for the rule. Should match what you would enter if you were creating a new rule using the Dashboard.
RULE_ORDER (optional)Integer that represents the order in which the rule should be executed in relation to other rules. Rules with lower numbers are executed before rules with higher numbers. If no order number is provided, the rule will execute last.
RULE_ENABLED (optional)Boolean that represents whether the rules is enabled (true) or disabled (false).
We expose IPv6 addresses in our public endpoints (e.g., travel0.us.auth0.com). If a request arrives from a machine that supports IPv6, then the context.request.ip property will contain an IPv6 address. If you perform manual IP address manipulation, we suggest you use the ipaddr.js@1.9.0 library.

​
Manage rate limits

For rules that call Auth0 APIs, you should always handle rate limiting by checking the X-RateLimit-Remaining header and acting appropriately when the number returned nears 0. You should also add logic to handle cases in which you exceed the provided rate limits and receive the HTTP Status Code 429 (Too Many Requests); in this case, if a retry is needed, it is best to allow for a back-off to avoid going into an infinite retry loop. To learn more about rate limits, read Rate Limit Policy For Auth0 APIs.

​
Available modules

Rules run in a JavaScript sandbox configured for a specific Node.js version. The sandbox supports all versions of the JavaScript language (and associated syntax) for the configured Node.js version, and a large number of Node.js modules. For a list of supported sandbox modules, check out Can I require: Auth0 Extensibility.

​
Learn more