API d'e-mail pour développeurs :
Construire avec Gmail, Outlook & IMAP
Une référence pratique pour les développeurs créant des intégrations d'e-mails : comparez les API Gmail, Microsoft Graph et IMAP, puis découvrez comment une API d'e-mails unifiée pour les développeurs réduit des semaines de code répétitif en un seul appel REST.
Qu'est-ce qu'une API d'e-mail pour les développeurs ?
Avant de comparer les fournisseurs et d'écrire du code, voici la définition précise dont les moteurs de recherche et vos coéquipiers ont besoin.
Un API email pour les développeurs est une interface programmatique qui permet à votre application de s'authentifier en tant qu'utilisateur, puis de lire, envoyer ou gérer directement les e-mails de cet utilisateur dans Gmail, Outlook ou toute boîte aux lettres IMAP – sans jamais avoir à gérer leur mot de passe. L'API s'authentifie via OAuth 2.0 (ou des informations d'identification IMAP), renvoie des réponses JSON structurées et déclenche des webhooks lors de l'arrivée de nouveaux e-mails. Elle est catégoriquement différente d'une API d'e-mails transactionnels (SendGrid, Mailgun), qui envoie des e-mails marketing ou de notification. au nom de votre marque une API d'envoi d'e-mails pour les développeurs agit au nom de votre utilisateur, à l'intérieur de leur boîte aux lettres existante.
En pratique : un service d'assistance SaaS utilise une API de messagerie pour extraire directement les tickets de support de la boîte de réception Gmail d'un client. Un CRM l'utilise pour synchroniser chaque fil de discussion par e-mail qu'un représentant commercial échange avec un prospect. Un agent IA l'utilise pour lire, classer et rédiger des réponses dans le compte Outlook d'un utilisateur. Il s'agit d'intégrations côté synchronisation, côté utilisateur OAuth, et non de pipelines d'envoi en masse.
Pourquoi les développeurs ont-ils besoin d'une intégration d'API d'e-mail
Voici les quatre catégories de produits où une API d'e-mail pour développeurs apporte une valeur commerciale directe : lire et agir sur les e-mails des utilisateurs réels, et non envoyer des campagnes de masse.
Les CRM, les helpdesks et les outils de gestion de projet ont besoin accès en direct à la boîte aux lettres d'un utilisateur. Votre application s'authentifie une fois via OAuth, puis lit, organise et affiche les e-mails directement dans votre interface utilisateur - pas de copier-coller, pas de règles de transfert. L'intégration de l'API d'e-mail s'exécute en arrière-plan, maintenant vos données à jour.
Les agents alimentés par des LLM ont besoin de lire et classifier les vrais courriels pour rédiger des réponses, extraire des entités, déclencher des flux de travail ou acheminer des tickets. Une API d'e-mail pour les développeurs donne à votre agent IA un accès JSON structuré à la boîte de réception - sujet, corps, pièces jointes, en-têtes - sans avoir à construire un client de messagerie personnalisé.
Tirer les e-mails de support directement de boîtes aux lettres clients ou boîtes de réception partagées, étiquetez-les par sujet, assignez des agents et publiez des réponses - le tout par programmation. L'intégration de l'API d'e-mails remplace le dépouillement SMTP fragile par une interface REST appropriée et des webhooks en temps réel.
Enregistrez chaque e-mail envoyé ou reçu par un représentant commercial auprès du bon contact ou de la bonne affaire. Suivez le statut d'ouverture/réponse au niveau du fil de discussion. Maintenez votre CRM à jour avec historique de conversation réelle sans demander aux représentants de mettre en copie un alias magique. Intégration pure via API d'e-mail - côté utilisateur, basée sur OAuth, au nom de chaque représentant individuel.
Ceci n'est PAS destiné aux e-mails transactionnels. Si votre cas d'utilisation consiste à envoyer des réinitialisations de mot de passe, des confirmations de commande ou des newsletters depuis votre propre domaine, c'est le marché transactionnel (SendGrid, Mailgun, Resend). L'API d'email d'Unipile pour les développeurs s'adresse au marché de la synchronisation/lecture/écriture au nom de l'utilisateur : infrastructure différente, exigences de conformité différentes, modèle de tarification différent.
Comparaison de Gmail API, Microsoft Graph et IMAP
Chaque intégration d'API d'e-mail commence par l'un des trois fournisseurs natifs. Voici ce que chacun d'eux propose et où chacun crée des frictions pour les développeurs.
| Fonctionnalité | API Gmail | Microsoft Graph | IMAP | Unipile (unifié) |
|---|---|---|---|---|
| Méthode d'authentification | OAuth 2.0 | OAuth 2.0 | Mot de passe / XOAUTH2 | OAuth 2.0 (tous) |
| Webhooks en temps réel | Pub/Sub (GCP nécessaire) | Abonnements graphiques | Non (sonde inactive) | Webhook unifié |
| Format de réponse | Gmail JSON (non-standard) | Graph JSON (OData) | RFC 2822 MIME brut | Schéma JSON unifié |
| Rafraîchissement des jetons | Manuel (bibliothèque google-auth) | Manuel (MSAL) | N/A | Géré par Unipile |
| Limites de taux | 250 Q/utilisateur/s | 10k requêtes / 10 min | Varie selon le serveur | Abstrait + réessayer |
| Envoyer un courriel | Oui, | Oui, | SMTP seulement | Oui (tous les prestataires) |
| Pièces jointes | Nécessite un appel supplémentaire | Max 4 Mo en ligne | Plein MIME | API de pièce jointe unifiée |
| Temps d'installation (estimation) | 1-2 semaines | 1-2 semaines | 3 à 5 jours | Heures |
API d'e-mail native vs API d'e-mail unifiée : comparaison de code réelle
Voir les deux approches côte à côte - dans du code réel - rend le compromis concret. Sélectionnez une langue ci-dessous pour comparer la lecture d'e-mails nativement ou via l'API unifiée d'e-mails de Unipile.
// 1. Installer et configurer le client OAuth
const {google} = require('googleapis');
const authentification = new google.auth.OAuth2(
ID_CLIENT, SECRET_CLIENT, URI_REDIRECTION
);
// 2. Échanger le code d'autorisation contre des jetons
const {jetons} = await auth.jeton(code);
auth.définirLesIdentifiantsjetons ;
// 3. Stocker et rafraîchir les jetons manuellement
// 4. Appeler l'API Gmail
const gmail = google.gmail({
version : 'v1', authentification
});
const res = await
gmail.users.messages.list({
userId : moi, maxResults : 10
});
// 5. Récupérer le message complet par ID
const message = await
gmail.users.messages.obtenir({
userId : moi,
id : res.data.messages[0].id,
format 'plein'
});
// 6. Analyser vous-même la charge utile encodée en base64urlUn SDK, tous les fournisseurs
const unipile =
require('@unipile/node-sdk');
const client =
new unipile.UnipileClient(
API_URL, JETON_ACCÈS
);
// 2. jetons gérés par Unipile
// Aucun flux OAuth manuel requis
// 3. Lister les e-mails
const courriels = await
client.email.listerTout({
identifiant_compte : IDENTIFIANT_COMPTE,
limite : 10
});
// 4. Corps déjà décodé
Gestionnaire JSON unifié - même schéma
// pour Gmail, Outlook, IMAP
console.log(emails.items);import msal, requêtes
# 1. Client confidentiel MSAL
application = msal.ClientApplicationConfidentielle(
CLIENT_ID,
autorité=AUTORITÉ,
identifiants client=CLIENT_SECRET
)
# 2. Obtenir un jeton au nom de l'utilisateur
résultat = application.acquérir_jeton_par_flux_code_authentification(
flux, réponse_authentification
)
jeton = résultat['jeton_d'accès']
# 3. Gérer l'actualisation des jetons et les stocker en toute sécurité
# 4. API Call Graph
en-têtes = {'Authorization': f'Porteur {token}'}
r = requêtes.obtenir(
'https://graph.microsoft.com/v1.0/moi/messages',
en-têtes=en-têtes
)
# 5. Analyser la réponse de l'enveloppe ODataimport demandes
Token # géré par Unipile
# : pas de MSAL, pas de configuration OAuth
en-têtes = {
'X-API-KEY': JETON_ACCÈS,
'Accepter': 'application/json'
}
# fonctionne avec Gmail ET Outlook
# : même point de terminaison, même schéma
r = requêtes.obtenir(
'https://api7.unipile.com:13091'
'/api/v1/courriels',
en-têtes=en-têtes,
paramètres={
'identifiant_de_compte': ID_DU_COMPTE,
'limite': 10
}
)
courriels = r.json()
# Déjà analysé, pas d'OData# IMAP ne dispose pas d'API REST
# Il faut utiliser imaplib ou node-imap
# Pas d'équivalent à cURL
Exemple # : openssl s_client
# (uniquement pour le débogage – pas pour la production)
openssl s_client \
-connecter imap.gmail.com:993 \
-silencieux
# Ensuite, envoyez les commandes IMAP brutes :
# A001 Identifiant : user@gmail.com Mot de passe :
# A002 SÉLECTIONNER LA BOÎTE DE RÉCEPTION
# A003 FETCH 1 RFC822
# A004 DÉCONNEXION
# Vous recevez des données MIME brutes au format RFC 2822
# Doit analyser les en-têtes, décoder
Parties # en base64, gestion des messages multipart
# : fixez-vous des limites
# De plus : pas de webhooks, interrogation en mode IDLE obligatoireAPI REST # - compatible avec n'importe quel
Fournisseur de messagerie # via cURL
curl \
-X OBTENIR \
-H " X-API-KEY : $TOKEN " \
-H "Accepter : application/json" \
"https://api7.unipile.com:13091
/api/v1/emails
?account_id=$ACCOUNT_ID
&limite=10"
Réponse # : JSON propre
# { "items": [ { "id": "...",
# " sujet " : " Bonjour ",
# " from " : { " name " : " Alice ",
# " address " : " ... " },
# " body_plain " : " ... ",
# " date " : " 2026-05-12T... " } ] }
# Même point de terminaison pour Gmail,
# Outlook et comptes IMAPLes essentiels d'OAuth 2.0 pour l'intégration d'API d'e-mail
Chaque intégration d'API de production d'e-mails repose sur OAuth 2.0 pour s'authentifier en tant qu'utilisateur sans stocker son mot de passe. Voici ce dont vous avez besoin pour chaque fournisseur - et comment Unipile s'en charge pour vous.
gmail.lecture seule, gmail.envoyer. Les champs d'application sensibles nécessitent une vérification Google pour la production.bibliothèque google-auth ou un gestionnaire personnalisé.Mail.Read, Mail.Send, Mail.ReadWrite.SDK et outils pour l'intégration d'API d'e-mail
Que vous construisiez en natif ou à l'aide d'une couche unifiée, le bon SDK réduit le code répétitif. Voici le paysage actuel pour chaque fournisseur et pour Unipile.
SDK officiel pour l'API unifiée de messagerie Unipile. Couvre la lecture, l'envoi, la gestion de comptes et les webhooks pour Gmail, Outlook et IMAP - en un seul package. Définitions TypeScript incluses.
@azure/msal-node séparé). Bien entretenu. Le format de réponse OData nécessite un analyse supplémentaire pour les cas d'utilisation simples.Tarification adaptée aux développeurs : commencez gratuitement, évoluez en toute transparence
"Les API d'e-mails natifs " gratuits » ne le sont pas vraiment. L'API Gmail et Microsoft Graph coûtent zéro dollar par appel d'API, mais chacune demande des semaines d'ingénierie : cycles de vérification OAuth, logique de rafraîchissement des jetons, infrastructure de webhook, gestionnaires de nouvelles tentatives, mappage des erreurs. Une équipe de taille moyenne passe généralement 3 à 6 semaines avant de livrer une seule fonctionnalité. L'API d'e-mails unifiée d'Unipile pour les développeurs remplace ce travail par un essai gratuit de 7 jours, sans carte de crédit requise.
En bref : les appels API sont gratuits, l'ingénierie, elle, ne l'est pas. La mise en place d'une intégration e-mail de qualité professionnelle sur les API natives (flux d'authentification, actualisation des jetons, gestion des erreurs, infrastructure de webhooks, abstraction multi-fournisseurs) coûte généralement 3 à 8 semaines de travail pour un développeur expérimenté par fournisseur, plus la maintenance continue chaque fois que Google ou Microsoft publie une modification qui casse la compatibilité. Unipile facture par compte lié par mois avec des paliers transparents. Voir le Guide de l'API d'e-mail gratuit pour la ventilation complète.
Sécurité et conformité pour les intégrations d'API d'e-mail
Lorsque votre application traite les e-mails des utilisateurs, la conformité n'est pas une option. Unipile est conçu pour les deux frameworks importants pour les produits destinés aux développeurs qui traitent des données européennes et d'entreprise.
Unipile est Certification SOC 2 Type II. L'audit couvre les critères de confiance de sécurité, de disponibilité et de confidentialité. Cela signifie que des auditeurs indépendants ont vérifié les contrôles d'Unipile sur une période soutenue – pas seulement à un instant T. Exigé par la plupart des acheteurs en entreprise et les questionnaires de sécurité SaaS.
Unipile traite les données d'e-mails en tant que processeur de données Conformément à l'article 28 du RGPD, des accords de traitement des données (ATD) sont disponibles pour tous les plans payants. Les données d'e-mail des utilisateurs ne sont traitées que pendant la durée de la session authentifiée et dans le cadre accordé par le consentement OAuth de l'utilisateur. Pas de stockage parallèle, pas de données vendues à des tiers.
Pièges courants dans l'intégration d'API d'e-mail (et comment les résoudre)
Chaque développeur qui intègre pour la première fois une API d'email se heurte aux mêmes quatre obstacles. Les voici – et comment les surmonter chacun correctement.
Les 250 unités de quota par utilisateur et par seconde de Gmail semblent généreuses jusqu'à ce que l'on réalise que lister 10 messages coûte 5 à 10 unités chacun et que récupérer le corps entier ajoute un quota par octet. Microsoft Graph plafonne à 10 000 requêtes par 10 minutes par application et par locataire. Atteindre la limite renvoie 429 - Trop de requêtes. Sans logique de nouvelle tentative, votre boucle de synchronisation plante silencieusement.
Les jetons d'accès de Google expirent après 3 600 secondes. Les jetons Microsoft après 60 à 90 minutes. Si votre jeton de rafraîchissement est révoqué (l'utilisateur modifie son mot de passe, révoque l'accès à l'application ou le jeton n'a pas été utilisé pendant 6 mois pour Google), votre synchronisation entière s'arrête silencieusement. Aucune erreur n'est signalée, sauf si vous surveillez la réponse de l'appel de rafraîchissement.
Les abonnements Microsoft Graph expirent après un maximum de 4 230 minutes (environ 3 jours pour les e-mails). Oublier de les renouveler signifie plus de notifications push - votre application revient au sondage ou manque des événements. Les abonnements Gmail Pub/Sub sont plus persistants mais nécessitent un abonnement GCP pour rester valides et que le sujet existe.
Les API d'e-mail sont éventuellement cohérentes. Si votre processus de synchronisation plante à mi-parcours, vous risquez de duplicata d'e-mails, ignorer une page de résultats, ou manquer des suppressions. Gmail utilise historyId pour la synchronisation incrémentielle ; Microsoft Graph utilise deltaToken. Les deux nécessitent une gestion minutieuse du curseur lors des redémarrages. IMAP n'a pas d'état de synchronisation natif - vous devez maintenir votre propre suivi des UID.
API d'e-mail pour les développeurs - foire aux questions
Réponses aux questions les plus fréquemment posées par les développeurs lors de la création de leur première intégration d'API d'e-mail à travers Gmail, Outlook et IMAP.
npm install @unipile/node-sdk. Puis créez un client avec votre URL d'API et votre jeton d'accès, et appelez client.email.listerTout() pour lire des e-mails ou client.email.envoyer() pour envoyer - via Gmail, Outlook et IMAP avec un seul chemin de code. Pour Gmail natif, utilisez le googleapis package npm. Pour Microsoft Graph, utilisez @microsoft/microsoft-graph-client.