RefLink embedded page

This example covers the RefLink plugin. For the general integration process, see Embedded page.

How the page opens

1. A user opens RefLink in a project. The cabinet loads the frontend as an embedded page and supplies launch context through Senler Bridge.
2. The frontend receives launch_code and project_id in useEmbeddedRefLinkApp.ts. The interface uses project_id to check consistency, but the value alone grants no access.
3. The frontend sends the one-time launch_code to POST /api/embedded/session.
4. The backend verifies the code's signature, lifetime, and single use in backend/src/core/session, extracts the project, and issues its own RefLink session_token.
5. Every later page request uses this session_token. EmbeddedSessionGuard extracts the project from the verified session again, so controllers do not need a project_id from a form or URL.
6. If the project has not completed OAuth, the frontend displays AuthorizationStep. After consent, the backend receives project-scoped Senler OAuth tokens and stores them for this project.
7. To load channels, agents, segments, and automations, the backend obtains an OAuth access token and calls the Senler API through SenlerApiClient.

Result: the browser knows only the RefLink session, while Senler API access and the Client Secret remain on the backend.

One Frontend Serves Multiple Contexts

A shared entry point avoids duplicating authorization, data loading, styles, and components. The difference between the main page and step form comes from the verified context.launch.type supplied by Senler Bridge, not a separate URL.

If the application adds an agent tool configurator, this design can grow by adding an explicit tool_configurator branch without mixing configuration persistence with normal page behavior.

The page session, management session, and OAuth token serve different purposes. Do not substitute one for another: see the RefLink authorization model.