Actions Integrations for Partners

Partners like you use Actions Integrations to build zero-code solutions that tie their products into Auth0 workflows. Actions Integrations let Auth0 customers implement solutions like identity verification or consent management without writing any code. You write the Actions Integration; customers drag and drop it into their workflow.

Actions Integrations are self-contained functions that execute at chosen points in the Auth0 platform. Written in JavaScript, they are closed source; customers can’t modify the code. 

Creating an Actions Integration involves planning, building, and testing. Before you make it available to customers in the Auth0 Marketplace, Auth0 reviews the Actions Integration. For information about the Auth0 Marketplace, read Marketplace Partners.

Identify what use case your Actions Integration will address. What problem will it solve for customers? How will it solve the problem? For more information, read Defining an Integration Use Case. 

Action Integrations consist of a single Action. What an Action can do is determined by where it is executed within the Auth0 runtime environment, its Action flow. Available Action flows are:

• Login flow runs synchronously after a user successfully signs up or logs in. Login events include interactive flows (like username/password or federated login) and non-interactive flows (like session checks and refresh token exchanges). To learn more about this flow, read Login Flow.

• Machine to Machine flow runs synchronously when an application requests an access token using the client credentials grant. To learn more about this flow, read Machine to Machine Flow.

• Pre User Registration flow runs synchronously before Auth0 adds a user to a database or passwordless connection. This flow does not run for federated logins like enterprise or social connections. To learn more about this flow, read Pre User Registration Flow.

• Post User Registration flow runs asynchronously after Auth0 adds a user to a database or passwordless connection. This flow does not run for federated logins like enterprise or social connections. To learn more about this flow, read Post User Registration Flow.

• Post Change Password flow runs asynchronously after the customer changes a password for a database connection user. This flow does not run for password changes on other types of connections. To learn more about this flow, read Post Change Password Flow.

• Send Phone Message flow delivers a phone or SMS message as part of a custom MFA provider. To learn about custom MFA providers, read Customize Multi-factor Authentication SMS and Voice Messages. To learn more about this flow, read Send Phone Message Flow.

To learn more about Action flows, read Explore Flows and Triggers. If you need to redirect users to an endpoint during login, read Redirect Actions for Partners.

Once you’ve decided which flow fits your Action Integration's use case, build your Action in a testing tenant. For instructions, read Write Your First Action. This Action will be the basis for your Action Integration code.

In addition, to assist you in building your integration you can leverage our Action integration templates:

• Post Login Action Integration Template

• Machine-to-Machine Action Integration Template

• Pre User Registration Action Integration Template

• Post User Registration Action Integration Template

• Post Change Password Action Integration Template

• Send Phone Message Action Integration Template

To learn how to make your Actions Integration secure and stable, read Actions Coding Guidelines. Also follow these guidelines specific to Actions Integrations:

• When building your Action in a test tenant, use secrets for all values that a customer needs to provide (such as identifiers, tenant names, and thresholds). When you submit your Actions Integration, Auth0 asks which fields must be encrypted at rest (remain secrets) and which can be editable text fields.

• Use a debug/test mode configuration flag for logging that helps with setup or troubleshooting. Actions Integrations should rarely output logs for all executions.

• Write secret names in ALL_CAPS_SNAKE_CASE to ease review.

• Action Integrations are closed source; customers can neither see nor modify the code. Any customer-specific input required to control the Action Integration must come from secrets or configuration.

Because Auth0 reviewers don't have access to your service, you must test your Action before submitting it for review. Manually test both successful executions and edge cases. Include these checks:

• Does the Action fail silently or block further execution?

• How does the Action work if an HTTP request fails?

• What, if any, error messages are exposed to users?

• What information is logged?

• Can the Action be bypassed or spoofed?

During the submission process, Auth0 asks for unit test coverage for the success path. Auth0 provides all the tooling and examples needed to make this as simple as possible.

Once you have written and thoroughly tested your Actions Integration, submit it to Auth0 for review: submit an Auth0 Marketplace service request. After a successful initial review, the integration is reviewed for security compliance.

Once Auth0 completes the reviews of your Actions Integration, we will notify you if the integration has passed the reviews and publication timelines.