Un SMS accepté peut encore échouer à cause d'un numéro invalide, d'un terminal injoignable ou d'un problème réseau. L'enregistrement du message, l'événement de remise et l'erreur retournée aident à distinguer ces résultats du filtrage.
Comment investiguer un filtrage suspecté ?
Vous comparez l’enregistrement du message à ses événements SMS. L’événement décrit le résultat ; l’erreur et les détails du fournisseur aident à l’expliquer.
| Événement | Ce que l'événement vous indique |
|---|---|
sms.rejected | Le traitement ou un fournisseur en aval a refusé le message accepté. |
sms.failed | Un échec permanent a été signalé. |
sms.undelivered | Un échec récupérable a été signalé, tel qu'un abonné injoignable ou un problème réseau. |
sms.expired | Le fournisseur a signalé une expiration. |
Aucun événement seul ne prouve un filtrage. Dans le mappage d'accusé de réception de Bird, une raison fournisseur carrier_rejected devient content_rejected. Une raison non mappée devient unknown, qui nécessite une investigation et peut avoir une cause sans rapport. Le statut d'un accusé de réception détermine l'événement indépendamment de sa raison, de sorte qu'un rejet opérateur peut accompagner différents événements d'échec.
Le catalogue d’erreurs définit blocked_by_carrier et sender_unregistered. Leur absence n’exclut pas un filtrage : Bird associe carrier_rejected à content_rejected et les causes non reconnues à unknown. Vérifiez le code réellement renvoyé, conservez les valeurs inconnues ainsi que les détails du fournisseur.
Quels détails faut-il enregistrer ?
Conservez l'identifiant du message, l'expéditeur, la destination, l'heure de soumission, le type d'événement, le error.code normalisé, la description et carrier_error_code. Regroupez les échecs par destination, expéditeur et type de message ; un échec isolé fournit moins de preuves qu'un changement affectant un groupe cohérent d'envois.
Le code normalisé est le champ stable pour le traitement par votre application. La description est un texte de diagnostic : ne l'analysez pas comme un contrat figé. carrier_error_code contient le code plus détaillé du fournisseur d'envoi lorsqu'il est fourni ; il n'est pas garanti qu'il s'agisse du propre code de l'opérateur mobile. Il peut être vide lorsque le fournisseur n'en fournit pas ou lorsqu'un échec survient avant la transmission au fournisseur.
Par exemple, content_rejected vous oriente vers le rejet signalé, invalid_destination vers le numéro du destinataire, et provider_unavailable vers le résultat réseau ou de capacité. unknown laisse la cause non résolue. Partagez l'identifiant du message et le code fournisseur disponible avec le support lorsque ces détails n'expliquent pas l'échec.
L'enregistrement de mon expéditeur empêche-t-il le filtrage ?
L'enregistrement satisfait le programme d'expéditeur applicable ; il ne garantit pas la remise. L'expéditeur doit aussi être éligible pour la destination, et le message et le trafic doivent respecter les exigences correspondantes.
Pour la messagerie A2P aux États-Unis avec des numéros locaux, vérifiez l'intégralité de l'enregistrement 10DLC : marque, campagne et liaison de numéro. Une marque ou une campagne approuvée ne lie pas automatiquement chaque numéro que vous possédez. Les programmes de numéros gratuits et de numéros courts ont des exigences différentes. D'autres destinations peuvent nécessiter l'enregistrement du nom d'expéditeur.
Utilisez les destinations SMS pour planifier le choix de l'expéditeur, puis confirmez les exigences applicables et l'état d'enregistrement de votre espace de travail avant le lancement. Un guide pays est un instantané de référence, pas la preuve que votre expéditeur est approuvé.
Que faire en cas d'échec lié à un opt-out ?
Préservez la préférence. Un envoi vers une paire expéditeur-destinataire supprimée par Bird est refusé au niveau du API avec E12077 ; ce refus ne crée ni message ni événement de message. Un signalement en aval de recipient_opted_out est différent : c'est un résultat pour un message accepté, et il amène Bird à enregistrer une suppression pour la paire.
Les mots-clés de désinscription pris en charge peuvent créer des exclusions par paire expéditeur-destinataire. Ces événements d’exclusion ne représentent pas toutes les préférences de l’espace de travail ni toutes les demandes reçues par le service client. Intégrez ces préférences plus larges à la sélection de votre audience. Ne changez pas d’expéditeur pour contourner une désinscription.
Que faut-il vérifier avant de réessayer ?
- Disponibilité de l'expéditeur. Confirmez le type d'expéditeur, l'enregistrement et l'accès à la destination requis pour ce trafic.
- Consentement et pertinence. Confirmez que la personne a accepté cet usage et n'a pas retiré cette autorisation.
- Contenu et liens. Identifiez clairement l'entreprise, utilisez des liens appropriés et vérifiez les exigences de contenu de la destination. Changer un lien seul ne peut pas établir l'éligibilité à la remise.
- Trafic et timing. Comparez les envois échoués avec votre schéma habituel, la mise en file d'attente et les limites de la route. Resoumettre à répétition le même contenu rejeté peut ajouter des coûts sans corriger la cause.
- L'échec signalé. Investiguez les refus permanents avant de renvoyer. Pour une réponse API ambiguë, réutilisez la clé d'idempotence originale dans sa fenêtre de rejeu ; ne transformez pas l'incertitude en une seconde requête automatique.
Le routage SMS applique les contrôles de destination avant le transfert à l’opérateur. Une intégration SMS suit chaque demande acceptée à travers l’enregistrement du message et ses événements de livraison.
En bref
Un échec de remise est un point de départ pour l'investigation.
L’événement, l’erreur normalisée et les détails du fournisseur décrivent l’échec. Une cause inconnue ne prouve pas un filtrage par l’opérateur.
L'enregistrement est une exigence, pas une garantie de remise.
Vérifiez l'expéditeur, la destination, le contenu, le consentement et le schéma de trafic avant de décider quoi modifier.
Un opt-out est une préférence à préserver.
Distinguez un refus API pour une paire supprimée d'un signalement d'opt-out en aval, et respectez la portée complète de la demande de la personne.
Conservez les preuves avec le message.
Enregistrez l'identifiant du message, la destination, l'expéditeur, l'heure, l'événement et les détails de l'erreur afin de pouvoir investiguer un schéma ou ouvrir un cas de support utile.