---
title: "Comment recevoir les accusés de réception via un webhook ?"
description: "Recevoir les accusés de réception SMS et WhatsApp par webhook : configurer l'endpoint, mapper les statuts, dédoublonner, sécuriser et récupérer les manqués."
canonical: "https://omnichannels.ai/fr/answers/delivery-report-webhook/"
language: "fr"
updated: "2026-10-10"
publisher: "BroadNet Technologies"
brand: "OmniChannels.ai"
---

# Comment recevoir les accusés de réception via un webhook ?

Canonical: https://omnichannels.ai/fr/answers/delivery-report-webhook/
Language: fr
Publisher: OmniChannels.ai by BroadNet Technologies

**Réponse courte:** Pour recevoir les accusés de réception par webhook, exposez un endpoint HTTPS qui accepte les requêtes POST et déclarez son URL auprès de votre fournisseur de messagerie. Enregistrez chaque événement, répondez vite par un statut 2xx et traitez-le de façon asynchrone. Rapprochez les événements de vos enregistrements par identifiant de message, dédoublonnez-les et ne laissez jamais un statut tardif écraser un statut final.

## Configurer l'endpoint

En développement, un tunnel donne une URL HTTPS publique à un serveur local.

1. Exposez un endpoint HTTPS qui accepte des requêtes POST avec un corps JSON.
2. Transmettez l'URL à votre fournisseur pour qu'elle soit configurée sur le bon compte ou sous-compte.
3. Envoyez un message de test à votre propre numéro et journalisez le corps brut de l'événement.
4. Mappez les champs utiles à partir d'événements réels, pas de noms de champs supposés.
5. Conservez des exemples de payloads comme jeux de test pour chaque canal utilisé.

## Quels statuts allez-vous recevoir ?

Les fournisseurs traduisent les accusés des opérateurs et des canaux dans leurs propres noms de statut. Voici l'ensemble normalisé qu'utilise OmniChannels.ai pour le SMS, WhatsApp et les autres canaux.

| Statut | Signification | Final ? |
|---|---|---|
| SUBMITTED | Accepté et mis en file d'attente | Non |
| SENT | Transmis à l'opérateur ou au canal | Non |
| DELIVERED | Confirmé sur l'appareil | En général ; READ peut suivre |
| READ | Ouvert, sur les canaux qui signalent la lecture | Oui |
| FAILED | Non délivré, avec un motif si disponible | Oui |
| REJECTED | Refusé, par exemple pour un identifiant d'expéditeur (Sender ID) non enregistré | Oui |

## Fiabiliser le traitement

- Enregistrez le corps brut, puis renvoyez 2xx. Si l'enregistrement échoue, renvoyez 5xx pour que l'événement soit renvoyé.
- Faites le vrai traitement dans une file ou un worker, pas avant de répondre.
- Dédoublonnez par identifiant de message ; un même statut peut arriver deux fois.
- Hiérarchisez les statuts pour qu'un SENT tardif n'écrase jamais DELIVERED.
- Acceptez les valeurs de statut inconnues au lieu d'échouer.
- Ne renvoyez jamais un message depuis le gestionnaire du webhook.

## Sécuriser l'endpoint et récupérer les accusés manqués

N'acceptez que le HTTPS, utilisez un chemin long et impossible à deviner, validez la structure du corps et confirmez l'état par un appel de statut avant toute action irréversible, comme un remboursement. Si votre endpoint était indisponible, demandez au fournisseur de renvoyer les accusés de la période ou lisez les statuts via ses endpoints de reporting.

En SMPP, les accusés arrivent sous forme de deliver_sm sur le bind plutôt que par webhook. Certains opérateurs renvoient les accusés en retard, voire jamais : considérez-les comme un indice fort, pas comme la preuve d'une lecture.

## Sources officielles

- [SMPP Protocol Specification v3.4 (Issue 1.2) — SMPP.org](https://smpp.org/SMPP_v3_4_Issue1_2.pdf)
- [RFC 9110: HTTP Semantics (IETF)](https://datatracker.ietf.org/doc/html/rfc9110)

## Questions associées

- https://omnichannels.ai/fr/answers/sms-delivery-report-statuses/
- https://omnichannels.ai/fr/answers/integrate-sms-api/
- https://omnichannels.ai/fr/answers/connect-sms-provider-smpp/
- https://omnichannels.ai/fr/answers/why-sms-not-delivered/

Mis à jour le: 2026-10-10