Authoritative response schema for Management API Test an Action

Get Help
1

Please provide the authoritative response contract and interpretation rules for the inner payload returned by Test an Action. We need evidence-backed fields proving terminal completion of the appointed Action, distinguishing expected api.access.deny from throws/timeouts/engine failures, covering the complete emitted access-token claim/effect set, and attributing console denial records to the tested deployed Action/version rather than echoed input. HTTP 200 or an empty payload cannot establish these properties. If the API cannot provide complete proof, please identify the officially supported mechanism that can.

3

Hi @pariswolf911

Welcome to the Auth0 Community!

I understand that you are interested in authoritative response contract and interpretation rules for the inner payload returned by Test an Action.

The Management API’s “Test an Action” endpoint cannot provide a rigidly versioned, evidence-backed response schema to programmatically prove terminal completion or token state. The officially supported mechanism to achieve this is Unit Testing using the @auth0/actions NPM package.

Recommended Action

Instead of using the “Test an Action” endpoint for programmatic CI/CD assertions, we can recommend using the @auth0/actions TypeScript definitions to mock the event and api objects in Jest (or your preferred framework). This provides a verifiable, mock-driven contract of your Action’s exact terminal behavior.

How Unit Testing Fulfills Your Requirements

The “Test an Action” endpoint is primarily designed to power the Auth0 Dashboard’s browser simulator. It relies on generic console outputs that cannot reliably distinguish an explicit api.access.deny from an unhandled throw or engine timeout. Moving to local/CI unit testing solves this:

  • Distinguishing Denials: By mocking the api object (e.g., access: { deny: jest.fn() }), you can explicitly assert that the deny() method was intentionally invoked by your code, safely isolating it from unhandled exceptions or runtime timeouts.

  • Verifying Token Claims: Instead of relying on an empty HTTP 200 payload, mock specific API interfaces like api.accessToken.setCustomClaim. You can then use spy assertions to inspect and verify the exact, complete set of claims and flow effects your handler emitted.

  • Proving Attribution: Because unit tests execute directly against your version-controlled handler code, they guarantee that the test results and denial records are strictly attributed to the specific code version being tested, eliminating the ambiguity of unversioned console payloads.

We hope this helped you achieve a more robust and complete testing of your Actions, please reach out to us for any other issues or requests and we will gladly look into it.

Have a great one!
Gerald