Scan any codebase and generate a complete, executable Bruno API collection using AI. Works with ChatGPT, Claude, Gemini, or any local model. Copy the full prompt below, paste it into any AI model along with your source files, and get organized .bru files back.
What it does: Finds every HTTP call in your project (fetch, axios, GraphQL), extracts methods, URLs, headers, bodies, and generates a fully organized Bruno collection with environments, authentication, and documentation. Ready to drop into your repo and start testing.
How to use: Scroll down, copy everything inside the code block, paste it into the AI along with your source code.
Scan this entire project and find every HTTP API call.
Look for:
- fetch() calls
- axios requests
- any HTTP client usage (ky, got, superagent, etc.)
- GraphQL queries and mutations
For each API call found, extract:
- HTTP method (GET, POST, PUT, DELETE, PATCH)
- URL or endpoint path
- Headers (especially Authorization, Content-Type)
- Request body/payload structure (if applicable)
- Query parameters
- Which file and function the call lives in
Before generating, check the Bruno documentation or any existing
.bru files in the project to verify the current file format,
block syntax, and known limitations.
If a Bruno collection already exists in the project, audit and
update it in place rather than generating from scratch. Flag any
endpoints missing from the collection.
Then generate a Bruno collection following these rules:
Collection structure:
- Group endpoints by domain/feature (auth, users, products, orders, etc.)
- Place the auth folder first, remaining folders in alphabetical order
- Within each folder, order requests by HTTP method
(GET, POST, PUT, PATCH, DELETE), then alphabetically
Requests:
- Use params:path for all path parameters (e.g. :userID) instead
of hardcoding values in the URL
- Path parameters that reference captured identifiers (like userId)
should use the corresponding environment variable (e.g. {{userId}})
instead of hardcoded values
- Do not duplicate query parameters in both the URL and the
params:query block. Use only params:query
- Add explicit Content-Type headers to all requests that send
a body, matching the actual content type used in the source code,
unless already set at the collection level
- Do not include standalone empty blocks. The auth: none property
inside the method block is acceptable
- Use Title Case for request names in the meta block
(e.g. "Create Plan", not "create-plan")
Environments:
- Include a baseUrl variable with the full API prefix
(e.g. http://localhost:3000/api/v1), so individual requests
only need the resource path (e.g. {{baseUrl}}/users)
- Generate environment files for environments configured or
referenced anywhere in the project (e.g. .env files, config
files, deployment scripts, existing API collections,
infrastructure configs). Do not invent URLs; use only URLs
found in the project
- Sensitive variables like tokens and credentials should use
vars:secret blocks so they are never committed to version control
Authentication:
- For auth endpoints (login, token refresh), add post-response
scripts that capture all returned identifiers (token, userId,
sessionId, etc.) using bru.setEnvVar() so they persist across
sessions
- All authenticated requests should use the auth:bearer block
with the same variable name returned by the login endpoint
- For endpoints where authentication is optional, use the same
auth:bearer block and note in the docs that the token can
be omitted
Documentation:
- Write docs as plain text (Bruno does not render markdown).
For complex endpoints (multiple params, request body, or
multiple error codes), include a brief description, list the
possible error status codes, and show a sample JSON response.
For simple endpoints (no body, no query params), one line
is enough
- Include the source file and function name in the docs block
Output the collection as a directory structure with .bru files I can
drop directly into my project.
- Run it periodically to catch new endpoints that were added
- Diff the output against your existing collection to spot undocumented APIs
- Run it on existing collections for even better results: the AI preserves your naming conventions and patterns, filling in the gaps
- Treat the prompt as a living document: run it, review the output, add a rule to fix what's wrong, and run it again
- Bruno - Open-source API client
- Bruno Documentation