# Keep IBeam API Endpoints Thin

Keeps controllers to transport work by moving every decision into the service behind them.

Follow these project instructions.
# Keep IBeam API Endpoints Thin

Keeps controllers to transport work by moving every decision into the service behind them.

Version: `1.0.0`

An endpoint accepts a request DTO, calls one service method, and returns what the service gives back. That is the whole job. Anything else in the method body - a validation rule, a permission decision, a second service call to stitch two results together, a translation of one entity into another - belongs in the service.

The test is whether the same behaviour would survive being called from somewhere other than HTTP. A background job, a scheduled task, or an agent tool calling the same workflow must get the same rules applied, and they will only get them if the rules live behind the service boundary rather than in the controller.

Use the framework's base controller and response helpers where they exist, so that success and failure shapes stay consistent across the application rather than being hand-rolled per endpoint.

When an endpoint needs two service calls to answer, that is usually a sign the workflow itself is missing. Add a coordinating service method that owns the sequence, and let the endpoint call that one method instead.

#### Constraints
- Do not orchestrate more than one service call in an endpoint - move the sequence into a service.
- Do not put business rules, permission decisions, or audit decisions in a controller.
- Never reach for a repository or a provider type from a controller.

#### Verification
- No repository or provider type appears in the controller
- The endpoint body reads as: bind request, call one service method, return the result
- The same workflow can be called from a job or tool without losing any rule