Envoyer un événement de test signé à l’URL du webhook
- Dans le bac à sable
En termes simples
Le corps contient event_id, type (toujours test), occurred_at et message, signés comme un événement de statut. Il ne concerne aucune facture. Depuis la 0.16.0, tout paramètre de requête répond 400.
apiKeyAuthorizationBearer <token>Envoyez votre clé sous forme de jeton bearer : Authorization: Bearer <your-api-key>. L’état du service est le seul appel qui ne nécessite pas de clé.
Ce qu’a répondu le point de terminaison du partenaire.
application/json- response
delivered*booleanhttp_status*integer|nullduration_ms*integercurl -X POST "https://example.com/webhook/test" \ -H "Authorization: Bearer <your-api-key>"{ "delivered": true, "http_status": 0, "duration_ms": 0}Définir l’URL du webhook, ou renouveler son secret PUT
La clé de l’opérateur définit le webhook de l’opérateur, qui reçoit les événements de tous les clients ; la clé d’administration d’un client définit celui de ce client, qui ne reçoit que ses événements. Le premier appel exige url et crée le secret, renvoyé une seule fois. Le renouvellement renvoie le nouveau secret une seule fois. Pendant 24 heures, le service signe chaque livraison avec le nouveau et l’ancien secret, afin que le partenaire puisse basculer sans perdre d’événements. Seuls les événements écrits après le premier appel sont livrés. L’URL doit être en https, et chaque adresse que son hôte résout doit être publique : les adresses de bouclage, privées, link-local, CGNAT, multicast, réservées et de métadonnées cloud sont refusées, ici et de nouveau avant chaque livraison. Les redirections ne sont pas suivies. Depuis la 0.16.0, tout paramètre de requête répond 400, de sorte qu’un client mal orthographié ne peut jamais modifier le webhook de l’opérateur.
Le bac à sable hébergé, et comment demander une clé.