Platform

Bird propose-t-il un sandbox, et que sont les numéros magiques ?

Bird simule la livraison via des destinations magiques sur son API normale, sans hôte sandbox ni clé de test séparés.

Un gestionnaire de webhooks a besoin de tests pour les échecs de livraison autant que pour les succès. Un test qui s'arrête à la réponse d'envoi ne peut pas confirmer comment votre application gère l'événement ultérieur.

Les destinations magiques vous permettent d'exercer ces résultats sans atteindre une vraie boîte de réception ou un vrai terminal. La validation de requête s'applique toujours, ce qui expose aussi les envois malformés.

Comment envoyer une requête de test ?

Envoyez vers une destination magique reconnue en utilisant vos identifiants et votre endpoint API habituels.

Il n'y a pas de mode test à activer. Pour l'e-mail, utilisez une adresse documentée sur messagebird.dev. Pour SMS, utilisez l'un des numéros ci-dessous.

Les destinataires simulés suivent les chemins normaux d'événements et de webhooks signés. Ils n'exercent pas la livraison vers une infrastructure externe. Ils ne peuvent donc pas vérifier le placement réel en boîte de réception ni le rendu sur terminal.

Utilisez uniquement des destinations magiques reconnues lorsqu'un test ne doit contacter personne. Une requête peut mélanger destinataires simulés et réels. Les destinataires réels sont livrés normalement.

Quelles adresses e-mail utiliser ?

Utilisez delivered@messagebird.dev pour tester l'acceptation par le serveur de réception. Les autres adresses ci-dessous exercent la gestion des rebonds, plaintes et rejets.

AdresseRésultat
delivered@messagebird.devLe serveur de réception accepte le message.
bounce@messagebird.dev ou hardbounce@messagebird.devUn rebond définitif avec SMTP 550 ; testez la gestion des échecs permanents.
softbounce@messagebird.devUn rebond temporaire avec SMTP 451 ; testez la classification des échecs temporaires.
deferred@messagebird.dev ou delay@messagebird.devUn report sans nouvelle tentative simulée ultérieure.
complaint@messagebird.dev ou spam@messagebird.devUne plainte pour spam.
suppressed@messagebird.devRejet en tant que destinataire déjà supprimé, sans événement de traitement ni de livraison.
reject@messagebird.devRejet avant une tentative de livraison.

La correspondance ignore la casse. Elle supprime +label avant de sélectionner le résultat. Par exemple, bounce+signup-flow@messagebird.dev produit toujours un rebond. L'adresse complète reste dans les événements pour que vous puissiez les associer à ce test.

Seuls les noms documentés sur ce domaine sont magiques. bounce@yourdomain.com est un destinataire normal, tout comme un nom non reconnu sur messagebird.dev.

Les rebonds et plaintes simulés n'ajoutent pas d'adresses à la liste de suppression de Bird et n'affectent pas la réputation d'envoi. Votre application reçoit quand même leurs événements : vérifiez comment votre propre logique de suppression les gère.

Tester la livraison d'e-mails répertorie les séquences d'événements complètes et les règles de correspondance.

Quels numéros de téléphone utiliser ?

Utilisez +15005550006 pour tester une livraison SMS réussie. Les autres numéros ci-dessous exercent les chemins de rejet et d'échec.

DestinationRésultat
+15005550001Rejet de soumission avec invalid_destination.
+15005550002sms.sent, puis sms.undelivered avec unreachable.
+15005550003sms.sent, puis sms.failed avec provider_unavailable.
+15005550004sms.sent, puis sms.failed avec blocked_by_carrier.
+15005550006sms.sent, puis sms.delivered.
+15005550009sms.sent, puis sms.failed avec recipient_opted_out.

Activez les États-Unis sous Destinations. Utilisez un expéditeur from valide pour les États-Unis. Un expéditeur alphanumérique y est rejeté, il ne peut donc pas tester ces numéros avec succès.

Un envoi vers +15005550006 peut tester votre gestionnaire de succès. Utilisez +15005550002 pour vérifier le chemin séparé de non-livraison. Le guide de migration SMS inclut une séquence de smoke test.

Que coûte ou modifie un test ?

Les envois simulés consomment des quotas réels et peuvent affecter vos statistiques.

Un SMS vers un numéro magique est facturé au tarif normal de la destination. Limitez les tests répétés, car chaque envoi simulé peut entraîner des frais.

Un destinataire e-mail simulé est décompté de votre quota d'envoi. Le trafic sandbox e-mail entre aussi dans les statistiques agrégées, y compris les taux de rebond et de plainte. Séparez-le dans votre analyse pour que les échecs de test ne ressemblent pas à des problèmes de livraison client.

Comment identifier un résultat de test ?

Associez l'événement au destinataire de test ou à l'identifiant de message que vous avez enregistré lors de l'envoi.

Un e-mail simulé accepté renvoie 202 et des structures d'événements normales. Il n'y a pas d'indicateur de test dans le payload. L'acceptation seule ne permet donc pas d'identifier un test.

Utilisez un label de destinataire tel que bounce+signup-flow@messagebird.dev pour associer les événements e-mail à un cycle de test. Vous pouvez aussi consulter la chronologie ou les événements API du message e-mail sans exploiter de récepteur de webhooks.

Gardez une vérification de livraison réelle séparée lorsque vous devez vérifier le rendu ou la réception. Les destinations magiques ne testent pas ces parties du chemin de livraison.

En bref

  1. La destination détermine le résultat du test.

    Utilisez votre clé et vos endpoints API habituels. Les adresses et numéros reconnus déclenchent des résultats de livraison simulés.

  2. Limitez les tests aux destinations magiques connues.

    Une requête peut mélanger destinataires simulés et réels. Les adresses non reconnues sont traitées comme des destinataires normaux.

  3. Les tests consomment des quotas réels.

    Les destinataires e-mail simulés consomment le quota d'envoi. Les numéros magiques SMS sont facturés au tarif normal de la destination.

  4. Enregistrez quels messages appartiennent à un test.

    Les événements n'ont pas d'indicateur de test. Les labels e-mail restent dans les adresses de destinataires, ce qui vous permet d'identifier un cycle de test dans ses événements.

Développez sur le même réseau.

Une clé API de test est disponible immédiatement. La production est activée dès que vous ajoutez un moyen de paiement et vérifiez un expéditeur.

Votre prochaine idée.
Prête à se connecter.