Synchronisation et erreurs
Garder les modifications dans l’ordre
Section intitulée « Garder les modifications dans l’ordre »Les mises à jour de véhicules et de dossiers Rental utilisent votre external_id dans votre organisation. À la création, fournissez le contexte disponible. Pour toute modification ultérieure, envoyez source_revision ou source_updated_at. Privilégiez un numéro de révision de votre logiciel et augmentez-le strictement. Dès qu’une révision est enregistrée, un horodatage ne peut plus la contourner. Les champs absents conservent leur valeur ; null n’efface que les champs qui l’acceptent. Les champs inconnus sont refusés.
Les règles du cycle Rental restent applicables : le véhicule est figé dès la première inspection ; après le départ, certains champs prévus sont figés ; après la clôture, seules les corrections de détails de rapport prises en charge restent possibles. Une modification ancienne ou incompatible reçoit une erreur structurée. Relisez la ressource actuelle avant une nouvelle tentative avec une révision différente.
Réessayer les commandes POST sans doublon
Section intitulée « Réessayer les commandes POST sans doublon »Chaque écriture POST demande l’en-tête Idempotency-Key. Créez une valeur unique par opération voulue, gardez-la identique lors des nouvelles tentatives réseau et ne la réutilisez jamais avec un autre contenu. Elle est propre à votre organisation et conservée sept jours. La répétition d’une commande terminée renvoie sa première réponse réussie ; une réutilisation incompatible échoue.
Le PUT par identifiant externe est déterministe, mais l’ordre des versions reste important pour les modifications. Ne créez pas un nouvel identifiant externe pour réessayer le même véhicule ou la même réservation.
Traiter les erreurs
Section intitulée « Traiter les erreurs »Les erreurs API utilisent application/problem+json avec un code stable, le status HTTP, un detail lisible, un request_id, retryable et éventuellement des errors par champ. Conservez le request_id pour le support, sans enregistrer de secrets ni d’octets de documents privés dans vos journaux.
L’URL type ouvre la page de l’erreur. Par exemple, INVALID_API_KEY explique la cause et la marche à suivre. Chaque code renvoyé par ce middleware possède une page en français, en anglais et en espagnol.
| Réponse | Action |
|---|---|
401 | Vérifier si la clé est valide, expirée ou révoquée. |
403 | Vérifier les permissions de la clé et les droits commerciaux de l’organisation. |
409 | Examiner la ressource actuelle ou le conflit d’idempotence avant de modifier la requête. |
422 | Corriger les champs indiqués ; ne pas renvoyer le même contenu invalide. |
429 | Respecter Retry-After et les en-têtes de limitation. |
503 | Réessayer selon retryable et l’éventuel Retry-After. |
GET /v1/capabilities indique les quotas, limites de fichiers et durées de conservation applicables à votre clé. La référence API fait foi pour les réponses possibles de chaque route.