FAQ API Email

Envoyez à une adresse sandbox telle que delivered@messagebird.dev. Le résultat dépend de l'adresse utilisée, pas de l'état de votre compte, ce qui vous permet de tester les envois, les webhooks et la suppression avant de vérifier un domaine. Des adresses comme bounce@ et complaint@ simulent ces résultats via notre pipeline réel. Installez un SDK et vous pouvez envoyer à l'une d'elles en environ cinq minutes.

Pas immédiatement. Les adresses sandbox fonctionnent dès que vous disposez d'une clé API. Pour atteindre un vrai destinataire, un domaine vérifié est nécessaire : ajoutez les enregistrements DNS que nous vous fournissons, et vous pouvez enregistrer un domaine d'envoi sur le plan gratuit, dix sur Startup, et mille sur Growth.

Envoi transactionnel et marketing, templates, domaines d'envoi avec DKIM/SPF/DMARC, IP dédiées et pools, suppressions, réception, webhooks et analyses de délivrabilité, le tout sur une seule API. Les SDK couvrent TypeScript, Python, Go, PHP, Kotlin et Swift, chacun documenté selon les mêmes structures que l'API REST. Il y a aussi un CLI, installable avec brew install messagebird/tap/bird, ainsi qu'un serveur MCP hébergé si vous connectez un agent plutôt qu'une application.

Le plan gratuit vous offre 1 000 e-mails par mois sans frais et sans carte bancaire. Les plans payants commencent à 15 $ pour 50 000 e-mails, et le tarif unitaire diminue à mesure que vous montez en volume. Si vous dépassez ce que couvre votre plan, le surplus est facturé pour 1 000 e-mails à un tarif qui baisse avec votre niveau : 0,90 $ pour 1 000 sur Startup et au bas de Growth, jusqu'à 0,50 $ pour 1 000 à 2,5 M par mois. Un contrat Enterprise peut supprimer entièrement ce plafond.

Rétrograder ne casse rien : les identifiants que vous avez déjà réservés continuent de fonctionner, vous ne pouvez simplement pas en réserver de nouveaux tant que vous n'êtes pas repassé sous le quota autorisé. Une boîte mail sur votre propre domaine est comptabilisée dans votre quota global de boîtes mail comme n'importe quelle autre, et sa partie locale n'affecte jamais le quota d'identifiants personnalisés.

24,95 $ par mois par IP dédiée avec le plan Growth, jusqu'à cinq. Aucuns frais d'installation ni engagement annuel.

Les envois unitaires et les envois par lots ont des limites distinctes, et ces limites comptent les requêtes plutôt que les destinataires — c'est ce qui fait du batching le levier de volume. Une clé gratuite permet 10 envois unitaires et 5 appels batch par minute, et les plans payants augmentent les deux. Ne codez pas ces chiffres en dur : chaque réponse contient un en-tête RateLimit IETF indiquant ce qu'il vous reste et quand la fenêtre se réinitialise — calibrez-vous dessus plutôt que d'attendre un 429. Un appel batch peut contenir jusqu'à 100 messages, et chaque message accepte jusqu'à 50 adresses dans chacun des champs to, cc et bcc.

20 Mo sur tous les plans, mesurés sur le message généré : le HTML, la partie texte et chaque pièce jointe après encodage base64. Maintenez vos pièces jointes brutes à 15 Mo ou moins pour laisser de la marge. Les destinataires fixent aussi leurs propres limites, donc un message proche du plafond peut être accepté par nous et quand même rebondir à l'arrivée. Nous conservons les données des messages pendant 30 jours ; récupérez tout ce dont vous avez besoin au-delà via l'API d'analyse ou les webhooks dans votre propre stockage.

Des clés à portée limitée, des écritures auditées et des suppressions par catégorie : un envoi marketing ne peut pas atteindre un destinataire supprimé. Les flux entrants excessifs sont aussi contenus, car un e-mail bloqué ne déclenche aucun webhook.

Oui, les deux passent par la même API d'envoi. La seule différence est le champ category, qui détermine l'application des suppressions et des désinscriptions. Choisissez transactional pour les réinitialisations de mot de passe et les reçus, et marketing pour les campagnes.

Envoyez un en-tête Idempotency-Key avec chaque envoi logique. Si la première requête a réussi mais que vous n'avez jamais reçu la réponse, la rejouer avec la même clé vous renvoie le résultat original avec un en-tête Idempotency-Replay, au lieu d'envoyer l'e-mail deux fois.

Définissez scheduled_at sur un horaire entre 30 secondes et 30 jours dans le futur. L'envoi est immédiatement accepté et reste planifié jusqu'à son expédition, vous pouvez donc l'annuler à tout moment avant.

Oui, en base64 dans le tableau attachments. Pour afficher une image en ligne, attribuez-lui un content_id et référencez-le dans votre HTML avec cid:. Maintenez les fichiers bruts à 15 Mo maximum afin que le message respecte la limite de 20 Mo une fois encodé, et notez que les types de contenu exécutables et de script sont refusés avant l'envoi.

Non. Travaillez entièrement via l'API : envoyez votre HTML avec les variables écrites en ligne et publiez-le, puis référencez le template par id ou slug lors de l'envoi. Nous détectons automatiquement les variables, il n'y a donc pas de liste séparée à déclarer. React Email fonctionne aussi : rendez vos composants en HTML et stockez le résultat comme corps du message, en laissant chaque variable en texte littéral dans le JSX afin qu'elle survive au rendu et soit remplie lors de l'envoi. Il n'y a pas de génération par IA ni d'éditeur glisser-déposer aujourd'hui.

Vous le référencez par id ou slug, vous n'envoyez donc que les valeurs propres à chaque destinataire au lieu du corps entier à chaque fois, et la mise en page est centralisée au lieu d'être reconstruite dans votre code à chaque appel. Les templates sont versionnés, et la personnalisation est rendue de notre côté : conditions, boucles sur des tableaux et valeurs par défaut par champ sont tous résolus par destinataire, de sorte qu'un bloc d'adhésion peut s'afficher uniquement pour les membres. L'envoi utilise l'appel d'envoi classique, avec template défini sur l'id ou le slug et les valeurs dans template.parameters.

Oui. La publication fige une version immuable et numérotée, et les modifications se font toujours sur le brouillon — rien ne change en production tant que vous ne publiez pas. Restaurez n'importe quelle version publiée antérieure pour qu'elle redevienne celle utilisée pour les envois, sans créer de nouvelle version. La restauration réinitialise également le brouillon avec le contenu de cette version, de sorte que les modifications ultérieures partent de là.

Globaux. Un contact est unique par e-mail, et les audiences ne font que le référencer. Déplacer un contact entre audiences transfère automatiquement ses attributs, car ils résident sur le contact, pas sur la liste. Les champs personnalisés vivent dans le registre de propriétés, un schéma fermé et typé que vous définissez en amont : déclarez le type de chaque champ (string, number, boolean ou datetime) avec une valeur par défaut optionnelle, et nous rejetons les clés inconnues ou les valeurs au type incorrect lors de l'écriture, pour que vos données restent propres.

Déposez un fichier CSV ou Excel dans le tableau de bord et Bird identifie automatiquement quelle colonne correspond à quoi, jusqu'à 50 000 contacts à la fois. Ou effectuez un upsert par lot de jusqu'à 1 000 contacts en un seul appel et associez-les à une audience dans la même requête, sans étape d'ajout distincte. Dans les deux cas, l'upsert est idempotent sur les identifiants de chaque entrée : relancer un import met à jour au lieu de créer des doublons. Un broadcast cible une seule audience : créez-la et maintenez-la ici, puis référencez-la par ID lors de l'envoi.

Associez-le à une seule audience. L'audience est le seul concept de ciblage : vous n'empilez pas des listes et des segments par-dessus.

Oui aux deux. Envoyez immédiatement, ou programmez-le avec un horodatage explicite de 30 secondes à 30 jours à l'avance. Une fois programmé ou déjà en cours d'envoi, vous pouvez l'annuler : un broadcast peut passer à l'état annulé depuis n'importe quel état non terminal.

La même. L'e-mail marketing et l'e-mail transactionnel partagent une seule API, un seul jeu de clés et une seule interface d'analyse. Les broadcasts ajoutent le cycle de vie des campagnes par-dessus l'infrastructure d'envoi que vous utilisez déjà. C'est à vous de décider comment séparer leurs réputations d'envoi.

Chaque envoi est authentifié avec DKIM, SPF et DMARC, vos IP sont préchauffées automatiquement, et les rebonds et plaintes entraînent une suppression automatique pour qu'une mauvaise adresse ne nuise jamais deux fois à votre réputation. La surveillance des listes de blocage signale un problème tant que vous pouvez encore agir. Les désinscriptions et plaintes suppriment aussi le destinataire automatiquement et de manière réversible, le List-Unsubscribe en un clic est intégré, et un broadcast applique vos suppressions marketing avant l'envoi.

Livraisons, ouvertures, clics, rebonds et plaintes ventilés par campagne, tag et fournisseur de messagerie, avec les ouvertures prérécupérées filtrées. Tout ce qui figure dans le tableau de bord est aussi disponible via l'API de statistiques.

Nous générons les enregistrements pour vous : un enregistrement TXT DKIM pour signer vos e-mails, un CNAME return-path qui aligne SPF (aucun enregistrement SPF apex requis), et un enregistrement TXT DMARC. Un CNAME de suivi pour les liens d'ouverture et de clic brandés est optionnel. Ajoutez le domaine, collez les enregistrements chez votre fournisseur DNS, puis cliquez sur vérifier : la plupart des vérifications aboutissent en quelques minutes après la propagation DNS, bien que cela puisse parfois prendre plus longtemps.

DMARC indique aux serveurs de réception quoi faire avec les e-mails qui échouent à l'alignement DKIM ou SPF, et où envoyer les rapports agrégés montrant qui envoie en tant que votre domaine. Nous exigeons un enregistrement DMARC avant qu'un domaine puisse envoyer, et recommandons de commencer avec p=none, qui surveille sans affecter la livraison. Une fois que vous avez confirmé que toutes les sources légitimes sont alignées, renforcez la politique vers p=quarantine ou p=reject. Si vous publiez déjà DMARC sur votre domaine ou un domaine parent, nous l'utilisons tel quel. Les principaux fournisseurs de messagerie attendent désormais des expéditeurs en masse qu'ils publient une politique, donc en avoir une fait de plus en plus partie des conditions pour atteindre la boîte de réception à grande échelle.

Oui aux deux, et nous recommandons un sous-domaine dédié, car il isole la réputation de vos e-mails de votre messagerie d'entreprise. Vous pouvez également utiliser des domaines séparés pour les e-mails transactionnels et marketing, ou un par marque, chacun avec sa propre authentification et réputation.

Dès que vous envoyez régulièrement un volume élevé, environ 100 000 e-mails par mois ou plus. En dessous, un pool partagé offre une meilleure délivrabilité car la réputation est mutualisée, et une IP dédiée n'est avantageuse que si vous envoyez suffisamment pour la maintenir chaude. Vous n'avez pas à la préchauffer vous-même : nous préchauffons automatiquement une nouvelle IP dédiée sur environ 30 jours, en augmentant progressivement le volume pour que les fournisseurs de messagerie établissent la confiance graduellement, avec un débordement sur le pool partagé pour que vous ne perdiez jamais de volume.

Oui. Regroupez les IP en pools et dirigez chaque type de trafic vers son propre pool, de sorte qu'un envoi marketing ne puisse pas affecter la réputation qui porte vos réinitialisations de mot de passe.

La délivrabilité désigne la capacité de votre e-mail à atteindre réellement la boîte de réception du destinataire plutôt que le dossier spam ou un rejet définitif. Elle dépend de l'authentification, de la réputation de l'expéditeur, de l'hygiène de la liste et de l'engagement, et nous gérons ou mettons en lumière chacun de ces aspects pour vous.

Nous surveillons les principales listes de blocage pour vous. L'API de statistiques et le tableau de bord exposent également les codes de rebond, les types de plainte et les ventilations par fournisseur de messagerie, afin que vous puissiez détecter une tendance à la baisse rapidement.

Un rebond définitif, une plainte pour spam ou un désabonnement place l'adresse sur votre liste de suppression, et plus rien de ce que vous envoyez ne lui parvient. C'est ce qui empêche une seule mauvaise adresse de nuire à votre réputation à chaque envoi suivant. La suppression n'est pas permanente : vous pouvez retirer une adresse de la liste vous-même une fois que vous savez qu'elle est redevenue valide.

Les hard bounces, les plaintes pour spam et les désinscriptions sont automatiquement supprimés : dès qu'un destinataire déclenche l'un de ces événements, nous l'ajoutons à votre liste de suppression et l'ignorons lors des envois futurs. Les hard bounces et toute adresse que vous supprimez manuellement bloquent tous les envois, mais les plaintes et désinscriptions ne s'appliquent qu'aux e-mails marketing, de sorte qu'un message transactionnel comme une réinitialisation de mot de passe parvient toujours à quelqu'un qui s'est désabonné de vos campagnes.

Oui, pour les trois. La suppression est réversible, donc si une adresse redevient valide, retirez-la de la liste via le tableau de bord ou l'API et reprenez les envois. Vous pouvez également ajouter des adresses vous-même, par exemple une liste d'adresses connues comme invalides que vous importez, et elles sont ignorées comme une entrée automatique. Pour tester le comportement sans utiliser une adresse réelle, envoyez à l'adresse sandbox suppressed@messagebird.dev : elle se comporte exactement comme si le destinataire était supprimé, rejetée avec recipient_suppressed, mais rien n'est écrit dans votre liste, vous pouvez donc la réutiliser indéfiniment.

Nous suivons la livraison, les ouvertures, les clics, les rebonds, les plaintes et les désabonnements, résumés sous forme de KPI et ventilés par domaine, FAI, IP, domaine d'envoi, domaine destinataire, tag et broadcast, avec le détail des codes de rebond et des types de plainte. Les ventilations par fournisseur de messagerie et client montrent également comment Gmail, Yahoo, Outlook, Apple Mail et d'autres livrent, ouvrent et font rebondir vos messages.

Oui. Tout ce que le tableau de bord affiche est disponible via l'API de statistiques, avec une granularité quotidienne ou horaire, pour que vous puissiez alimenter des rapports ou diffuser les métriques dans vos propres outils. Les événements d'engagement et de livraison arrivent également en quasi temps réel via des webhooks et sont agrégés dans les endpoints de statistiques, de sorte que les tableaux de bord et les requêtes reflètent ce qui vient de se passer, pas la veille.

Une vraie boîte de réception adressable que votre code possède. Les e-mails envoyés à cette adresse arrivent dans des fils de discussion que votre agent peut lire, filtrer, auxquels il peut répondre, et depuis lesquels il peut envoyer via l'API — sans faire tourner un serveur IMAP ni parser du MIME brut. Le parsing entrant simple ne vous livre que des messages bruts. Une boîte aux lettres ajoute la couche conversationnelle : une adresse revendiquée, des fils avec des labels, du texte sans citations, et des réponses qui s'intègrent au fil.

Oui. Une boîte aux lettres peut être sur le domaine partagé inbox.ai ou sur votre propre domaine, une fois le transfert entrant configuré. Toute partie locale qui n'est pas en quarantaine de 30 jours après suppression est disponible. Un identifiant généré est composé de 20 caractères aléatoires, toujours disponible et gratuit. Un identifiant personnalisé est un nom que vous choisissez (goldcrest@inbox.ai), attribué selon le principe du premier arrivé, premier servi entre toutes les organisations, et il est décompté de l'allocation de votre plan.

Si vous avez seulement besoin d'analyser un e-mail pour le transmettre à un webhook, le traitement entrant simple suffit. Une boîte aux lettres prend tout son sens quand l'agent doit maintenir une conversation. Pour commencer, créez une clé API dans le tableau de bord, revendiquez une adresse et répondez à votre premier fil — le tout en quelques minutes. La documentation couvre l'ensemble du processus, et le serveur MCP hébergé donne à un agent les mêmes outils sans code HTTP intermédiaire.

Les deux sont des MTA sur site que vous gérez vous-même au lieu d'envoyer via notre API managée. Momentum MTA est conçu autour de workflows et de routage personnalisables pour l'envoi en grand volume. PowerMTA est conçu pour fonctionner sur vos propres serveurs ou n'importe quel cloud public, comme AWS ou Azure.

Aux équipes ayant des exigences d'infrastructure ou de conformité nécessitant la gestion de leur propre MTA, et aux équipes souhaitant une visibilité indépendante sur le placement en boîte de réception et le benchmarking concurrentiel plutôt que de se fier uniquement à leurs propres métriques d'envoi. Le premier groupe utilise Momentum MTA ou PowerMTA. Le second groupe utilise Inbox Tracker, qui mesure le placement en boîte de réception et la réputation à partir de données réelles de boîtes aux lettres, ou Competitive Tracker, qui compare votre programme à d'autres marques, et aucun des deux ne nécessite d'auto-hébergement.

SparkPost est désormais Bird Email. Nous avons acquis SparkPost en 2021 pour intégrer le moteur de délivrabilité derrière environ 40 % des e-mails commerciaux mondiaux à une plateforme unique pour l'e-mail, le SMS, WhatsApp et la voix. Les clients SparkPost existants conservent leur service et ne sont pas tenus de migrer. Les nouveaux projets s'appuient sur l'API Bird Email, qui repose sur le même moteur de délivrabilité et ajoute SMS, WhatsApp et voix sur un seul jeu de clés.

Le moteur de délivrabilité est le même que celui de SparkPost, mais l'interface est une API e-mail moderne avec des SDK pour chaque runtime majeur. Sa documentation couvre l'envoi, les templates, les domaines d'envoi et les webhooks.

Momentum est notre plateforme d'infrastructure e-mail on-premise pour l'envoi à haut volume, avec des workflows personnalisables, un routage et des paramètres de livraison configurés via son Policy Manager. Il est conçu pour évoluer avec votre volume d'envoi tout en maintenant des performances stables, et il prend en charge l'Unicode complet (SMTPUTF8) pour envoyer vers des jeux de caractères internationaux.

Adaptive Delivery est le façonnage automatique du trafic de Momentum. Il observe comment chaque fournisseur de messagerie réagit à vos e-mails et s'ajuste en temps réel : limitation, report ou pause temporaire d'un flux pour protéger votre réputation, puis montée en charge une fois la situation rétablie. Vous atteignez la boîte de réception sans surveiller manuellement les débits d'envoi pour chaque fournisseur. L'Intelligence Router vous montre ces ajustements en temps réel sur toutes vos sources de données, avec des alertes à chaque modification.

Oui aux deux. Momentum fonctionne sur vos propres serveurs, sur n'importe quel cloud majeur, ou en combinant les deux, afin de s'adapter à votre infrastructure, vos coûts et vos exigences de conformité — et vous pouvez faire évoluer cette répartition au fil du temps. Il continue aussi d'évoluer : les versions récentes le maintiennent à jour avec les systèmes d'exploitation modernes, TLS 1.3, et les standards de sécurité et SMTP actuels, et exposent les événements de messages via des API en temps réel que vous pouvez intégrer à vos propres outils de reporting et d'automatisation.

Oui. PowerMTA peut relayer une partie du trafic vers l'API Bird Email hébergée tout en livrant le reste directement depuis vos propres serveurs — c'est le moyen le plus simple de tester la plateforme hébergée ou de migrer progressivement sans tout déplacer d'un coup. PowerMTA lui-même fonctionne sur une infrastructure que vous possédez, donc ces IP restent sous votre gestion. Le trafic relayé vers la plateforme hébergée peut utiliser nos IP ou vos propres IP dédiées, tandis que tout le reste reste entièrement sous votre contrôle.

Les MTA virtuels vous permettent d'exécuter plusieurs flux d'envoi indépendants au sein d'une même instance PowerMTA, chacun avec ses propres IP, sa réputation et ses limites. Utilisez-les pour séparer proprement l'e-mail transactionnel du marketing, ou différents clients, afin que les problèmes d'un flux n'affectent jamais un autre.

La délivrabilité désigne la capacité de votre e-mail à atteindre la boîte de réception plutôt que le dossier spam ou un rejet. Inbox Tracker la mesure par fournisseur de messagerie, en temps réel, et vous fournit un bilan quotidien indiquant où votre courrier a réellement atterri : boîte de réception, spam ou bloqué.

Inbox Tracker signale une baisse du placement chez un fournisseur pendant qu'elle se produit, ce qui vous permet de la voir dans un bilan quotidien plutôt que dans une chute des réponses des semaines plus tard. Il signale aussi les pièges à spam (spam traps), qui indiquent généralement un problème de liste à corriger avant qu'il ne dégrade votre réputation, et vous alerte lorsque l'authentification DMARC commence à échouer.

Trois sources : des données de boîtes aux lettres sous licence montrant où vos e-mails atterrissent pour de vrais destinataires, des comptes de test (seeds) qui vérifient le placement dans des scénarios spécifiques, et une connexion directe à Google Postmaster pour la vision propre de Gmail sur votre réputation. Elles répondent à des questions différentes : les données réelles de boîtes aux lettres vous montrent le résultat, Postmaster vous donne le raisonnement de Gmail, et les seeds vous permettent de tester un scénario volontairement. Une seule source laisse des angles morts et génère de fausses alertes.

Nous suivons des millions d'e-mails par jour pour plus de 250 000 marques dans plus de 100 secteurs. Ces données sont actualisées en continu, de sorte que les informations que vous consultez reflètent les campagnes et tendances actuelles, pas un instantané historique.

Vous pouvez comparer la taille de l'audience, la fréquence des campagnes, les stratégies de messagerie, les métriques de performance et les taux d'engagement par rapport à d'autres marques de votre secteur, jusqu'aux parcours e-mail individuels d'un concurrent. Cette même vue est utile pour la planification saisonnière : observez comment vos concurrents ajustent leurs campagnes avant une saison et identifiez les stratégies qui fonctionnent avant de vous engager dans les vôtres.

Souvent, oui. Le Competitive Tracker peut révéler la plateforme ou le service d'envoi derrière l'e-mail d'un concurrent, ce qui est utile pour la veille concurrentielle et pour les équipes commerciales qui évaluent comment les rivaux d'un prospect gèrent leurs programmes.

Les fournisseurs considèrent cela comme de la collecte d'adresses et vous imposeront des limites de débit ou vous mettront en liste de blocage. De plus, les résultats ne sont pas fiables : un serveur peut accepter une adresse lors du handshake sans pour autant la délivrer, et le greylisting fait apparaître des adresses valides comme invalides. Vérifier par rapport à l'historique de livraison évite à la fois le risque et les faux résultats.

Pour Neutral, c'est à vous de décider : l'adresse est bien formée, dispose d'un serveur de messagerie réel et n'a jamais généré de hard bounce, mais nous n'avons pas encore constaté d'événement de livraison ou d'engagement pour elle, donc elle présente un risque faible plutôt qu'un motif de suspicion. Envoyez-y un message si vous privilégiez la croissance, ou attendez d'observer un engagement si vous préférez jouer la prudence. Pour Typo, affichez la correction suggérée sur le formulaire d'inscription afin que la personne puisse la corriger avant de soumettre, ce qui récupère un prospect qui aurait autrement rebondi ; dans une liste par lots, isolez les erreurs de frappe et confirmez-les ou supprimez-les, mais n'envoyez pas à l'adresse mal orthographiée.

Oui. L'API fonctionne exclusivement en HTTPS. Si vous soumettez via SMTP à la place, le port 465 est chiffré dès le premier octet, et les ports 587 et 2525 passent en chiffrement avec STARTTLS : nous refusons AUTH sur ces ports tant que la mise à niveau n'est pas terminée, de sorte que les identifiants ne circulent jamais en clair. Le port 25 n'est pas proposé pour la soumission. Vos données restent dans la région où votre organisation est hébergée, soit us1 soit eu1, et le préfixe de votre clé API (bk_us1_…, bk_eu1_…) encode cette région afin que les SDK et la CLI sélectionnent automatiquement le bon endpoint. Seules l'authentification et l'administration des comptes fonctionnent sur un hôte indépendant de la région.

Uniquement ce que vous lui autorisez. Une clé comporte une liste de scopes tels que emails, email_marketing ou domains, chacun en lecture ou en écriture, de sorte qu'une clé qui envoie des e-mails ne peut pas gérer vos domaines d'envoi. Les actions du plan de contrôle (membres, paramètres de l'espace de travail, émission de clés, pools d'IP) sont accessibles uniquement depuis le tableau de bord, et aucune clé ne peut y accéder. Chaque clé accepte également une liste blanche de plages CIDR, et les requêtes provenant de toute autre adresse sont rejetées.

La rotation génère la nouvelle clé et laisse l'ancienne fonctionner pendant une période de grâce, 24 heures par défaut, afin que vous puissiez la déployer progressivement. Passez zéro pour révoquer l'ancienne clé immédiatement. La rotation ne prolonge jamais la durée de vie d'une clé : une clé dont l'expiration est plus proche que la période de grâce conserve sa date d'expiration initiale.

Oui, via SAML 2.0 ou OIDC, donc Okta, Microsoft Entra ID et Google Workspace fonctionnent tous. La configuration se fait par organisation : votre équipe de compte l'active pour vous. Les membres qui se connectent avec un mot de passe peuvent activer eux-mêmes le MFA.

Oui. Le journal d'audit est un enregistrement en lecture seule, à l'échelle de l'organisation, de chaque action de gestion, avec l'acteur, l'espace de travail, l'heure et le résultat, et il s'exporte au format OCSF pour votre propre SIEM. Il couvre les modifications de configuration et non les messages que vous envoyez. Ceux-ci figurent dans le journal des e-mails.

Les certifications et la documentation de sécurité sont disponibles dans le Trust Center à l'adresse trust.bird.com. L'accord de traitement des données, la déclaration de confidentialité et la politique d'utilisation acceptable sont publiés sur bird.com/legal, avec les versions actuelles et une archive des versions antérieures. Pour un questionnaire fournisseur, votre équipe de compte s'en charge.