API endpoints

API endpoints are the server boundaries of the planned application. Unlike pages, components, and stores, they are not drawn on the Structure board — they are defined in the Backend tab, which holds the endpoint tree, HTTP methods, request and response contracts, and per-endpoint test cases, and can generate CRUD endpoints from the entities in Data.

Each endpoint still becomes a real file: a route-handler skeleton at app/api/<path>/route.ts in the export, written after the stores and components that precede it in the build order. Planning the server surface beside the interface is one of the calls the App Router architecture checklist says to make early.

Endpoints in the matrices

Endpoints take their place alongside the canvas nodes wherever the plan is reviewed as a whole. The Security matrix lists every endpoint as a row, because an endpoint is a surface a role either reaches or does not. Traceability does the same, because an endpoint is very often the thing a feature is actually implemented by.

Guards

Role restrictions on an endpoint generate a permission check that answers with a 403 rather than redirecting. That is the correct behaviour for an endpoint — a redirect is a response for a browser navigating, not for a client expecting data. Guarded pages redirect and guarded endpoints refuse; security concepts covers why the split matters.

Other targets

The idea only exists where a server does. Terminal projects have no route handlers — the CLI's flag table is their contract with the outside world instead — and an Extension's background service worker plays the "server-side" role a web app's API plays.