API-Dokumentationsgenerator aus Endpunkt-Code
Why this prompt matters
API documentation debt compounds fast — endpoints shipped undocumented stay undocumented for months or years because no one wants to reverse-engineer them later. The typical cost: integration errors, support tickets, and delays every time a new developer touches that endpoint. This prompt eliminates the friction by making documentation the fastest part of shipping an endpoint, not an afterthought. The structured Role + Output Format approach is critical because without it, models produce prose summaries instead of the schema tables and curl examples that developers actually need for integration.
What we use it for
You have just finished writing a new API endpoint and need to hand it off to a frontend developer, a third-party integrator, or your own team. The endpoint has validation logic scattered across middleware and the controller, and writing the documentation by hand would take 30-45 minutes. This prompt lets you paste the code and get publish-ready documentation in under 30 seconds.
Prompt
Act as a senior API technical writer with deep expertise in REST API design and OpenAPI 3.0 documentation standards. Context: I have an API endpoint written in [FRAMEWORK] / [LANGUAGE] that needs complete, developer-ready documentation. The endpoint is part of [YOUR PROJECT NAME / DOMAIN]. Task: Analyze the following endpoint code and produce complete API documentation covering every detail a developer needs to integrate this endpoint correctly. ``` [PASTE YOUR FULL ENDPOINT HANDLER CODE HERE — include route definition, middleware, validation logic, controller/handler function, and error handling] ``` Constraints: - Do not omit any parameters you can infer from the code — if validation logic implies a constraint (e.g., minLength, required, enum values), include it - Do not guess at business logic that is not in the code — if something is unclear, mark it as [TO CLARIFY] - Keep all parameter names and field names exactly as they appear in the code - Use technical documentation vocabulary, not conversational descriptions Output Format — produce exactly these sections: ## Endpoint Overview - Method and path - Authentication requirement (inferred from middleware) - Rate limiting notes (if any) - Short description (1-2 sentences) ## Request Specification ### Path Parameters (table: name | type | required | description | constraints) ### Query Parameters (table: name | type | required | default | description | constraints) ### Request Body (table: field | type | required | description | validation rules) ## Response Specification ### Success Response (2xx) (schema with field names, types, example values) ### Error Responses (table: status code | error code | meaning | when it occurs | how to fix) ## Example Request ```bash curl [working example with realistic sample values matching all validation rules] ``` ## Example Response ```json [realistic JSON response matching the success schema] ```
Was dieser Prompt bewirkt
Das Schreiben von API-Dokumentation gehört zu den zeitaufwändigsten Aufgaben in der Softwareentwicklung – und zu den am häufigsten ausgelassenen. Dieser Prompt verwandelt rohen Endpunkt-Code in vollständige, entwicklerfertige Dokumentation: Endpunktbeschreibung, HTTP-Methode, Pfadparameter, Query-Parameter, Request-Body-Schema, Response-Schema, Statuscodes, Fehlerbehandlung und curl-Beispiele – alles in einem Durchgang.
Der Prompt
Der vollständige Prompt steht oben. Hier erfahren Sie, was jeder Abschnitt bewirkt und warum er wichtig ist:
Warum die Rollenanweisung funktioniert
Der KI zu sagen, sie solle als Senior-API-Technikautor mit REST- und OpenAPI-3.0-Expertise agieren, ist nicht nur Beiwerk – es aktiviert einen spezifischen Ausgabemodus. Das Modell erzeugt strukturierte Dokumentation mit korrekter Fachsprache statt allgemeiner Absätze darüber, was der Code tut.
Warum Sie den vollständigen Codeblock einfügen müssen
Unvollständiger Code oder nur die Funktionssignatur liefert unvollständige Dokumentation. Der Prompt weist Sie an, den gesamten Endpunkt-Handler einzufügen — einschließlich Middleware, Validierungslogik und Fehlerbehandlung — denn dort lebt die eigentliche Dokumentation. Das Modell liest die Validierungsregeln und wandelt sie direkt in Parameterbeschränkungen um, wie required: true, minLength: 3, type: string.
Der Abschnitt zum Ausgabeformat
Ohne explizite Anweisungen zum Ausgabeformat verfassen Modelle prosaische Dokumentation. Dieser Prompt gibt eine strukturierte Aufschlüsselung vor: Endpunkt-Übersicht, Request-Spezifikation, Response-Spezifikation, Fehlercode-Tabelle und ein curl-Beispiel. Dieses Format kann direkt in eine README, ein Notion-Dokument oder eine Swagger-Datei übernommen werden, ohne dass eine Neuformatierung nötig ist.
Wie die Beispielausgabe aussieht
Für einen POST /api/users/register-Endpunkt erhalten Sie Folgendes:
- Endpunkt-Übersicht: Methode, Pfad, Authentifizierungsanforderung, Hinweis zur Ratenbegrenzung
- Request Body: JSON-Schema mit Feldnamen, Typen, Einschränkungen und Angabe, ob erforderlich
- Response: 201-Erfolgsschema, plus Fehlerformen für 400/409/422/500
- Fehlertabelle: Statuscode, Fehlercode-String, Bedeutung und Hinweis zur Behebung
- curl-Beispiel: Ein funktionierender Befehl mit realistischen Beispielwerten
Am besten geeignet mit
Dieser Prompt funktioniert am besten mit Claude 3.7 Sonnet oder GPT-4o. Beide bewältigen Code-zu-Dokumentation-Aufgaben zuverlässig. Für Endpunkte mit komplexer Validierungslogik (Joi, Zod, Pydantic) ist Claude tendenziell genauer beim Extrahieren von Einschränkungsregeln.
Anpassung an Ihren Stack
Die Felder [FRAMEWORK] und [LANGUAGE] sind entscheidend. "Express.js / Node.js" erzeugt JavaScript-native curl-Beispiele. "FastAPI / Python" liefert Python-typische Typannotationen und erkennt Pydantic-Modelle. Füllen Sie diese Felder stets aus – sie beeinflussen die Ausgabequalität erheblich.