LinkedIn
Instagram
WhatsApp
Telegram
Gmail
Outlook
Google Agenda
Rejoindre la communauté Slack5 produits qui fonctionnent sur une API Email - et Pourquoi
Enrichissement CRM, suivi des candidats ATS, engagement commercial, boîtes de réception du service d'assistance, assistants IA - chacun de ces produits doit lire et envoyer des e-mails au nom d'utilisateurs authentifiés. Ce guide montre exactement comment ils le font, avec des modèles de code réels, afin que vous puissiez construire la même chose en quelques heures, pas en quelques semaines.
const response = await fetch(
`/api/v1/emails?account_id=${accountId}`,
{ headers: {
'X-API-KEY': process.env.UNIPILE_KEY
}}
);
const { courriels } = await réponse.json();
// Connexion automatique à la chronologie des contacts
enregistrerDansCRM(courriels, contactId);
Que pouvez-vous construire avec une API d'e-mail ?
Une API d'e-mail pour la synchronisation des utilisateurs permet à votre produit lire, synchroniser et envoyer des e-mails au nom des utilisateurs authentifiés, accédant à leurs boîtes de réception réelles via OAuth. Les cinq principaux cas d'utilisation des API d'e-mail sont : Enrichissement du CRM (enregistrer automatiquement chaque e-mail de prospect), Système de suivi des candidats ATS (synchronisation des fils par candidat), engagement commercial (détection de réponse et envoi depuis une boîte aux lettres réelle), support client (messagerie unifiée), et Agents d'e-mail IA (accès LLM à portée limitée pour la rédaction et le triage). Chacune de ces opérations repose sur le même schéma sous-jacent : lire + synchroniser + envoyer au nom de l'utilisateur authentifié.
| Vertical | Email de candidature | Modèle d'API | Prestataires principaux |
|---|---|---|---|
| CRM | Enrichir le contact, journaliser automatiquement le fil | lire + synchroniser | Gmail, Outlook, IMAP |
| ATS / Recrutement | Suivre le fil candidat, partager la vue | synchroniser + lire | Gmail, Outlook, IMAP |
| Engagement commercial | Détection de réponse, envoyer depuis la boîte aux lettres du représentant | synchroniser et envoyer | Gmail, Outlook, IMAP |
| Support Client | Boîte de réception unifiée, ticket à partir d'un fil de discussion | lire + envoyer | Gmail, Outlook, IMAP |
| Agent d'e-mail IA | Tri, brouillon, résumer au nom de | lire + envoyer (limité) | Gmail, Outlook, IMAP |
Pas ce que vous cherchez ? Il existe deux catégories d'API d'e-mail : transactionnel (SendGrid, Mailgun, vous possédez le domaine d'envoi, les destinataires ne se sont jamais inscrits à votre produit) et synchronisation des utilisateurs (cet article). La synchronisation des utilisateurs signifie la délégation OAuth ; votre produit agit au nom des utilisateurs authentifiés accédant à leurs propres boîtes de réception. Les cinq cas d'utilisation ci-dessous relèvent tous de la synchronisation des utilisateurs. Si vous devez envoyer des newsletters en masse depuis votre propre domaine, ce n'est pas votre guide.
Email API pour CRM
Un CRM qui utilise une API d'e-mail peut enregistrer automatiquement chaque e-mail échangé entre un représentant commercial et un prospect directement sur la fiche du contact, sans aucune copie-coller. L'API d'e-mail lit la boîte de réception de l'utilisateur au nom du représentant commercial authentifié, fait correspondre les fils de discussion aux contacts existants par adresse e-mail et écrit en temps réel dans la chronologie du CRM.
Le motif derrière API de messagerie pour CRM c'est-à-dire lire, synchroniser et envoyer – le tout au nom de l'utilisateur authentifié. Le représentant associe une seule fois son compte Gmail ou Outlook via OAuth. Par la suite, tous les e-mails entrants et sortants avec un contact connu sont automatiquement enregistrés – sans transfert en Cci, sans extension de navigateur, sans saisie manuelle.
// 1. Récupérer les e-mails d'un contact
// au nom du représentant authentifié
GET /api/v1/emails
?account_id={rep_account_id}
&email_expediteur={courriel_contact}
Autorisation : X-API-KEY {key}
// Réponse
{
"objet": "ListeEmailsCompte",
"articles": [
{
"id": "em_01abc",
"sujet": "Re: Suivi",
"de": "contact@acme.com",
"date": "2026-06-05"
}
]
}API de messagerie électronique pour les systèmes de gestion des candidatures (ATS) et les logiciels de recrutement
Un ATS doté d'une API de messagerie électronique offre une vue d'ensemble complète et synchronisée automatiquement de toutes les conversations par e-mail avec chaque candidat, quel que soit le recruteur ou le fournisseur de messagerie. Les recruteurs n'ont à associer leurs comptes qu'une seule fois ; dès lors, chaque fil de discussion est automatiquement mis en correspondance avec le profil du candidat.
Le API e-mail pour ATS Ce cas d'utilisation porte sur la synchronisation et la visibilité. Les équipes de recrutement comptent généralement plusieurs recruteurs qui utilisent différents comptes de messagerie : Gmail pour l'un, Outlook pour un autre. L'API de messagerie consulte chaque compte associé au nom du recruteur authentifié et affiche tous les fils de discussion contenant l'adresse e-mail d'un candidat dans un fil d'actualité unique et unifié au sein du système de gestion des candidatures (ATS).
Le Cas d'utilisation de l'API de messagerie Cette fonctionnalité est particulièrement utile pour les équipes composées de plusieurs fournisseurs. Les recruteurs des grandes entreprises utilisent souvent à la fois des comptes Gmail et Outlook. Une API de messagerie unifiée gère les deux via une seule intégration, ce qui permet au développeur du système de suivi des candidatures (ATS) d'écrire un seul chemin de code, et non deux. Pour découvrir le modèle technique complet permettant de lire les données de la boîte de réception, consultez le lire le guide de l'API de messagerie. Pour les modèles de synchronisation en temps réel, consultez le Guide de l'API de synchronisation d'e-mails.
Résumé des modèles de l'API e-mail ATS : Connectez les comptes des recruteurs via OAuth (Gmail, Outlook ou IMAP). Synchronisez tous les fils de discussion entrants et sortants par adresse de candidat. Affichez un fil d'actualité unifié dans l'interface utilisateur de l'ATS. Envoyez éventuellement des e-mails de réponse depuis l'ATS au nom de la boîte mail réelle du recruteur : pas de transfert en Cci, pas d'alias d'e-mail, pas de " de noreply@yourapp.com ".
API de messagerie pour l'engagement commercial
Les plateformes d'engagement commercial utilisent une API de messagerie pour détecter quand un prospect répond et déclencher automatiquement l'étape suivante d'une séquence : suspendre les relances, avertir le commercial, faire passer l'opportunité à l'étape suivante. Il est essentiel de noter que les e-mails sortants sont envoyés depuis la boîte mail réelle du commercial, et non depuis un domaine partagé de la plateforme, ce qui garantit la délivrabilité et préserve l'identité de l'expéditeur.
Le API de messagerie électronique pour l'engagement commercial Le processus consiste à synchroniser puis à envoyer, pour chaque utilisateur. Chaque commercial associe son compte Gmail ou Outlook une seule fois. Chaque e-mail d'une séquence active est envoyé depuis l'adresse réelle de ce commercial. Lorsqu'une réponse arrive, le moteur de synchronisation détecte l'identifiant du fil de discussion, le fait correspondre à une séquence ouverte et déclenche l'automatisation appropriée. Il s'agit d'une décision prise par le client : la plateforme se contente de relayer l'action ; la cadence et le volume restent sous le contrôle de l'équipe commerciale.
Ceci cas d'utilisation d'une API d'e-mail est le pilier des outils tels que les plateformes de prospection et les SaaS d'automatisation des ventes. L'avantage de la délivrabilité est fondamental : les e-mails envoyés depuis rep@lentreprise.com via la boîte de réception Gmail ou Outlook réelle du représentant héritent de la réputation d'envoi du domaine. Les e-mails envoyés depuis un domaine de plateforme partagé ne le font pas. Le modèle d'envoi complet est documenté dans guide API d'envoi d'e-mails.
Pourquoi cela est important pour la délivrabilité : L'envoi par la plateforme-domaine (depuis sequences@platform.com) dissocie la réputation de l'expéditeur de celle de son domaine. L'envoi par synchronisation d'utilisateurs route chaque e-mail via la boîte aux lettres réelle de l'utilisateur authentifié – Gmail SMTP ou Outlook Graph – de sorte que la délivrabilité est liée à la réputation du domaine de l'utilisateur, et non à celle de la plateforme. C'est un avantage structurel qu'aucune API d'e-mail transactionnel ne peut reproduire.
API d'e-mail pour le support client / service d'assistance
Un centre d'assistance basé sur une API d'e-mail agrège toutes les boîtes aux lettres de support - support@, facturation@, entreprise@ - en une seule boîte de réception unifiée. Les nouveaux e-mails créent automatiquement des tickets. Les réponses sont envoyées depuis l'adresse de la boîte aux lettres d'origine. L'agent de support ne quitte jamais l'interface du centre d'assistance pour ouvrir Outlook ou Gmail.
Le API e-mail pour le support client Le cas d'utilisation est principalement lecture + envoi, avec une forte exigence de threading. La plupart des helpdesks gèrent plusieurs adresses sur plusieurs fournisseurs : une équipe utilise Gmail, une autre utilise Outlook, une troisième pourrait avoir une boîte aux lettres héritée uniquement IMAP. Une API d'email unifiée lit tous les comptes liés comme un seul flux, préservant le contexte du fil afin que les agents puissent répondre dans le fil avec l'identité correcte de l'expéditeur.
Ceci Cas d'utilisation de l'API de messagerie c'est ainsi que les produits SaaS de helpdesk modernes se différencient, en particulier ceux qui se positionnent face aux outils hérités construits sur des plugins basés uniquement sur l'e-mail. La différenciation clé est la fidélité du fil : les e-mails transitent par le canal SMTP/Graph réel du propriétaire de la boîte de réception, de sorte que les réponses arrivent dans le bon fil du côté du client, et non comme un message déconnecté d'une adresse générique de la plateforme. Pour le guide technique complet couvrant les trois fournisseurs, consultez Guide de l'API Email.
Intégrez votre boîte de réception du supportAPI d'e-mail pour les agents/assistants d'e-mail IA
Les agents de messagerie IA utilisent une API de messagerie pour donner à un grand modèle linguistique un accès limité et "au nom de" la boîte de réception réelle d'un utilisateur - en lisant les fils de discussion pour rédiger des réponses, en triant les messages, en résumant de longues chaînes d'e-mails et, éventuellement, en envoyant des réponses après révision humaine. Le modèle ne gère jamais les informations d'identification OAuth ; l'API de messagerie abstrait la boîte de réception comme un flux structuré propre.
C'est le plus nouveau Cas d'utilisation de l'API de messagerie et la plus rapidement croissante en 2026. Les assistants IA intégrés aux outils de productivité, aux outils de vente et aux produits CRM ont tous besoin des trois mêmes éléments : un accès en lecture à la boîte de réception pour la récupération du contexte, des données structurées d'e-mails pour le "prompting" (sujet, expéditeur, corps, ID de fil de discussion), et un canal d'envoi optionnel pour les brouillons confirmés. L'API e-mail fournit ces trois éléments en une seule intégration pour Gmail, Outlook et IMAP, au nom de l'utilisateur authentifié.
Accès et gestion des données avec portée : Les agents d'e-mail IA construits sur une API d'e-mail synchronisée avec l'utilisateur n'accèdent qu'à la boîte de réception de l'utilisateur authentifié – jamais au-delà de cette portée. L'API d'e-mail agit comme une intermédiaire technique indépendant, transmettant des données structurées à la couche LLM sans stocker de copie parallèle des e-mails de l'utilisateur. La portée du traitement des données, la rétention et le consentement restent une décision côté client. C'est l'architecture correcte pour les agents IA opérant au nom de vrais utilisateurs sans devenir un entrepôt de données.
Lorsque vous créez des agents d'e-mail IA à grande échelle, vous devez également gérer la réalité multi-fournisseurs : vos utilisateurs auront des comptes Gmail, Outlook et IMAP. Une API d'e-mail unifiée normalise le flux de la boîte de réception dans une structure cohérente - thread_id, sujet, de, à, corps, date - quel que soit le fournisseur. Votre modèle de prompt LLM reste le même pour les trois. Pour le guide technique complet sur la couche d'intégration d'e-mails pour les produits IA, consultez Guide de l'API d'e-mail pour les développeurs. Pour l'architecture plus large des agents d'IA multicanaux (ajout de LinkedIn, WhatsApp et d'autres canaux au même agent), le guide à venir sur l'API multicanal pour les agents d'IA couvre l'ensemble de la pile.
Commencez à construire votre agent de messagerie IATransactionnel ou synchronisation utilisateur : dans quel cas d'utilisation vous trouvez-vous ?
Si les cinq cas d'utilisation des API d'e-mails ci-dessus ne correspondent pas à vos besoins, vous pourriez être dans la mauvaise catégorie. Les API d'e-mails se divisent en deux marchés fondamentalement différents, transactionnel et synchronisation d'utilisateurs, et ils ne se chevauchent pas. Cette courte section vous indique de quel côté vous vous trouvez afin que vous arrêtiez d'évaluer les mauvais outils.
| Dimension | API d'e-mails transactionnels | API de synchronisation des e-mails de l'utilisateur (cet article) |
|---|---|---|
| Qui possède le domaine d'envoi | Vous (la plateforme) | L'utilisateur (son Gmail / Outlook) |
| Expéditeurs typiques | noreply@yourapp.com | user@theirdomain.com |
| OAuth requis | Non | Oui, |
| Lire / synchroniser la boîte de réception de l'utilisateur | Non | Oui, |
| Cas d'usages | Notifications, reçus, marketing | CRM, ATS, ventes, support, agents IA |
| Exemples de fournisseurs | SendGrid, Mailgun, Resend | API Gmail, MS Graph, IMAP, Unipile |
Si votre produit envoie des notifications, des reçus ou des e-mails marketing depuis un domaine que vous possédez, c'est le marché transactionnel, et SendGrid, Mailgun ou Resend sont les bons outils. Si votre produit a besoin d'accéder aux boîtes de réception réelles des utilisateurs en leur nom, de lire leurs e-mails, de synchroniser leurs conversations ou d'envoyer depuis leur adresse réelle, c'est la synchronisation utilisateur, et les cinq cas d'utilisation de l'API de messagerie ci-dessus, voici exactement ce que vous construisez. Pour une analyse plus approfondie sur le choix de chaque approche, consultez le guide complet sur les API d'e-mails synchrones et transactionnels.
Données, confidentialité et responsabilité de la plateforme
Chaque cas d'utilisation d'API d'e-mail dans cet article implique l'accès aux boîtes de réception réelles des utilisateurs via OAuth. Avant de construire, comprenez comment Unipile fonctionne en tant qu'intermédiaire, ce que signifie la gestion des données en pratique et où se situent les responsabilités de la plateforme.
Unipile ne maintient pas de copie parallèle des e-mails de vos utilisateurs indépendamment de leur boîte aux lettres. L'accès est limité à utilisateur authentifié'le compte, limité à la session et aux autorisations accordées via OAuth. Aucune archive d'e-mails n'est créée en dehors du fournisseur de l'utilisateur (Gmail, Outlook, IMAP). Le périmètre de traitement des données, les politiques de rétention et les mécanismes de consentement de l'utilisateur restent sous la responsabilité de votre produit en tant que responsable du traitement des données.
Unipile agit comme un intermédiaire technique indépendant entre votre produit et le fournisseur de messagerie. Chaque opération de messagerie - lecture, synchronisation, envoi - est exécutée au nom de le propriétaire du compte lié, en utilisant ses propres identifiants OAuth. Unipile n'est affilié, approuvé ou parrainé par Google ou Microsoft. Aucun identifiant n'est partagé entre les utilisateurs. Chaque compte lié est isolé.
Unipile relaie les limites de débit et les contrôles d'accès du fournisseur d'e-mail sous-jacent (Google, Microsoft, serveur IMAP). La fréquence des appels d'API, la cadence des synchronisations et le volume d'e-mails envoyés par compte restent un décision côté client. Votre produit est responsable du respect des quotas du fournisseur et des réglementations applicables (RGPD, CCPA). Unipile est certifié SOC 2 et conforme au RGPD en tant que couche d'infrastructure.
Unipile n'est affilié, approuvé ou sponsorisé par Google ou Microsoft Corporation. Gmail et Outlook sont des marques déposées de leurs propriétaires respectifs. Google n'est pas affilié à Unipile. Microsoft n'est pas affilié à Unipile. L'utilisation de ces plateformes via l'API d'Unipile est soumise aux conditions d'utilisation et aux politiques d'utilisation acceptable des plateformes respectives.
Cas d'utilisation de l'API d'e-mail - FAQ
Questions courantes sur les cas d'utilisation des API d'e-mail, l'accès à la boîte de réception OAuth et le développement sur les API d'e-mail de synchronisation utilisateur.
Un API de messagerie laissons les produits logiciels lire, synchroniser et envoyer des e-mails au nom des utilisateurs authentifiés - accédant à leurs boîtes de réception Gmail, Outlook ou IMAP réelles via OAuth. Noyau cas d'utilisation de l'API de messagerie inclure l'enrichissement CRM, le suivi des candidats ATS, l'automatisation des séquences d'engagement commercial, les boîtes de réception unifiées du centre de support et les agents d'e-mails IA. Ceci est distinct des API d'e-mails transactionnels (SendGrid, Mailgun) qui envoient des messages en masse à partir d'un domaine détenu par la plateforme et n'impliquent pas d'accès à la boîte de réception via OAuth.
Un CRM utilise une API d'e-mail pour enregistrer automatiquement toutes les conversations par e-mail entre un représentant et un prospect sur la fiche du contact - aucune copie-coller manuelle, aucun transfert en copie cachée requis. API de messagerie pour CRM lit la boîte de réception du représentant au nom du utilisateur authentifié, associe les conversations aux adresses e-mail de contact et écrit dans la timeline du CRM en temps réel. Il permet également d'envoyer des e-mails depuis le CRM en utilisant la boîte aux lettres réelle du commercial, de sorte que les réponses proviennent de leur véritable adresse - essentiel pour les taux de réponse et la délivrabilité.
Les plateformes ATS utilisent les API e-mail pour ATS pour synchroniser tous les fils de discussion entre les recruteurs et les candidats. Chaque recruteur connecte une fois son compte Gmail ou Outlook via OAuth. L'API lit tous les e-mails envoyés ou reçus de l'adresse de chaque candidat sur l'ensemble des comptes des recruteurs et les associe au profil du candidat. Cela offre une visibilité partagée à toute l'équipe sans que personne n'ait besoin d'accéder à la boîte aux lettres d'un collègue. Certains produits ATS associent cela à une API Calendrier pour analyser les fils de discussion de planification d'entretiens et créer des événements automatiquement.
Oui. Vous pouvez synchroniser la boîte de réception Gmail ou Outlook d'un utilisateur à l'aide d'une API de messagerie prenant en charge la délégation OAuth. L'utilisateur s'authentifie une fois via l'authentification OAuth de Google ou de Microsoft, accordant à votre application l'accès au nom de leur compte. L'API fournit ensuite des points d'accès pour lister les e-mails, récupérer le contenu des fils de discussion, synchroniser les nouveaux messages via des webhooks et envoyer depuis la boîte aux lettres de l'utilisateur. Une API d'e-mail unifiée comme Unipile couvre Gmail, Outlook et IMAP avec une seule intégration - voir le Guide de l'API Email pour la présentation technique complète.
Les assistants d'e-mail IA accèdent aux e-mails via une API de messagerie qui fournit accès à la boîte de réception avec étendue et pour le compte de pour l'utilisateur authentifié. L'API d'e-mail récupère des données structurées (sujet, de, à, corps, ID de conversation) et les transmet à l'IA comme contexte. Le modèle génère ensuite une ébauche de réponse, un résumé ou une action de triage. L'API d'e-mail gère l'OAuth et normalise les différences entre les fournisseurs (Gmail, Outlook, IMAP) afin que la couche IA reçoive un flux structuré cohérent, quel que soit le fournisseur de l'utilisateur. Le modèle ne manipule jamais les identifiants ni les jetons OAuth bruts.
Oui. La lecture de la boîte de réception d'un utilisateur nécessite une autorisation OAuth. Pour Gmail, cela signifie Google OAuth 2.0 avec le protocole approprié Portées de l'API Gmail. Pour Outlook, cela signifie Microsoft OAuth avec les autorisations Microsoft Graph. Pour IMAP, XOAUTH2 est la norme moderne (l'authentification de base a été dépréciée par les principaux fournisseurs, y compris Google et Microsoft). OAuth garantit que l'utilisateur consent explicitement à l'accès à sa boîte aux lettres, et la portée des autorisations est limitée à ce qu'il a approuvé. Une API de messagerie unifiée gère ce flux OAuth pour les trois fournisseurs.
Le plus intégration d'email pour SaaS Les produits entrent dans l'un des cinq cas d'utilisation de synchronisation utilisateur de cet article : CRM (journalisation des conversations), ATS (suivi des candidats), ventes (détection d'envoi + de réponse), support (boîte de réception unifiée) ou IA (récupération de contexte). La décision architecturale sous-jacente - qu'il s'agisse de construire directement sur l'API Gmail / Microsoft Graph / IMAP ou d'utiliser une couche d'abstraction unifiée - est traitée en détail dans Guide de l'API d'email pour SaaS, y compris les modèles d'architecture, les coûts cachés et la décision de construire ou d'acheter.
Non. Unipile n'est affilié, approuvé ou sponsorisé par Google ou Microsoft. Unipile est un intermédiaire technique indépendant qui fournit une couche d'API unifiée sur Gmail (Google), Outlook (Microsoft) et IMAP. L'accès à chaque fournisseur est régi par les conditions d'utilisation de la plateforme respective. Unipile est certifié SOC 2 et conforme au RGPD en tant que couche d'infrastructure. Votre produit reste responsable du consentement de l'utilisateur, de la portée de la gestion des données et de la conformité avec les réglementations applicables en matière de protection des données.
Vous avez encore des questions sur les cas d'utilisation de l'API e-mail ? Notre équipe est là pour vous aider.
FR 
EN 
ES 
DE 
IT 
BR 
NL 
PL 
TR