Overview
Un message qui reste en file d'attente (sans jamais atteindre les états DELIVRD ou UNDELIV) signifie généralement qu'il a été accepté par la passerelle mais pas encore remis par l'opérateur de destination : souvent parce qu'il est programmé pour une livraison ultérieure, limité par votre limite de TPS, en attente d'expiration de sa période de validité pour un terminal hors service ou hors réseau, ou bloqué sur une route saturée. Vérifiez le délai d'attente (schtime), votre limite de débit et le DLR : un message ne quitte la file d'attente que lorsque l'opérateur renvoie un accusé de réception final.
C'est prévu pour plus tard.
Si vous définissez une heure de planification (avec GMT), la passerelle conserve le message jusqu'à ce moment précis, le mettant ainsi en file d'attente jusqu'à l'heure prévue. Vérifiez l'heure de planification et le fuseau horaire GMT que vous avez indiqués : un décalage GMT incorrect ou une date ultérieure est la raison la plus courante pour laquelle un lot n'est pas envoyé. Omettez l'heure de planification pour un envoi immédiat ; l'API REST renvoie un ScheduleId lorsqu'un envoi est programmé.
- schtime (yyyyMMddhhmm) + gmt conserve le message jusqu'à cette heure.
- Un décalage horaire GMT incorrect peut décaler les heures d'envoi.
- Omettez schtime pour envoyer maintenant.
- Un traitement par lots planifié renvoie un ScheduleId, et non une livraison immédiate.
Il est limité à votre limite TPS
Un traitement par lots important est effectué selon le débit autorisé de votre compte (messages par seconde). Les messages suivants restent en file d'attente pendant que les précédents sont envoyés ; il s'agit d'un traitement normal, et non d'une panne. Si un volume de données soutenu est important, demandez un débit par seconde plus élevé. Pour les envois très volumineux, il est préférable de téléverser un fichier de destinataires vers le point de terminaison d'envoi en masse `/sms/sendbulk` plutôt que de soumettre une seule requête volumineuse.
- Les gros lots s'écoulent au niveau du bouchon TPS — les pièces suivantes attendent.
- Il s'agit d'un rythme normal, et non d'une erreur.
- Demander un débit plus élevé pour un volume soutenu.
- Utilisez /sms/sendbulk pour les très grandes listes.
Le téléphone est injoignable pendant la période de validité.
Si le téléphone du destinataire est éteint ou hors réseau, le serveur SMSC de l'opérateur stocke le message et effectue des tentatives de livraison jusqu'à ce que le téléphone soit de nouveau disponible ou que la période de validité expire. Pendant ce laps de temps, le message est légitimement mis en file d'attente. Lorsque la période de validité expire sans avoir été distribué, le DLR indique « UNDELIV/expired » (message non distribué/expiré). Ainsi, un message resté longtemps en attente est souvent résolu de lui-même une fois le téléphone de nouveau disponible.
- Le système SMSC de stockage et de retransmission tente de recontacter un combiné injoignable.
- Le message reste en file d'attente jusqu'à sa livraison ou jusqu'à expiration de sa validité.
- À expiration, le DLR devient UNDELIV/expiré.
- Le problème se résout généralement lorsque le téléphone retrouve du réseau.
Vérifier les crédits, la route et le statut réel
Si aucune transaction n'est effectuée, vérifiez le solde (une requête peut échouer avec HTTP18, en raison d'un solde insuffisant) et assurez-vous que l'identifiant de l'expéditeur et la route sont approuvés pour la destination. En l'absence de webhook, ne déduisez pas l'état : récupérez directement l'état de chaque message (via l'API HTTP historique : /websmpp/websmsstatus avec l'identifiant de réponse).
- Aucun mouvement ? Vérifiez vos crédits — Solde insuffisant (HTTP18).
- Veuillez vérifier que l'identifiant de l'expéditeur et la route sont approuvés pour le pays.
- Lire l'état réel en le récupérant directement (API HTTP historique : /websmpp/websmsstatus).
- Ne tirez pas de conclusions hâtives à partir d'un webhook manquant ; vérifiez son statut.