Webhooks et reprise
Configurer une destination
Section intitulée « Configurer une destination »Un administrateur ouvre une clé API dans API & integrations et ajoute une destination HTTP ou HTTPS. HTTPS est recommandé ; l’interface signale HTTP, les adresses IP directes et les adresses locales sans empêcher l’enregistrement. Le middleware doit pouvoir joindre l’URL pour livrer les événements. Elle appartient à cette clé et possède son propre secret de signature, affiché uniquement lors de la création ou du renouvellement. Sélectionnez les types d’événements si votre récepteur ne doit recevoir qu’une partie du flux. Le remplacement ou la révocation d’une clé affecte aussi ses destinations ; préparez le récepteur avant l’activation.
Vérifier avant de traiter
Section intitulée « Vérifier avant de traiter »Chaque envoi contient webhook-id, webhook-timestamp et webhook-signature. La signature suit Standard Webhooks : HMAC-SHA256 sur les octets UTF-8 de webhook-id + "." + webhook-timestamp + ".", suivis des octets exacts du corps brut. Le secret commence par whsec_ ; la suite est une clé de signature encodée en Base64. Comparez la signature Base64 d’une entrée v1, en temps constant.
Rejetez les horodatages décalés de plus de cinq minutes de l’heure de votre serveur. Vérifiez la signature avant d’analyser le JSON. Contrôlez ensuite que l’id de l’événement correspond à webhook-id, puis enregistrez cet identifiant avant d’appliquer des effets métier. Une réponse 2xx rapide accuse réception.
Les envois peuvent être répétés et arriver dans le désordre. Dédupliquez-les par identifiant d’événement. Un événement de validation porte des identifiants et des chemins API ; récupérez le rapport ou le dossier actuel par l’API authentifiée si vous avez besoin des données complètes. Les événements de validation sont rental.departure.completed et rental.return.completed. Les corrections et la disponibilité du PDF disposent d’événements distincts. La définition OpenAPI du webhook Rental décrit tous les types et champs.
Retrouver les événements manqués
Section intitulée « Retrouver les événements manqués »Utilisez GET /v1/events avec son curseur et éventuellement created_after après une indisponibilité. Les événements restent disponibles pendant 30 jours. N’avancez votre curseur enregistré qu’après avoir traité la page reçue. La plateforme retente les envois échoués jusqu’à huit fois sur 48 heures ; un administrateur peut consulter et relancer les échecs récents dans API & integrations.
Considérez le flux comme une notification et les routes authentifiées comme source des données actuelles. La page Identité et versions des rapports explique leur archivage.