Engenheiros podem gerar documentação de API diretamente do código do endpoint
Why this prompt matters
Engineering teams often ship endpoints faster than they document them, which leaves frontend developers, partners, QA, and new teammates relying on source code to understand basic usage. A strong prompt closes that gap by turning controllers, routes, schemas, and middleware into a consistent documentation draft. That speeds up integration, reduces support questions, and makes undocumented edge cases like auth rules or validation failures visible before they cause avoidable bugs.
What we use it for
Turning endpoint implementations into reusable API documentation with parameters, authentication requirements, validation rules, error cases, and copy-pasteable curl examples.
Prompt
Act as a senior API technical writer and backend engineer. I will paste endpoint code, controller logic, route definitions, request and response schemas, validators, auth middleware, error handling, comments, and sometimes tests. Your job is to convert that implementation detail into clean, developer-facing API documentation that another engineer could use without reading the source code. Return your answer in exactly these sections: 1. Endpoint Summary 2. HTTP Method and Path 3. What This Endpoint Does 4. Authentication Requirements 5. Request Headers 6. Path Parameters 7. Query Parameters 8. Request Body Schema 9. Validation Rules and Constraints 10. Success Response 11. Error Responses 12. Example cURL Request 13. Example Success Response JSON 14. Implementation Notes and Assumptions Rules: - Base the documentation only on the code and context provided. Do not invent fields, permissions, business rules, or status codes that are not supported by the source. - If something is implied but not fully certain, place it under Implementation Notes and Assumptions. - Normalize naming so the final documentation is easy to read, but preserve exact parameter names, enum values, header names, and route paths. - If auth middleware is present, explain the auth mechanism plainly, including required header format when visible in the code. - If validation logic exists, convert it into practical parameter constraints such as required, optional, type, format, min or max, allowed values, and defaults. - If the code shows multiple failure paths, list each distinct error with status code, trigger, and response shape when available. - If the endpoint interacts with pagination, filtering, sorting, idempotency, rate limits, or tenant scoping, include those details when explicitly present. - Write for engineers who need usable docs fast, not a marketing description. - Keep the output concise but implementation-ready. Source code and related context: [PASTE CODE HERE]
Result
A documentação de API costuma ficar atrás do código que realmente vai para produção. A equipe de backend adiciona uma nova rota, atualiza validações, muda uma exigência de autenticação ou cria um novo caminho de erro, mas a documentação continua incompleta ou desatualizada. Isso cria um problema comum nas equipes de engenharia: as pessoas precisam ler controllers, schemas e middleware apenas para responder perguntas básicas de integração.
Este prompt foi criado para transformar esses detalhes de implementação em documentação útil rapidamente. Em vez de pedir um resumo vago, ele força uma estrutura específica: resumo do endpoint, método e caminho, autenticação, headers, parâmetros, schema de requisição, regras de validação, resposta de sucesso, respostas de erro e um exemplo de cURL. Essa estrutura importa porque corresponde exatamente às perguntas que desenvolvedores frontend, QA, parceiros técnicos e redatores técnicos normalmente precisam responder.
O prompt também reduz o risco de alucinação ao dizer ao modelo para se basear apenas no código fornecido e mover pontos incertos para uma seção de suposições. Isso é especialmente importante em trabalho com API, onde inventar um campo ou código de status torna a saída pior do que inútil. Ao separar detalhes confirmados de observações inferidas, o resultado fica mais prático e mais seguro de reutilizar.
Outro motivo pelo qual esse prompt funciona é que ele traduz padrões de código de baixo nível para uma linguagem voltada ao desenvolvedor. O middleware vira uma explicação clara dos requisitos de autenticação. A lógica de validação vira restrições legíveis para parâmetros. Os fluxos de erro viram falhas documentadas com códigos de status e gatilhos prováveis. Testes e definições de rota passam a servir como evidência de apoio para exemplos e comportamento.
Quando bem usado, esse prompt pode ajudar equipes a criar documentação interna mais rápido, melhorar o handoff entre backend e frontend e gerar um rascunho inicial mais limpo para referências externas de API sem começar de uma página em branco.