Änderungsprotokoll

Was sich an dieser Spezifikation geändert hat, mit Datum und Grund.

Hinweis

Bisher war keine dieser Änderungen brechend. Jede hat entweder ein Feld ergänzt, eine Regel geschärft, die vorher zweideutig war, oder einen Satz korrigiert, der etwas Falsches sagte. Kein Feld wurde entfernt oder umbenannt, kein Typ geändert, kein optionales Feld verpflichtend.

Was als brechend gilt und was nicht, steht auf Testsystem & Go-live. Brechende Änderungen werden hier zuerst angekündigt und treten nie in kürzerer Frist in Kraft als dort zugesichert.

DatumWasWarumBrechend
2026-10-23Der bestätigte Anamnesebogen trägt discussInPractice[]: die Fragen, die der Halter mit „Bespreche ich lieber in der Praxis“ markiert hat, statt sie zu beantworten.⚠️ Rein additiv (§13): ein neues, immer vorhandenes Feld — leer bei jedem älteren Bogen —, und entries[].status behält seine drei Werte. ⛔ Eine Markierung ist keine Antwort und hat keinen value; wer sie als Nein importiert, macht aus „fragen Sie mich persönlich“ das Gegenteil. Eine markierte Frage zählt weder als answered noch als unanswered.Nein
2026-09-07Jeder Request-Body in openapi.yaml deklariert jetzt additionalProperties: false — elf von dreizehn taten das bisher nicht.⛔ Kein Verhalten ändert sich. Die Routen haben ein unbekanntes Feld immer schon mit 400 unknown_field abgelehnt, und SPEC §10.5 sagt das seit jeher — nur das maschinenlesbare Dokument sagte es nicht. Ein aus dem Vertrag generierter Client konnte also ein Feld senden, das der Vertrag erlaubte, und genau den 400 bekommen, den derselbe Vertrag ausschloss. ⚠️ Antworten bleiben offen — §13 erlaubt Petla, ein Feld ohne Versionssprung hinzuzufügen — und die beiden webhooks:-Bodies ebenso: die ruft Petla bei Ihnen auf, ein striktes Schema dort hieße, ein künftiges Feld von uns abzulehnen.Nein
2026-09-07Impfungen melden — GET /vaccine-products und POST /appointments/{appointmentId}/vaccinations, hinter der Fähigkeit vaccinations.push.⛔ SPEC §12.2 verlangte seit jeher das Impfprodukt und verbot den Namen — und es gab keinen Weg, eine Petla-Produkt-Id zu erfahren. Der Katalog ist die fehlende Vorbedingung, nicht ein Zusatz. ⚠️ Rein additiv: neue Pfade und ein neuer Wert in der offenen Fähigkeitsliste (§13), also ändert sich für wen nichts, der ihn nicht deklariert. ⛔ Diese Version nimmt entgegen, prüft und speichert — sie berechnet keine Erinnerung neu; das steht auf der Seite, weil „angenommen“ und „Erinnerung bewegt“ zwei Aussagen sind.Nein
2026-09-07Webhooks lassen sich jetzt einschalten — PUT / GET / DELETE /connections/webhook und POST /connections/webhook/secret/rotate, dazu zwei neue Fehlercodes.⛔ SPEC §8.2 beschrieb vollständig, was Petla sendet — Signatur, Wiederholungsleiter, 410 Gone — und nannte keinen Endpunkt, an dem man eine URL hinterlegt. Man konnte also einen geprüften Empfänger bauen und hatte nichts, worauf man ihn richtet: ein Transportweg ohne Schalter. ⚠️ Rein additiv: neue Pfade, und der Zugang hängt am Feld transport, das seit v1 in der Deklaration steht. Wer weiter /events abruft, ändert nichts.Nein
2026-09-07bookingGridMinutes in der Fähigkeitsdeklaration, und die Ablehnung SLOT_OFF_GRID.Optional und rein additiv — weglassen ändert nichts. Es beantwortet die eine Frage, die windows nicht ausdrücken kann: welche Startzeiten Ihr System speichern kann, nicht wann die Praxis offen ist.Nein
2026-09-06Der bestätigte Anamnesebogen liegt dem Termin bei — Appointment.forms[] und GET /forms/{submissionId}/pdf, hinter der Fähigkeit forms.receive.forms stand am 04.09.2026 im Beispiel von SPEC §7.1 und wurde entfernt, weil es von nichts gesendet wurde — eine externe Prüfung baute einen Client aus diesen Seiten und fand es in keinem Rumpf. Jetzt kehrt es in der umgekehrten Reihenfolge zurück: erst der Sender, dann der Vertrag. ⚠️ Ein ergänztes Feld, keine neue Version: Antworten sind offen (§10.5), und wer forms.receive nicht deklariert, bekommt den Schlüssel gar nicht erst. ⛔ Ein fehlender Schlüssel und [] bedeuten das Gegenteil voneinander.Nein
2026-09-06Dokumente freigeben ist beschrieben und normativ — POST /appointments/{appointmentId}/documents und der zugehörige /revoke, hinter der Fähigkeit documents.push.SPEC §12 nannte Dokumente bis dahin weder implementiert noch aufrufbar, während beide Endpunkte geschrieben und zusammengeführt waren. ⚠️ Nichts an einer bestehenden Integration ändert sich: eine neue Fähigkeit in einer offenen Liste ist nach §13 keine neue Version, und wer sie nicht deklariert, merkt nichts davon.Nein
2026-09-06POST /connections/pairing-codes liefert zusätzlich onboardingUrl.SPEC §4.1 Schritt 3 nennt seit jeher den Zweig Praxis ohne Petla-Konto — und es gab nirgends einen Link dorthin, weder im Vertrag noch in Petlas eigenem Code. ⚠️ Ein ergänztes Feld, keine neue Version: ältere Auslieferungen lassen den Schlüssel weg, und §10.5 verlangt ohnehin, unbekannte Felder zu ignorieren. ⛔ Der Link trägt die pairingCodeId, nie den Code.Nein
2026-09-06Acht Codes mehr in der Fehlerliste — sechs für Dokumente, dazu core_capability_missing und appointment_not_reschedulable.Die letzten beiden waren älter als dieser Eintrag und standen nie in der Liste, obwohl beide von einer aktiven Route ausgegeben werden — core_capability_missing ausgerechnet auf PUT /capabilities, dem ersten Aufruf der dokumentierten Reihenfolge. §11 sagt eine Liste jedes Codes zu.Nein
2026-09-03busy: [] und windows: [] bedeuten das Gegenteil voneinander — und das stand vorher falsch da.Der Text sagte für beide geschlossen. windows: [] ist ein Tag ohne buchbares Fenster, also geschlossen; busy: [] ist ein Tag, an dem nichts belegt ist — also ganz offen, die Öffnungszeiten der Praxis unabgezogen. Wer die alte Zeile wörtlich befolgte, stellte einen ganzen Tag zum Verkauf.Nein
2026-09-03Event.data ist nicht mehr required.Es war als verpflichtender Appointment deklariert — womit das Schema das fünfte Mitglied seiner eigenen Ereignisliste nicht ausdrücken konnte: connection.revoked handelt von keinem Termin.Nein
2026-09-03§7.4 verwies für die Ablehnung auf §5.2. Jetzt beschreibt es den eigenen Weg.§5.2 ist der synchrone Fall: Petla bucht, Ihr System lehnt im selben Austausch ab, der Tierhalter steht noch im Formular. §7.4 ist asynchron — der Termin existiert bereits, der Tierhalter ist längst weg, und die Nachricht muss ihn per Mail erreichen. Der Verweis konnte diesen Fall nicht abdecken.Nein
2026-09-03Eine Veröffentlichung muss das Array ihrer deklarierten Form mitschicken, auch leer — und darf höchstens 380 Tage umspannen.Das Schema verlangte weder busy noch windows, also validierte ein Rumpf ohne beide und hätte geschlossen bedeutet. Viele Serialisierer lassen ein leeres Array weg, weshalb „heute nichts“ und ein halbfertiger Client byteweise identisch aussahen.Nein
2026-09-02GET /connections/pairing-codes/{pairingCodeId} — das Verbindungs-Token wird abgeholt.§4.1 Schritt 4 versprach ein Token, und kein Endpunkt konnte eines liefern: es gehört zu einem Moment in der Sitzung der Praxis, nicht zu Ihrer. Abrufen ist §3.1 und §8.1 angewandt — alles Verpflichtende sind Aufrufe von Ihnen zu uns.Nein
2026-09-02Capabilities.resourceSelection ist im Schema.§3.4's eigenes Beispiel hat es immer mitgeschickt und das Schema kannte es nicht — womit §10.5 („unbekanntes Feld ist ein 400“) das Beispiel der Spezifikation zu einem Fehler machte.Nein

Warum hier keine Versionsnummern stehen

Die Hauptversion steht im Pfad (/partner/v1/…) und ändert sich nur, wenn etwas Brechendes passiert — was bisher nicht der Fall war. Eine Nebenversion gibt es nicht: Sie würde suggerieren, dass Sie auf eine bestimmte aufsetzen können, und genau das sollen Sie nicht. specVersion in PUT /capabilities sagt uns, gegen welchen Stand Sie gebaut haben.

Achtung

Die Einträge oben stammen aus dem Vertragstext selbst. Jede Zeile entspricht einer Added 2026-…- oder Corrected 2026-…-Markierung in SPEC.md beziehungsweise openapi.yaml — diese Seite ist die Lesefassung, nicht ein zweiter Ort, an dem etwas gemerkt werden muss. Weicht sie ab, gilt der Vertragstext.