# List Every API Endpoint in an ASP.NET Core App An agent traces ASP.NET Core route registration, authentication and request models, then checks local responses and writes an endpoint inventory. [Run this on Rush](https://cloud.getrush.ai/run/api-endpoint-inventory/aspnet-core/), in a Project that has your repository. ## What the agent does The agent reads your app's SDK requirement, startup code and endpoint registration before enumerating routes. In an app like jasontaylordev/CleanArchitecture, `global.json:3` selects SDK `10.0.402` and `src/Web/Program.cs:45` calls `app.MapEndpoints(typeof(Program).Assembly)`. The route discovery implementation matters: `src/Web/Infrastructure/WebApplicationExtensions.cs:14-24` finds exported `IEndpointGroup` implementations and derives a default `/api/{ClassName}` prefix. Searching only for controller attributes would miss this app's registration mechanism. It follows each group's `Map` method and the custom verb helpers in `EndpointRouteBuilderExtensions.cs`. `src/Web/Endpoints/TodoItems.cs:13-18` combines `RequireAuthorization()` with POST, PUT, PATCH and DELETE registrations; the patch pattern is `UpdateDetail/{id}`. `src/Web/Endpoints/Users.cs:12` delegates to `MapIdentityApi()`, so framework-generated identity endpoints belong in the inventory too. The agent checks runtime metadata and OpenAPI against these source registrations instead of assuming each visible `MapPost` represents the entire API. For parameters and authorization, it reads handler signatures, command types and any application-layer requirements. `TodoItems.cs:32-35` compares the route id with the command's id, a constraint a path-only table would lose. `TodoLists.cs:13` requires authorization at the group level, while the handler dispatches through `ISender`. The inventory separates endpoint authentication, application policies and resource-level conditions. It cites file lines for a role requirement only when the code actually defines one; a logged-in requirement does not imply an administrator role. The agent prepares an isolated development instance using the repository's setup instructions, checking the generated app configuration before following `dotnet run --project src/AppHost`. It enumerates the running endpoint metadata and sends credential-free probes only to that local instance with disposable data. Each result records method, URL, supplied parameters, status, content type and redirect behavior. `Program.cs:48` maps a frontend fallback, so an HTML success page must not count as a successful protected API response. Setup failures or unsafe-to-exercise routes remain explicitly unverified. ## Start it with one API call `POST https://api.prix.dev/o/{org}/sessions` ```json { "agent": "claude", "input": "Inspect the attached ASP.NET Core repository and write endpoints.md with every HTTP method and path, route registration and handler file:line, path/query/body parameters, authentication, roles and application authorization. Follow discovered endpoint groups, custom mapping helpers and framework-generated identity routes, then compare with runtime metadata and OpenAPI. Start only a disposable local development instance with sandbox-owned data; probe each route without credentials where safe, recording status, content type and redirects. Flag successful protected operations separately from intentional public endpoints and frontend fallback HTML. Mark blocked probes honestly. Do not contact production, modify application source, push, or open a PR.", "resources": [ { "url": "https://github.com/your-org/your-app" } ] } ``` 1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token. 2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox. 3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory. ## What comes back `endpoints.md` contains a method-and-path table, handler references, request parameter details and separate expected and observed authentication columns. Generated identity operations are identified as framework registrations, with the resolved framework version recorded. The report also lists documentation routes, health or diagnostic endpoints discovered at runtime and any source registrations that could not be verified against a running server. A reviewer checks that prefixes and custom route patterns compose correctly, that authorization inherited from a group appears on its members and that public sign-in behavior is not reported as a leak. For a suspicious success, the report includes enough local request detail to repeat it without copying credentials. Rush returns the report through the session's artifacts; this inventory asks for no code patch and makes no claim that a security scan proves the whole app safe. ## Run it on every API release candidate Your release automation can start one inventory session for the candidate branch, using a GitHub `tree` URL in `resources` and an API key in the request header. Give each release its own `Idempotency-Key` and reuse it only when retrying the same body. Name the configuration being checked in the prompt so a development-only route does not appear to be a production promise. Read the finished session or use the key's completion webhook to collect `endpoints.md`. Compare the table with the preceding release for newly public operations, changed verbs and parameters whose required status changed. Keep a human decision between a report finding and any authorization change. ## Why run it on Rush? ASP.NET route discovery can span reflection, group conventions, framework helpers and application handlers. Rush gives the agent a sandbox in which it can inspect those layers and prepare a separate development instance without starting migrations against a developer's existing database. The request names the repository; the result records the exact revision being explained. Source references and real local HTTP responses make the inventory reviewable. The session messages retain command arguments and tool results, including failed setup attempts rather than a polished table that hides them. Separate runs can inspect separate services within your concurrency allowance, with each service's report and verification limits kept apart. ## Frequently asked questions ### Can this handle minimal APIs rather than MVC controllers? Yes, the task follows registration code and runtime endpoint metadata. CleanArchitecture is a concrete example where exported endpoint groups and custom verb helpers matter. Controller-only searches would give an incomplete answer. ### Does an anonymous success always mean an auth bug? No, registration, sign-in, documentation and public reads can intentionally accept anonymous requests. The agent compares the observed response with the requirement found in source. It also checks content type so a frontend fallback is not mistaken for an API result. ### Will it call destructive endpoints? Only a disposable local instance with sandbox-owned fixtures is eligible for mutation probes. Production URLs and external side effects are excluded. If the local setup cannot safely exercise an operation, the report preserves the route and labels its live check unverified. ### What if the SDK or database cannot start? The source-derived route inventory can still be useful. The agent records the requested SDK, failing command and missing dependency, then separates static findings from runtime observations. It never invents a response for a server that did not start.