Versionsrichtlinie
Wie sich die NovaFisko-API weiterentwickelt, was als kompatible oder als inkompatible Änderung gilt und die Ankündigungsfrist von sechs Monaten bei Abkündigungen.
Eine Integration muss jahrelang unbeaufsichtigt laufen können. Diese Seite beschreibt die Zusagen von NovaFisko zur Weiterentwicklung seiner API und was wir im Gegenzug von Ihrem Code erwarten.
Die Version steht im Pfad
Die Hauptversion steht in der URL: https://api.novafisko.com/v1/.... Das Feld api_version der Webhooks trägt denselben Wert.
Solange Sie /v1/ aufrufen, sind Sie von keiner inkompatiblen Änderung betroffen. Eine inkompatible Weiterentwicklung führt zu einer neuen Hauptversion, /v2/, die neben der vorherigen veröffentlicht wird.
Es gibt keine Nebenversion, die per Header auszuwählen wäre. Kompatible Ergänzungen werden fortlaufend in v1 ausgerollt und im Änderungsprotokoll festgehalten.
Kompatible Änderungen
Diese Änderungen können jederzeit und ohne Vorankündigung eintreten. Ihre Integration muss sie tolerieren.
| Änderung | Was Ihr Code tun muss |
|---|---|
| Neue Route | Nichts |
| Neues Feld in einer Antwort oder in einem Webhook | Unbekannte Felder ignorieren |
| Neuer optionaler Parameter in einem Request | Nichts |
| Neues Webhook-Ereignis | Mit 200 antworten und unbekannte Ereignisse ignorieren |
Neuer Wert in einer offenen Aufzählung (status, code, type) |
Einen Standardfall vorsehen |
Neuer Fehler-code |
Sich zuerst auf den HTTP-Status stützen |
| Neuer Response-Header | Nichts |
| Anhebung eines Rate- oder Größenlimits | Nichts |
Änderung des Textes einer message |
Meldungen niemals analysieren |
| Änderung der Reihenfolge der Schlüssel eines JSON-Objekts | Nicht von dieser Reihenfolge abhängen |
Ein strikter Deserialisierer, der bei einem unbekannten Feld scheitert, bricht bei der ersten Ergänzung. Konfigurieren Sie Ihren Client so, dass er ignoriert, was er nicht kennt. Das ist die häufigste Ursache für den Ausfall einer Integration.
Inkompatible Änderungen
Diese Änderungen werden niemals in einer bestehenden Version vorgenommen.
- Eine Route, ein Feld oder einen Parameter entfernen oder umbenennen.
- Den Typ eines Feldes ändern, zum Beispiel von einer Zeichenfolge zu einer Zahl.
- Einen bisher optionalen Parameter zur Pflicht machen.
- Die Bedeutung eines bestehenden Feldes oder Status ändern.
- Einen Aufzählungswert oder ein Webhook-Ereignis entfernen.
- Das Format der Kennungen, der Datumsangaben oder der Beträge ändern.
- Das Signaturschema der Webhooks ändern.
- Den HTTP-Status eines dokumentierten Erfolgs- oder Fehlerfalls ändern.
- Ein dokumentiertes Rate-Limit senken.
Ausnahmen
Drei Situationen können eine Änderung ohne Einhaltung der Ankündigungsfrist rechtfertigen:
- Sicherheit. Eine Schwachstelle wird sofort behoben, auch wenn die Korrektur ein Verhalten ändert.
- Gesetzliche Pflicht. Eine von der Verwaltung vorgeschriebene Änderung (MwSt., Intervat, Peppol, Jahresabschluss) gilt ab dem gesetzlich festgelegten Datum.
- Fehlerkorrektur. Ein Verhalten, das der Dokumentation widerspricht, wird korrigiert. Wenn sich Integrationen erkennbar darauf stützen, informieren wir vorab.
In jedem dieser Fälle wird die Änderung im Änderungsprotokoll angekündigt.
Abkündigung
Wenn eine Route oder ein Feld entfallen soll, folgt NovaFisko diesem Zeitplan.
| Schritt | Zeitpunkt | Was geschieht |
|---|---|---|
| Ankündigung | T | Eintrag im Änderungsprotokoll, Hinweis in der Referenz und in der OpenAPI-Spezifikation (deprecated: true) |
| Kennzeichnung | Ab T | Die betroffenen Antworten tragen die Header Deprecation und Sunset |
| Erinnerung | T + 3 Monate | Nachricht an die Administratoren der Kanzleien, deren Tokens das Element noch verwenden |
| Entfernung | Frühestens T + 6 Monate | Das Element wird entfernt. Eine entfernte Route antwortet mit 410 Gone |
Die Mindestfrist zwischen Ankündigung und Entfernung beträgt sechs Monate.
Abkündigungs-Header
HTTP/1.1 200 OK
Deprecation: @1798761600
Sunset: Wed, 30 Jun 2027 23:59:59 GMT
Link: <https://docs.novafisko.com/de/api/changelog>; rel="deprecation"
| Header | Bedeutung |
|---|---|
Deprecation |
Datum, ab dem das Element abgekündigt ist, als Unix-Zeitstempel mit vorangestelltem @ |
Sunset |
Datum, ab dem das Element nicht mehr funktionieren kann |
Link mit rel="deprecation" |
Seite, die den Ersatz beschreibt |
Derzeit ist kein Element von v1 abgekündigt, und diese Header werden daher von keiner Route gesendet. Sie beschreiben, wie Ihnen eine künftige Abkündigung angezeigt wird.
Protokollieren Sie jede Antwort, die einen Header Deprecation enthält, und lösen Sie einen Alarm aus. So werden Sie von Ihrem eigenen Monitoring gewarnt, Monate vor der Entfernung.
Neue Hauptversion
Sollte eine v2 entstehen:
v1undv2laufen mindestens zwölf Monate parallel;- ein Migrationsleitfaden erläutert jeden Unterschied im Einzelnen;
- die Tokens bleiben in beiden Versionen gültig;
- die Webhooks behalten das Format
v1, solange Sie sich nicht für den Wechsel zuv2entschieden haben.
Was nicht abgedeckt ist
Diese Elemente können sich ohne Vorankündigung ändern. Bauen Sie nichts darauf auf.
- Routen, die in der Referenz und in der OpenAPI-Spezifikation fehlen.
- Die Routen
bridge/*, die der Anbindung an Novadesko vorbehalten sind. - Der genaue Inhalt der PDF-Dateien (Layout, Bezeichnungen).
- Der Text der Fehlermeldungen und der übersetzten Bezeichnungen.
- Das interne Format der signierten URLs. Behandeln Sie sie als opake Zeichenfolgen mit kurzer Lebensdauer.
- Die Daten der Demo-Kanzlei, die jede Nacht zurückgesetzt werden.
Die seit Langem bestehenden CSV-Exporte (Journale, Hauptbuch, Saldenliste, Kundenliste, Prüfprotokoll) haben dagegen eine stabile Spaltenstruktur, die unter die Zusagen dieser Seite fällt.
Eine langlebige Integration schreiben
- Ignorieren Sie Felder, Ereignisse und Aufzählungswerte, die Sie nicht kennen.
- Entscheiden Sie anhand des HTTP-Status, dann anhand von
code, niemals anhand vonmessage. - Senden Sie einen
User-Agent, der Ihre Integration und ihre Version kennzeichnet, zum BeispielERP-Atelier/2.4 (support@atelier.example). So können wir Sie bei Bedarf kontaktieren. - Sehen Sie bei jedem Versionssprung Ihres Produkts im Änderungsprotokoll nach.
- Generieren Sie Ihren Client von Zeit zu Zeit neu aus der OpenAPI-Spezifikation, um von den Ergänzungen zu profitieren.