--- title: "URL de rappel SMS" description: "Envoyez les événements d'un message SMS, ou les réponses d'un profil de messagerie, vers votre propre URL HTTPS. Couvre le routage, la vérification des signatures, les nouvelles tentatives et la relecture des échecs." canonical: "https://bird.com/fr-fr/documentation/guides/sms/callbacks" --- # URL de rappel SMS Une URL de rappel reçoit les événements d'un message SMS, ou de tous les messages d'un profil de messagerie, à la place de vos endpoints de webhook. Utilisez-la lorsqu'un message ou un programme a besoin de son propre récepteur. Gérez le secret de signature, l'historique des tentatives et la relecture dans le tableau de bord, ou via l'[API](/docs/api/reference/rotate-webhook-callback-signing-secret) et les commandes `bird webhooks callbacks`. Définissez l'URL d'un profil lorsque vous [créez un profil de messagerie](/docs/api/reference/create-sms-messaging-profile) ou [le modifiez](/docs/api/reference/update-sms-messaging-profile). ## Choisir la destination des événements L'URL est déterminée une seule fois, au moment où le message est accepté, et conservée pendant toute la durée de vie du message. Une modification ultérieure du profil ne redirige pas un message déjà en cours d'acheminement. | Message | URL utilisée | | ---------------------------------------------------- | -------------------------------------------------------------------- | | Envoyé avec `options.callback_url` | Cette URL | | Envoyé avec `options.callback_url` défini sur `null` | Aucune : les événements vont à vos endpoints de webhook | | Envoyé sans elle, sur un profil de messagerie | Le `options.callback_url` du profil | | Reçu sur un numéro d'un profil de messagerie | Le `inbound.callback_url` du profil, puis son `options.callback_url` | | Aucune URL issue des cas ci-dessus | Aucune : les événements vont à vos endpoints de webhook | L'URL doit être HTTPS, compter au plus 2 048 caractères et pointer vers une adresse publique. Un hôte privé, de bouclage ou link-local renvoie `422`. La liste des tentatives de callback indique où l'événement d'un message reçu a été livré. ## Ce que l'URL remplace Tant qu'une URL s'applique, les événements de ce message ne passent pas par vos endpoints de webhook. Les autres messages de l'espace de travail les atteignent toujours. Un callback en échec ne se rabat pas sur vos endpoints : utilisez la [relecture](#trouver-et-relire-les-callbacks-en-échec) pour le récupérer. Les abonnements MCP Events et les endpoints de connecteurs reçoivent toujours les événements du message. Les `callback_events` d'un profil de messagerie déterminent quels événements sortants vont à l'URL, parmi `sms.accepted`, `sms.sent`, `sms.delivered`, `sms.undelivered`, `sms.failed`, `sms.rejected` et `sms.expired`. Un événement absent de la liste n'atteint pas non plus les endpoints de webhook pour ce message. Un profil sans liste, ainsi qu'un envoi sans profil, transmettent tous les événements sortants. `sms.received` n'est jamais filtré. Les payloads sont les [événements SMS](/docs/guides/sms/events). ## Vérifier les signatures Les callbacks utilisent les mêmes en-têtes [Standard Webhooks](/docs/guides/webhooks#verify-signatures) et la même signature HMAC-SHA256 que les endpoints de webhook : votre code de vérification existant fonctionne donc sans modification. La clé est le secret de signature des callbacks de votre espace de travail, un secret unique partagé par toutes les URL de callback et toutes les requêtes webhook des séquences vocales : une rotation s'applique donc aux deux. Le premier secret n'est jamais affiché. Effectuez une rotation pour en obtenir un que vous pouvez utiliser, sous **Webhooks → Direct callbacks** dans le tableau de bord ou avec [Rotate callback signing secret](/docs/api/reference/rotate-webhook-callback-signing-secret). Le nouveau secret n'apparaît qu'une fois : enregistrez-le avant de quitter la page. Pendant les 24 heures suivantes, chaque callback est signé avec l'ancien et le nouveau secret, ce qui vous permet de déployer le nouveau sans perdre de livraisons. Un espace de travail détient au plus 5 secrets valides simultanément : une nouvelle rotation pendant la période de chevauchement peut donc être refusée. Une rotation prend effet en une minute environ. Effectuez une rotation avant de vous fier à la vérification : d'ici là, les callbacks portent une signature créée avec un secret que vous ne pouvez pas lire. ## Nouvelles tentatives et doublons Les callbacks suivent le [calendrier de nouvelles tentatives des endpoints de webhook](/docs/guides/webhooks#delivery-semantics) : huit tentatives sur environ 27,5 heures, et une réponse `2xx` reçue en moins de 15 secondes compte comme un succès. Contrairement à un endpoint, une URL de callback n'est jamais mise en pause. La livraison se fait au moins une fois et sans ordre garanti. Dédupliquez à l'aide de l'en-tête `webhook-id` et triez selon le champ `timestamp` du payload. ## Trouver et relire les callbacks en échec L'onglet **Direct callbacks** sous **Webhooks** dans le tableau de bord, ainsi que [List callback delivery attempts](/docs/api/reference/list-webhook-callback-attempts), affichent les tentatives de callback de l'espace de travail, des plus récentes aux plus anciennes, avec l'URL, le statut renvoyé par votre récepteur et la latence. Les tentatives sont conservées pendant trois jours. [Replay failed callback deliveries](/docs/api/reference/create-webhook-callback-replay) met en file d'attente une tentative supplémentaire pour chaque événement dont les callbacks ont échoué dans une période que vous choisissez, comme le fait la [relecture des livraisons aux endpoints](/docs/guides/webhooks#replaying-failed-deliveries) pour les endpoints. Un événement également livré avec succès dans cette période est ignoré. Un succès hors de la période ne compte pas : cet événement est donc renvoyé. Une relecture envoie au plus les 10 000 événements en échec les plus anciens de la période ; après une panne plus longue, relancez une relecture avec une heure de début plus tardive pour traiter le reste. Une relecture envoie vers l'URL enregistrée sur les tentatives en échec, ni vers vos endpoints de webhook, ni vers l'URL actuelle du profil. Elle permet de récupérer après une panne de votre récepteur. Elle ne peut pas récupérer un message envoyé à une mauvaise URL : renvoyez alors ce message. Les relectures sont décomptées de la même limite quotidienne que les relectures d'endpoints. ## Étapes suivantes - [Événements SMS](/docs/guides/sms/events) : le payload de chaque événement - [Webhooks et événements](/docs/guides/webhooks) : signatures, nouvelles tentatives et relecture en détail - [Envoyer des messages SMS](/docs/guides/sms/sending-sms) : la requête d'envoi ## Related resources - [Sending your first SMS](/learn/sms/sending-your-first-sms) (video) - [What does SMS mean?](/explained/sms/what-does-sms-mean) (answer) - [SMS](/sms-api) (product) - [Build your first integration](/learn/paths/integration) (course) [Get an implementation brief](/learn/workspace?topic=sms)