Backend Authorization

Prepare the Handler

Authorization is required for application actions. First, describe the allowed operations in OpenAPI.

How The Application Backend Is Authorized

An MCP key or OAuth token authorizes the AI client only with Senler. Senler checks the project, current permissions, active installation, and exact action published in OpenAPI. The original MCP secret, OAuth token, and authorization header are never forwarded to the plugin backend.

Instead, every action call creates a short session between Senler and the application:

1. Senler signs a one-time launch_code containing the project ID, expiry, and nonce with the application's Client Secret;
2. it sends the code to /api/embedded/management-session on the same origin that hosts OpenAPI;
3. the backend verifies the signature, expiry, and nonce replay, then returns its own short-lived management_token;
4. Senler calls the marked endpoint with Authorization: Bearer <management_token>.

The session request looks like this:

POST /api/embedded/management-session
Content-Type: application/json

{"launch_code":"<one-time Senler code>"}

The application backend must verify launch_code using Client Secret and return its own short-lived token:

{"management_token":"app-session-token"}

Creating a management session must complete within 5 seconds, and the token response is limited to 64 KiB. An action has a 15-second timeout; its response is limited to 5 MiB, or 2 MiB for a funnel report. Redirects are not followed. Determine the project and permissions only from the verified management session, not from parameters supplied by AI.

The management_token is valid only in the application's own backend. If that backend then calls the Senler API, it needs its own API key or application OAuth access token with the required permissions. Neither the management_token nor the original MCP token is a Senler API credential for the plugin.