Présentation de l’API REST TrekMail pour développeurs

L’API TrekMail vous permet de gérer les domaines, boîtes mail, transferts, DNS, migrations d’e-mails et opérations de webmail depuis un client HTTP ou un agent d’IA. Cela comprend la lecture et l’envoi des e-mails, les brouillons, la planification, les dossiers, les contacts, les calendriers, les identités, les modèles et les expéditeurs bloqués. Les requêtes authentifiées utilisent un jeton bearer, les réponses sont au format JSON et l’activité de l’API est auditée.

Fonctionnalités disponibles

• API REST v1 avec un format de requête et de réponse JSON.
• Authentification par jeton bearer : aucun cookie ni aucune session pour les appels API authentifiés.
• Clés d’idempotence sur les opérations d’écriture qui les exigent, afin d’éviter les tâches en double lors des nouvelles tentatives.
• Limitation du débit par jeton avec des en-têtes Retry-After.
• Journal d’audit visible dans votre tableau de bord sous AI Agents & API → Audit Log.
• Serveur MCP avec un catalogue filtré selon les identifiants, le transport et les paramètres de sécurité de la connexion actuelle. Une connexion limitée à un projet ne voit donc que les outils qu’elle peut utiliser.
• Alias de domaine : reliez des adresses en réception uniquement d’un domaine secondaire aux mêmes parties locales d’un domaine principal, avec des états de livraison enregistrés et actifs ainsi qu’une suppression sûre. Consultez Alias de domaine via API et MCP.
• Architecture à deux jetons : séparez les jetons d’opérations pour l’infrastructure des jetons de messages pour les opérations complètes d’e-mail, comme la lecture, l’envoi, les brouillons, la planification, les contacts, les calendriers, les identités, les modèles et les dossiers.
• Informations sur la délivrabilité sortante et les rebonds : récupérez dans le tableau de bord les totaux d’e-mails envoyés, livrés, en rebond définitif et en rebond temporaire, ainsi que les codes et réponses SMTP par destinataire. Consultez Délivrabilité et rebonds.
• Utilisation du stockage des boîtes mail : list_mailboxes et get_mailbox renvoient used_mb, quota_mb, allocation_mb et is_pooled, afin qu’un agent détecte les boîtes proches de leur limite sans accéder au tableau de bord.
• Administration White Label : inspectez la configuration, gérez le branding par domaine, invitez des clients, contrôlez les rôles et les domaines, suspendez ou restaurez l’accès et consultez l’activité via API ou MCP. Consultez le guide du branding et le guide de gestion d’équipe.

API Drive et automatisation des fichiers

Drive fait partie de la surface API publique. Il couvre les espaces Drive du compte et des boîtes mail, l’utilisation, la navigation dans les dossiers, les téléversements, la gestion des fichiers et dossiers, la Corbeille, les actions groupées, les liens de partage publics, la gestion des mots de passe des appareils de synchronisation et l’état en lecture seule du module Drive Storage.

Drive utilise onze portées de jeton d’opérations : drive:account:read, drive:account:write, drive:account:share, drive:account:purge, drive:mailbox:read, drive:mailbox:write, drive:mailbox:share, drive:mailbox:purge, drive:addon:read, drive:devices:read et drive:devices:write. Les actions de facturation du module Drive, comme l’achat, le redimensionnement et l’annulation, restent réservées au tableau de bord et ne sont pas exposées comme opérations d’écriture API ou MCP.

Commencez par la Présentation de l’API Drive ou le Démarrage rapide de l’API Drive.

Architecture à deux jetons

L’API utilise deux types de jetons indépendants. Vous pouvez utiliser l’un ou les deux selon vos besoins :

Les jetons d’opérations et de messages ont des portées et des limites de débit distinctes. Un même agent peut utiliser les deux simultanément en les configurant dans l’environnement du serveur MCP.

Les jetons de messages sont disponibles avec les offres Pro et Agency.

Avant de commencer

• Toutes les offres disposent d’un accès à l’API :
  • Nano : Email Verifier. Ajoutez un module Drive Storage pour obtenir un accès complet à l’API et à MCP de Drive.
  • Starter : accès complet à Drive et Email Verifier, ainsi qu’un accès en lecture seule aux autres domaines d’infrastructure. Utilisez le tableau de bord pour leurs actions d’écriture.
  • Pro / Agency : accès complet à l’API de base, y compris les jetons de messages. Les portées White Label sont ajoutées pendant la période d’essai ou lorsque son module payant est actif.
• Vous connectez un agent d’IA ? Ajoutez https://trekmail.net/mcp comme serveur MCP distant dans tout client compatible. S’il prend en charge l’autorisation par navigateur, aucun jeton manuel n’est nécessaire. Consultez Connexion des agents d’IA (MCP) pour les options distantes, CLI/bureau, passerelle et auto-hébergées.
• Vous créez votre propre intégration ? Créez un jeton tm_live_ sous AI Agents & API → Tokens → Create token et envoyez-le comme Authorization: Bearer …. Consultez Création et gestion des jetons API.
• Vous débutez avec l’API ? Cliquez sur Start tour en haut de la page AI Agents & API pour suivre une courte présentation des méthodes de connexion, de la gestion des jetons, des applications connectées et du journal d’audit.

Fonctionnement de l’authentification

Chaque requête doit inclure votre jeton dans l’en-tête Authorization :

Authorization: Bearer tm_live_abc123...

Les jetons d’opérations commencent par tm_live_ et les jetons de messages par tm_msg_. Tous deux ne sont affichés qu’une fois lors de leur création et ne peuvent plus être consultés ensuite.

Si le jeton est absent, révoqué ou expiré, l’API renvoie 401 avec le code d’erreur unauthenticated.

URL de base et gestion des versions

Tous les endpoints se trouvent sous :

https://trekmail.net/api/v1

L’URL de base apparaît dans votre tableau de bord AI Agents & API, sous Quick Reference. La version se trouve dans le chemin de l’URL. Si une v2 est introduite un jour, la v1 continuera de fonctionner.

Format des réponses

Les réponses réussies renvoient du JSON avec une clé data pour les ressources uniques ou une liste paginée :

{
  "data": [
    { "id": 1, "domain": "example.com", "status": "active" }
  ],
  "links": { "next": "...", "prev": null },
  "meta": { "current_page": 1, "last_page": 1, "total": 1 }
}

Les réponses d’erreur suivent une structure cohérente :

{
  "error": {
    "code": "unauthenticated",
    "message": "Invalid or expired API token",
    "hint": "Check that your token is correct and has not been revoked.",
    "request_id": "req_abc123",
    "retryable": false
  }
}

Identifiants de requête

Chaque réponse contient un en-tête X-Request-Id. Vous pouvez aussi fournir le vôtre via X-Request-Id dans la requête. Il sera renvoyé à l’identique et consigné dans la piste d’audit.

Limites de débit

Chaque jeton est soumis à une limite par minute. Lorsque vous atteignez la limite, l’API renvoie 429 avec un en-tête Retry-After indiquant quand réessayer.

Les opérations destructrices (intentions de suppression) ont une limite quotidienne supplémentaire par jeton et un délai entre deux suppressions consécutives.

Les opérations d’écriture de migration (démarrage, annulation, nouvelle tentative) ont une limite dédiée de 10 requêtes par minute et par jeton, ainsi qu’une limite de concurrence à l’échelle du serveur qui renvoie 503 lorsque trop de migrations sont exécutées globalement.

Les jetons de messages utilisent des limites distinctes. Les valeurs par défaut sont de 30 requêtes de lecture par minute et par jeton, 60 requêtes d’envoi par minute et par jeton, 5,000 lectures réussies par jour et par jeton et 100 envois API par jour pour une boîte mail. Un second compteur de sécurité d’envoi est fixé par défaut à 500 par jeton et par jour; la limite inférieure de la boîte s’applique généralement d’abord. Ces protections API ne remplacent pas les limites SMTP gérées de votre offre ni celles d’un fournisseur externe.

Idempotence

Les endpoints qui modifient l’état et sont marqués comme idempotents exigent un en-tête Idempotency-Key. Cela couvre les créations, mises à jour, envois et suppressions pour lesquels une nouvelle tentative automatique pourrait dupliquer le travail. Les actions POST assimilables à une lecture, comme la détection d’un fournisseur ou le test d’une connexion, n’en exigent pas; consultez la table des endpoints ou la spécification OpenAPI. Si vous envoyez la même clé avec le même corps, l’API reproduit la réponse d’origine sans créer de doublons.

Idempotency-Key: create-mailbox-alice-2024

Si vous envoyez la même clé avec un corps différent, l’API renvoie 409 Conflict.

Allocation du stockage des boîtes mail

Chaque endpoint qui crée une boîte mail ou une invitation, POST /api/v1/mailboxes, /api/v1/mailboxes:bulk, /api/v1/mailboxes/invites, /api/v1/mailboxes/invites:bulk, accepte un entier facultatif storage_allocation_mb.

Les allocations sont validées par rapport au pool actif, moins les boîtes dédiées existantes et les invitations dédiées en attente. Les endpoints groupés valident également la somme des allocations du lot et rejettent l’ensemble du lot avec 422 storage_pool_exceeded s’il dépasse la capacité. Le pool est actualisé lorsqu’une boîte dédiée est supprimée, lorsqu’une invitation est utilisée (l’allocation passe à la nouvelle boîte) et lorsqu’une invitation en attente expire.

Pour les invitations, l’allocation est enregistrée sur le code d’accès et copiée vers la nouvelle boîte au moment de l’utilisation. Si le pool ne peut plus accueillir l’allocation demandée à ce moment-là (par exemple, un autre administrateur a augmenté son allocation dédiée entre-temps), l’utilisation rétrograde proprement la nouvelle boîte vers le stockage partagé au lieu d’échouer, et le destinataire voit un avis sur la page de réussite.

Accès Drive des boîtes mail

Chaque boîte mail possède un niveau drive_access qui détermine la quantité de Drive accessible dans le webmail à la personne qui l’utilise. Il est renvoyé dans la ressource de la boîte et peut être défini avec PATCH /api/v1/mailboxes/{id} ou, pour plusieurs boîtes à la fois, POST /api/v1/mailboxes:drive-access.

Le stockage est partagé dans tout le compte; ce réglage contrôle donc la quantité de ce pool qu’une personne peut remplir de fichiers.

Suspension de la connexion à une boîte mail

La connexion d’une boîte mail peut être suspendue tout en continuant à recevoir du courrier : le webmail, IMAP, SMTP et les mots de passe d’appareil sont refusés et les sessions ouvertes prennent fin, mais la livraison reste intacte. Aucun message ne rebondit et tous attendent le rétablissement de la connexion. Configurez-la avec POST /api/v1/mailboxes/{id}:suspend-login (et :resume-login), ou sur plusieurs boîtes avec POST /api/v1/mailboxes:login-access.

La ressource de boîte mail l’indique avec login_suspended, login_suspended_at et login_suspended_reason. Consultez login_suspended pour savoir si la personne peut se connecter et status pour savoir si la boîte elle-même fonctionne. Une boîte suspendue reste active, car elle continue d’accepter le courrier. :pause a un autre effet : il définit status sur disabled et interrompt également la livraison.

Consultez Suspension de la connexion à une boîte mail via API.

L’endpoint groupé accepte exactement un sélecteur, mailbox_ids, domain_id ou all, et renvoie ce qu’il a fait :

{ "data": { "drive_access": "attachments_only", "matched": 24, "updated": 21, "skipped_shared": 3 } }

domain_id est le sélecteur à utiliser lorsqu’un domaine correspond à un client. Les boîtes qui ont déjà le niveau demandé sont comptées comme matched, mais pas comme updated; l’appel peut donc être répété sans risque.

Les boîtes partagées sont refusées sur l’endpoint individuel avec 422 drive_access_not_applicable et ignorées (tout en étant comptées) par l’endpoint groupé : elles n’ont pas leur propre utilisateur de webmail, leurs membres les ouvrent donc avec leur propre niveau et une valeur stockée sur la ligne partagée ne changerait rien.

La restriction s’applique à l’API comme à l’interface. L’espace Drive d’une boîte restreinte est absent de GET /api/v1/drive/spaces, ses fichiers répondent 404 lorsqu’ils sont demandés par id et aucun appareil de synchronisation ne peut être créé pour elle.

Adresses de transfert

GET /api/v1/domains/{id}/forwarding-addresses renvoie plus que la liste, car deux caractéristiques d’une adresse de transfert ne sont pas visibles dans l’adresse elle-même :

{
  "data": [ { "id": 8, "address": "sales@acme.com", "local_part": "sales",
              "domain_id": 4, "recipients": ["team@example.net"], "is_active": true } ],
  "limits": { "used": 1, "max": 100, "recipients_per_address": 15 },
  "delivery": { "active": true, "requires_plan": "pro",
                "paused_until": null, "paused_reason": null }
}

• limits.max s’applique par domaine et dépend de l’offre : 100 avec Pro, 300 avec Agency et 25 enregistrées mais inactives avec Nano ou Starter.
• delivery.active indique si ces règles acheminent du courrier en ce moment. Il vaut false avec une offre inférieure à requires_plan et false tant que paused_until est défini (le compte a dépassé son débit d’envoi horaire; consultez Limites d’envoi par offre). Une règle peut avoir is_active: true sans livrer de message; consultez donc delivery, et pas seulement is_active, avant d’indiquer que le transfert fonctionne.

La création est autorisée avec une offre qui ne peut pas livrer et renvoie 201 : la règle est enregistrée et commence à fonctionner après la mise à niveau. Cela correspond au tableau de bord, qui présente ces règles comme enregistrées et inactives.

Les refus sont renvoyés avec 422 et error.code défini sur validation_error ou limit_exceeded : adresse déjà utilisée sur le domaine, destinataire sur le même domaine (ce qui créerait une boucle), domaine destinataire sans MX fonctionnel ou quota par domaine épuisé.

Les opérations POST et DELETE sur ces endpoints exigent une Idempotency-Key; PATCH ne l’exige pas.

Historique de livraison

GET /api/v1/domains/{id}/forwarding-addresses/{addressId}/log renvoie ce qui est réellement arrivé aux messages récents, du plus récent au plus ancien :

{
  "data": [
    { "id": 91, "occurred_at": "2026-07-27T09:12:04+00:00", "outcome": "delivered",
      "from": "rfq@northgatesupply.com", "to": "sales@example.net",
      "smtp_code": "2.0.0", "smtp_response": "250 2.0.0 OK" }
  ],
  "address": "sales@acme.com",
  "window": { "retention_days": 30, "max_events": 200 }
}

outcome peut être delivered, deferred (échec temporaire, nouvelle tentative en cours), failed (le serveur du destinataire l’a refusé) ou blocked. Ce dernier signifie que notre filtre antispam a arrêté le message avant le transfert, il n’a donc jamais atteint le destinataire. Traiter blocked comme un rebond conduirait à chercher sur le serveur destinataire un problème survenu chez nous.

limit (1-200, valeur par défaut 100) est le seul paramètre. La fenêtre correspond à la conservation de l’offre : 30 jours avec Agency, 7 ailleurs. Aucun événement plus ancien ne peut être demandé, car les événements transférés sont supprimés.

Boîtes mail partagées (d’équipe)

Une boîte mail partagée est une boîte d’équipe comme support@ ou sales@, que les membres ouvrent via leur propre compte de boîte normal dans le Webmail et, lorsque l’accès natif est activé, comme dossier IMAP délégué. Il n’existe aucun mot de passe partagé ni connexion distincte. L’accès est uniforme : chaque membre peut lire et un indicateur can_send unique détermine s’il peut répondre avec l’adresse (true) ou dispose d’un accès en lecture seule (false). Il n’existe aucun rôle de membre.

GET /api/v1/mailboxes et GET /api/v1/mailboxes/{id} renvoient désormais mailbox_type ("user" ou "shared") ainsi qu’un booléen is_shared; les boîtes partagées incluent également shared_member_count. Utilisez ces champs pour distinguer une boîte d’équipe d’une boîte normale avant d’appeler les endpoints de membres.

Les endpoints de membres réutilisent vos portées mailboxes:read / mailboxes:write existantes. Il n’existe pas de portée distincte pour les boîtes partagées.

Pour découvrir l’accès natif des applications de messagerie, appelez GET /api/v1/mailboxes/{member_mailbox_id}/client-setup pour une boîte normale de membre. Son objet shared_mailboxes indique la disponibilité native durable, l’état et la raison effectifs de Send As, les chemins exacts Inbox/Sent/Archive/Junk et les opérations autorisées. can_send est l’autorisation Can reply attribuée, et non la preuve que SMTP est actuellement prêt. L’endpoint ne renvoie jamais de mot de passe. Un appel avec l’id de la boîte partagée renvoie 422 direct_login_unavailable, car l’adresse partagée ne peut pas s’authentifier directement.

La suppression d’un membre, la modification de can_send ou la reconversion d’une boîte partagée en boîte normale synchronise les autorisations du serveur de messagerie lorsque l’accès natif est activé. Une réponse 503 native_access_sync_failed peut être retentée et garantit que l’appartenance, l’autorisation ou le type de boîte est resté inchangé, plutôt que d’appliquer partiellement l’opération.

Endpoints disponibles

Drive dispose de sa propre référence et n’est pas répété ici; consultez la Présentation de l’API Drive. Les endpoints SMTP au niveau du compte conservés pour la rétrocompatibilité sont décrits sous Routage SMTP par domaine, au lieu d’être présentés comme actuels.

Les endpoints Cloudflare suivent le même processus que le tableau de bord : valider un jeton, répertorier les zones, connecter les domaines, prévisualiser les modifications DNS, puis les appliquer. /cloudflare/preview et /cloudflare/apply acceptent tous deux deux contrôles facultatifs par domaine :

• included_records, une liste d’autorisation des enregistrements à modifier, indexée par ID de domaine : { "123": ["mx_primary", "spf_record"] }. Les enregistrements omis sont ignorés; vous pouvez donc n’appliquer que MX et SPF, puis revenir plus tard pour DKIM. Omettez ce champ pour appliquer chaque enregistrement.
• confirmed_conflicts, lorsque la prévisualisation signale un enregistrement existant avec une valeur différente, indiquez ici son ID d’enregistrement (même forme { domain_id: [record_ids] }) pour autoriser son remplacement.

Les ID d’enregistrement (mx_primary, spf_record, dkim_primary, dmarc_main, …) proviennent directement de la réponse de prévisualisation. Un agent appelle donc généralement la prévisualisation en premier, puis transmet à l’application les ID voulus :

POST /api/v1/cloudflare/apply
{
  "domain_ids": [123],
  "included_records": { "123": ["mx_primary", "spf_record"] },
  "confirmed_conflicts": { "123": ["dmarc_main"] }
}

Routage SMTP par domaine et valeur par défaut du compte

SMTP est configuré par domaine. Chaque domaine choisit l’une des trois routes : envoi géré par la plateforme, profil SMTP enregistré (votre propre fournisseur, réutilisable entre domaines) ou « non configuré ». Une valeur par défaut unique pour tout le compte détermine la route initiale des nouveaux domaines.

Endpoints par domaine (smtp:read / smtp:write) :

Quelques remarques sur le corps de la route :

• smtp_mode=platform sélectionne l’envoi géré; smtp_mode=profile exige smtp_connection_id; not_configured efface la route.
• smtp_mode=inherit fait que le domaine suit en direct la valeur par défaut du compte : lorsque celle-ci change, ce domaine change avec elle. L’interface web écrit toujours des routes concrètes, mais le backend prend encore en charge inherit; c’est pourquoi GET renvoie effective_smtp_mode, qui indique la valeur actuelle de inherit.
• set_account_default: true est l’équivalent API du commutateur Make this the account default du tableau de bord (les nouveaux domaines commencent sur cette route). apply_to_all: true correspond au bouton Apply to all domains (basculement ponctuel de tous les domaines vers cette route).

Endpoints de valeur par défaut du compte (smtp:read / smtp:write) :

La suppression d’un profil qui était la valeur par défaut du compte rétablit la valeur de base de l’offre.

Endpoints hérités. Les endpoints GET/PUT /api/v1/smtp au niveau du compte (ainsi que DELETE /api/v1/smtp/{id}, POST /api/v1/smtp:test, GET /api/v1/smtp:test-status/{jobId}) restent disponibles pour la rétrocompatibilité, mais ne contrôlent plus le routage par domaine : utilisez les endpoints par domaine et /smtp/default ci-dessus. Les anciens outils MCP get_smtp_config / update_smtp_config sont obsolètes pour la même raison.

Branding White Label, clients et accès d’équipe

Le branding est configuré par domaine avec branding:read / branding:write. Un domaine utilise son propre branding (mode=custom), hérite de la valeur par défaut du compte (mode=inherit) ou est désactivé. Une période d’essai White Label active ou un module payant est requis. Après l’annulation, le propriétaire conserve un accès de récupération en lecture seule pendant la période de grâce affichée. Lisez les dns_records du domaine et publiez exactement les enregistrements renvoyés. Ne déduisez pas les noms d’hôtes ou les cibles CNAME d’un exemple.

PATCH est une fusion partielle, les champs omis sont donc conservés. Si le branding est actuellement désactivé, passez mode pour le réactiver. Un sender_email personnalisé doit appartenir à un domaine doté d’une clé DKIM vérifiée. mail_zone_enabled fournit les applications de messagerie et la synchronisation DAV sous le propre domaine de la marque. Il appartient à la marque plutôt qu’à un seul domaine et exige donc mode=custom ou scope=account_default; un domaine inherit renvoie 422 inherited_brand. Lisez mail_zone.dns_status, mail_zone.client_hosts_status, mail_zone.records, mail_zone.dav_url et mail_zone.dav_ready pour suivre le provisionnement et n’utiliser qu’une adresse DAV prête. Pour le flux complet de l’agent, consultez le Guide de l’API et de MCP pour le branding White Label.

La surface White Label au niveau du compte ajoute 13 routes sous /api/v1/white-label : état et progression de la configuration, catalogue d’accès actif, liste et actions de cycle de vie des membres, activité du compte et historique des actions et connexions par membre. Elle utilise members:read, members:write et activity:read. L’accès est toujours l’intersection entre les droits du compte, l’adhésion actuelle de la personne, l’autorisation des identifiants et toute contrainte de domaine. Consultez Gestion des équipes White Label avec API et MCP pour la table des routes et les transitions d’état.

La spécification OpenAPI est disponible à l’adresse /api/openapi.json pour l’importer dans Postman, Insomnia ou des générateurs de code.

Solutions rapides

• 401 « unauthenticated » : vérifiez que l’en-tête Authorization: Bearer <token> est présent et que le jeton n’a pas été révoqué ou n’a pas expiré.
• 403 « plan_api_disabled » : la portée demandée n’est pas incluse dans votre offre. Nano couvre Email Verifier (et Drive si vous avez acheté le module Drive Storage). Passez à Starter ou à une offre supérieure pour le reste de l’API.
• 403 « token_scope_blocked_by_plan » : votre jeton possède des portées indisponibles avec votre offre actuelle. Révoquez-le et créez-en un nouveau avec les portées autorisées.
• 403 « scope_blocked_by_entitlement » : une autorisation White Label enregistrée est indisponible, car le module est inactif ou l’opération est une écriture pendant la période de grâce. Réactivez White Label, puis réémettez ou réautorisez les identifiants.
• 403 « scope_blocked_by_membership » : le rôle actuel du membre est plus restreint que l’action demandée. Demandez au propriétaire de le modifier; une simple réautorisation ne peut pas élargir l’adhésion.
• 422 « missing_idempotency_key » : ajoutez un en-tête Idempotency-Key à l’opération d’écriture indiquée dans la référence de l’endpoint.
• 403 « mailbox_sending_paused » : l’envoi depuis cette boîte a été arrêté, car son courrier sortant ne ressemblait plus à celui de son propriétaire, généralement parce qu’un mot de passe est tombé entre de mauvaises mains. La lecture, la liste et tous les autres endpoints fonctionnent encore; seul l’envoi est refusé et réessayer ne le réactivera pas. Le mot de passe de la boîte doit être modifié, puis l’assistance réactivera l’envoi. Consultez Pourquoi ne puis-je pas envoyer d’e-mail ?.
• 429 débit limité : attendez la durée indiquée dans l’en-tête Retry-After avant de réessayer.

Envoi d’e-mails : corps, en-têtes et délivrabilité

POST /api/v1/messages/send accepte la forme de requête {to, subject, body: {text, html}, attachments, reply_to_message_id, headers}.

• body.text et body.html sont tous deux facultatifs, mais au moins l’un est requis. Si vous ne fournissez que body.text, nous générons automatiquement une variante HTML avec des paragraphes <p> (les lignes vides séparent les paragraphes; les retours à la ligne simples deviennent <br>), afin que le message s’affiche comme un e-mail ordinaire dans tous les clients modernes. Pour une police à chasse fixe, envoyez le littéral <pre>...</pre> dans body.html.
• headers est un objet facultatif d’en-têtes sortants fournis par l’utilisateur. La liste autorisée comprend List-Unsubscribe, List-Unsubscribe-Post, Reply-To et tout en-tête de suivi personnalisé X-*. Les autres noms (From, Subject, Message-Id, Authentication-Results, etc.) sont gérés par la plateforme et refusés avec 422. Les valeurs contenant CR/LF sont également refusées pour empêcher l’injection d’en-têtes. Elles sont limitées à 998 caractères conformément à RFC 2822.
• Pour l’envoi groupé et l’automatisation, consultez la section En-têtes de délivrabilité pour les expéditeurs en masse afin de configurer List-Unsubscribe et le commutateur auto_list_unsubscribe à l’échelle du compte.

Articles associés

• Création et gestion des jetons API
• Connexion des agents d’IA (MCP)
• Portées de l’API et autorisations des offres
• Mesures de sécurité et intentions de suppression