Synchronisierung und Fehler

Aktualisierungen in der richtigen Reihenfolge halten

Fahrzeug- und Rental-Upserts sind auf Ihre Organisation und Ihre external_id begrenzt. Übermitteln Sie beim Anlegen den verfügbaren Kontext. Senden Sie bei späteren inhaltlichen Änderungen source_revision oder source_updated_at. Bevorzugen Sie eine ganzzahlige Revision aus Ihrem Quellsystem und erhöhen Sie diese streng. Sobald eine Revision gespeichert ist, kann ein Zeitstempel sie nicht überschreiben. Nicht gesendete Eigenschaften behalten ihren aktuellen Wert; ein ausdrückliches null löscht nur nullable Felder. Unbekannte Eigenschaften werden abgelehnt.

Die Regeln des Rental-Lebenszyklus gelten weiterhin: Die Fahrzeugzuweisung wird mit Beginn der ersten Inspektion festgeschrieben; nach der Abfahrt werden einige Planungsfelder festgeschrieben; nach Abschluss bleiben nur unterstützte Korrekturen an Berichtsdetails möglich. Eine widersprüchliche oder ältere Aktualisierung erzeugt einen strukturierten Fehler. Lesen Sie die aktuelle Ressource, bevor Sie mit einer neuen Revision erneut senden.

POST-Befehle sicher wiederholen

Jeder schreibende POST-Vorgang benötigt den Header Idempotency-Key. Erzeugen Sie für jede beabsichtigte Aktion einen eindeutigen Wert, behalten Sie ihn bei Netzwerkwiederholungen bei und verwenden Sie ihn niemals mit einem anderen Anfragetext. Der Schlüssel ist auf Ihre Organisation begrenzt und wird sieben Tage gespeichert. Wird derselbe abgeschlossene Befehl erneut gesendet, liefert die API die ursprüngliche erfolgreiche Antwort; eine widersprüchliche Wiederverwendung schlägt fehl.

PUT über eine externe Kennung ist deterministisch, doch Versionsmarkierungen sind bei inhaltlichen Änderungen weiterhin erforderlich. Erzeugen Sie für die Wiederholung desselben Fahrzeugs oder derselben Reservierung keine neue externe Kennung.

Fehler behandeln

API-Fehler verwenden application/problem+json mit stabilem code, HTTP-status, verständlichem detail, request_id, retryable und optionalen feldbezogenen errors. Protokollieren Sie für Supportanfragen die request_id, jedoch keine Geheimnisse oder Bytes privater Dokumente.

Die type-URL verweist auf eine öffentliche Fehlerseite. So erläutert INVALID_API_KEY Ursache und nächste Aktion. Jeder Code dieses Middlewares besitzt eine entsprechende Seite in allen unterstützten Sprachen.

Antwort	Aktion
401	Prüfen, ob der Schlüssel gültig, abgelaufen oder widerrufen ist.
403	Schlüsselberechtigungen und kommerziellen Zugang der Organisation prüfen.
409	Aktuelle Ressource oder Idempotenzkonflikt untersuchen, bevor die Anfrage geändert wird.
422	Benannte Felder korrigieren; denselben ungültigen Inhalt nicht wiederholen.
429	Retry-After und Rate-Limit-Header beachten.
503	Gemäß retryable und vorhandenem Retry-After wiederholen.

GET /v1/capabilities meldet die wirksamen Kontingente, Dateigrenzen und Aufbewahrungswerte Ihres Schlüssels. Für die möglichen Antworten jeder Route ist die API-Referenz maßgeblich.