Backend

The Backend tab defines the server-facing API surface of the planned application — the endpoints, their contracts, and the acceptance criteria that describe them. Planning the server boundary beside the interface it serves is part of designing the application as a whole: the pages that call an endpoint, the entities it reads, and the roles allowed to reach it all live in the same plan.

Build endpoints manually

Add an endpoint, choose its HTTP method, set its path, and describe its purpose. Paths use App Router's bracket syntax for dynamic segments — /api/resources/[id] — and are normalized as you type, so a stray trailing slash never makes two spellings of the same route.

Endpoints are organized into a navigable tree grouped by path, so related routes stay together: /api/orders and /api/orders/[id] fold under one branch. Branches collapse and expand, a search box filters the whole surface by method, path, or description, and deleting a folder removes every endpoint at or below it in one action.

Endpoint contracts

Each endpoint carries a contract you can expand in place:

• Params — what goes in. Path params are owned by the path itself (renaming [id] in the path is the rename), so the params list describes bodies and query inputs.
• Responses — what comes back, listed by status code with a type and a description, so the difference between a 200, a 403, and a 404 is written down before anyone implements it.
• Test cases — acceptance criteria attached to the endpoint, written by hand or generated, following the same approach as the test cases tool: tests planned before the code exists are requirements, not afterthoughts.

Reusable types defined on the Data tab are available when describing request and response shapes, so an endpoint that returns an Order says so in the data model's own vocabulary.

Generate from Data

When entities exist on the Data tab, Generate CRUD creates the standard surface every table needs before anyone has designed anything: list, create, read, update, and delete for each entity, at plural, hyphenated resource paths (OrderItem becomes /api/order-items and /api/order-items/[id]), each seeded with the response statuses that shape of route answers with.

Generation is add-only in both directions. Existing method-and-path combinations are kept instead of duplicated, so re-running it after adding an entity fills in only what is missing. And it is a generator, not a binding: generated rows drop into the ordinary endpoint list, where they can be renamed, re-described, or deleted like any other — an endpoint you edited is never silently rewritten because the entity behind it changed. The ER diagram proposes the surface; you own it from there.

AI endpoint suggestions

Suggest endpoints asks the AI for the actions the application needs beyond table CRUD — the "publish", "invite", "checkout" routes no data model implies on its own. The Domain tab's product description grounds the suggestions, so a well-written domain produces routes that sound like your product rather than a generic API. Suggestions are additive, and the button's chat half opens the assistant sidebar with a drafted prompt instead, when you would rather discuss the API surface than generate it.

Where endpoints go next

Backend endpoints flow through the rest of the plan: the Security tab includes them in the role-access matrix, Traceability maps features to the endpoints that satisfy them, and the Export tab writes each one as a route-handler skeleton and lists the surface in the project report. The API endpoints reference page summarizes how endpoints sit alongside the canvas nodes downstream.

Two targets extend the Backend section with a second panel of their own: Terminal projects plan CLI flags — a flag table is to a command-line tool what the route tree is to a site — and Extension projects plan surfaces, permissions, and content-script match patterns alongside their routes.