Ingenieure können API-Dokumentation direkt aus Endpoint-Code erzeugen
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
API-Dokumentation hinkt dem tatsächlich ausgelieferten Code oft hinterher. Ein Backend-Team ergänzt eine neue Route, aktualisiert Validierung, ändert Authentifizierungsanforderungen oder fügt einen neuen Fehlerpfad hinzu, aber die Dokumentation bleibt lückenhaft oder veraltet. Dadurch entsteht in Engineering-Teams ein bekanntes Problem: Für einfache Integrationsfragen müssen erst Controller, Schemas und Middleware gelesen werden.
Dieser Prompt wurde dafür entwickelt, solche Implementierungsdetails schnell in nutzbare Dokumentation zu verwandeln. Statt einer vagen Zusammenfassung erzwingt er eine konkrete Struktur: Endpoint-Zusammenfassung, Methode und Pfad, Authentifizierung, Header, Parameter, Request-Schema, Validierungsregeln, Erfolgsantwort, Fehlerantworten und ein cURL-Beispiel. Diese Struktur ist wichtig, weil sie genau den Fragen entspricht, die Frontend-Entwickler, QA, Partneringenieure und technische Redakteure normalerweise beantwortet haben wollen.
Der Prompt senkt außerdem das Halluzinationsrisiko, weil das Modell nur auf Basis des bereitgestellten Codes arbeiten und unsichere Punkte in einen Abschnitt für Annahmen verschieben soll. Gerade bei APIs ist das entscheidend, denn ein erfundenes Feld oder ein falscher Statuscode macht die Ausgabe schlimmer als nutzlos. Durch die Trennung bestätigter Details von abgeleiteten Hinweisen bleibt das Ergebnis praktisch und sicherer wiederverwendbar.
Ein weiterer Grund, warum dieser Prompt gut funktioniert, ist die Übersetzung von Low-Level-Code in entwicklergerechte Sprache. Middleware wird zu einer klaren Erklärung der Authentifizierungsanforderungen. Validierungslogik wird zu lesbaren Parameterbeschränkungen. Fehlerzweige werden zu dokumentierten Fehlerfällen mit Statuscodes und wahrscheinlichen Auslösern. Tests und Routendefinitionen dienen als zusätzliche Belege für Beispiele und Verhalten.
Richtig eingesetzt hilft dieser Prompt Teams dabei, interne Dokumentation schneller zu erstellen, die Übergabe zwischen Backend und Frontend zu verbessern und einen saubereren ersten Entwurf für externe API-Referenzen zu erzeugen, ohne bei null anfangen zu müssen.