Vorlage Referenz

Diese Seite ist eine redaktionelle Vorlage, keine Produktreferenz. Neue Referenzseiten (REST-API, Widget-Vertrag, Betriebsgrenzen) kopieren die Struktur und ersetzen Platzhalter.

Für die öffentliche REST-API bleibt /openapi/public-v1.yaml die Quelle der Wahrheit. Die Markdown-Referenz darf die OpenAPI-Datei nicht widersprechen.

---
title: Name des Vertrags
description: Ein Satz zum Geltungsbereich, ohne interne Dateipfade als Titel.
---

| Feld | Wert |
| --- | --- |
| Version | `1` |
| Geprüft | `YYYY-MM-DD` |
| Status | Beta oder ausgeliefert |
| Quelle | Link auf OpenAPI oder kanonische Spezifikation |

Ein Absatz, was der Vertrag einschließt und explizit **nicht** einschließt.

## Authentifizierung

Schema, Header, Key-Präfix, wer Keys anlegt. Platzhalter `YOUR_API_KEY`.

## Berechtigungen

Tabelle der Scopes oder Rollen und der jeweils sichtbaren Daten.

## Endpunkte oder Felder

Pro Ressource: Methode, Pfad, Request, Response, optionale Felder.
Beispiel nur mit Platzhaltern.

## Fehler

Stabile Fehlerform, HTTP-Status, `code`, wann welcher Code entsteht.

## Limits

Rate-Limits, Seitengrößen, Caching-Header, Idempotenz. Nicht vorhandene
Mechanismen (zum Beispiel Cursor-Pagination) ausdrücklich nennen, wenn
Integrationen sie erwarten könnten.

## Änderungen

Link auf das Changelog. Breaking Changes stehen dort, bevor sie
ausgeliefert werden.

Checkliste vor dem Merge

Version, Prüfdatum und Status sind gesetzt
OpenAPI oder gleichwertige Spezifikation ist zuerst aktualisiert
Keine Secrets, keine internen IDs aus Logs
Docs-Build mit check-docs.mjs ist grün
Für REST: apps/e2e/tests/integrations.spec.ts; für das Portal: E2E docs-portal
Ablauf in Qualität und Prozess eingehalten