Fehlerbehandlung
RxScale APIs verwenden überwiegend dieselben Fehlerformate. Diese Seite dokumentiert die Fehlerformate, HTTP-Statuscodes und häufige Fehlerszenarien und nennt die Stellen, an denen eine API abweicht.HTTP-Statuscodes
Fehlerantwort-Formate
RxScale APIs verwenden drei Fehlerantwort-Formate, abhängig vom Fehlertyp.Standardfehler
Die meisten Fehler geben einen einfachen Fehlerstring zurück:"Resource not found"— Ressource existiert nicht oder Sie haben keinen Zugriff"Bad request"— Allgemeiner Fehler; der Grund wird nur in den Protokollen von RxScale festgehalten, nicht in der Antwort. In der External Pharmacy API deckt er auch Anfragen ab, die RxScale ablehnt, etwa die Statusänderung einer stornierten Bestellung — siehe Fehlerantworten der External Pharmacy API"Missing required parameters: from and to"— Spezifische Information über fehlende Parameter
Authentifizierungsfehler
Authentifizierungsfehler sowie Berechtigungsfehler in der Management API und der Public API geben einen Code und eine Beschreibung zurück:
Die External Pharmacy API verwendet
permission_denied nicht: Ein Schlüssel ohne die erforderliche Berechtigung erhält 403 mit {"error": "Permission denied"}. Siehe Fehlerantworten der External Pharmacy API.
Validierungsfehler
Schema-Validierungsfehler geben feldbezogene Fehlerdetails zurück:Fehlerantworten der External Pharmacy API
Die External Pharmacy API gibt die folgenden Fehlerantworten zurück. Verlassen Sie sich auf den HTTP-Statuscode und behandeln Sie den Antwortkörper als zusätzliche Information.{"error": "Bad request"} ist ein allgemeiner Fehler. Der Grund wird nur in den Protokollen von RxScale festgehalten, nicht in der Antwort. Neben unerwarteten Fehlern deckt er ab:
- Anfragen, die RxScale ablehnt, zum Beispiel die Statusänderung einer stornierten Bestellung;
- bei Endpoints mit Anfragekörper (außer
complete_order) einen Anfragekörper, der kein gültiges JSON ist oder ohneContent-Type: application/jsongesendet wird; - einen gruppenweiten API-Schlüssel ohne
pharmacy_uidoder mit einerpharmacy_uidaußerhalb seiner Apothekengruppe.
PATCH /pharmacy_orders/{uid}/complete_order hat drei weitere 400-Varianten:
{"error": ["Invalid JSON in request body"]}— der Anfragekörper ist kein gültiges JSON. Hier isterroreine Liste.{"error": {...}, "pharmacy": {"uid": "...", "display_name": "..."}}— der Anfragekörper hat die Validierung nicht bestanden, zum Beispiel wegen eines nicht unterstütztencarrier.pharmacynennt die Apotheke, für die die Anfrage gestellt wurde.{"error": "<message>"}— Sie haben Tracking-Links für eine bereits abgeschlossene Bestellung gesendet.
Häufige Fehlerszenarien
401 — Fehlender API-Schlüssel
401 — Fehlender API-Schlüssel
Anfrage:Antwort:Lösung: Fügen Sie den
X-API-Key-Header in Ihre Anfrage ein.403 — Unzureichende Berechtigungen
403 — Unzureichende Berechtigungen
Anfrage: Versuch, mit einem schreibgeschützten API-Schlüssel zu schreiben.Management API und Public API — erkennen Sie diesen Fehler an External Pharmacy API:Lösung: Überprüfen Sie die Berechtigungen Ihres API-Schlüssels. Möglicherweise müssen Sie einen neuen Schlüssel mit den erforderlichen Berechtigungen erstellen.
code; description ist ein lesbarer Text:404 — Ressource nicht gefunden
404 — Ressource nicht gefunden
Anfrage: Zugriff auf eine Ressource mit einer ungültigen UID oder ohne Zugriffsberechtigung.Lösung: Überprüfen Sie, ob die Ressourcen-UID korrekt ist. Wenn Sie sicher sind, dass die UID gültig ist, prüfen Sie, ob Ihr API-Schlüssel die Berechtigung zum Zugriff auf die Ressource hat.
400 — Validierungsfehler
400 — Validierungsfehler
Anfrage: Übermittlung eines ungültigen Anfragekörpers.Lösung: Überprüfen Sie jedes im Fehler aufgelistete Feld und geben Sie gültige Werte an.
409 — Doppelte Ressource
409 — Doppelte Ressource
Anfrage: Erstellung einer Ressource, die bereits existiert.Lösung: Die Ressource existiert bereits. Verwenden Sie eine GET-Anfrage, um sie abzurufen, oder verwenden Sie PATCH, um sie zu aktualisieren.
413 — Anfragekörper zu groß
413 — Anfragekörper zu groß
Anfrage: Ein Körper über dem Limit von 32 MiB.Lösung: Verteilen Sie die Daten auf mehrere Anfragen.
429 — Ratenlimit überschritten
429 — Ratenlimit überschritten
Sie haben das Ratenlimit überschritten. Der Antwortkörper ist HTML, kein JSON:Es werden weder ein
Retry-After- noch X-RateLimit-*-Header gesendet.
Lösung: Warten Sie mindestens eine Sekunde — ein volles Ratenlimit-Fenster — und
versuchen Sie es dann erneut. Siehe Ratenbegrenzungen für Details
und bewährte Praktiken.Bewährte Praktiken
Prüfen Sie immer zuerst den HTTP-Statuscode
Prüfen Sie immer zuerst den HTTP-Statuscode
Der Statuscode zeigt Ihnen die Fehlerkategorie. Analysieren Sie den Antwortkörper für Details erst nach der Prüfung des Statuscodes.
Behandeln Sie 404 defensiv
Behandeln Sie 404 defensiv
Ein
404 kann bedeuten, dass die Ressource nicht existiert ODER dass Sie keinen Zugriff haben. Nehmen Sie nicht an, welches der Fall ist — überprüfen Sie sowohl die Berechtigungen Ihres API-Schlüssels als auch die Ressourcen-UID.Implementieren Sie exponentielles Backoff für 429
Implementieren Sie exponentielles Backoff für 429
Wenn das Ratenlimit erreicht ist, warten Sie und wiederholen Sie die Anfrage mit zunehmenden Verzögerungen. Wiederholen Sie nie sofort in einer engen Schleife.
Protokollieren Sie die vollständige Fehlerantwort
Protokollieren Sie die vollständige Fehlerantwort
Protokollieren Sie zum Debuggen den gesamten Antwortkörper einschließlich Statuscode und Headern. Der RxScale-Support kann nach diesen Details fragen.