Démarrer

API pour envoyer des e-mails au nom de l'utilisateur

API Email

Qu'est-ce que " Envoyer au nom de " dans une API d'e-mail ?

Envoyer un e-mail au nom d'un utilisateur signifie que votre application envoie des messages directement depuis la boîte aux lettres de l'utilisateur, et non depuis un expéditeur transactionnel partagé. Le destinataire voit la véritable adresse e-mail de l'utilisateur dans le champ "De". C'est le fondement de tout produit SaaS qui gère les e-mails pour ses utilisateurs.

Ce que vous apprendrez

Comment les flux OAuth 2.0 envoient-ils l'autorisation
Gmail, Outlook et prise en charge IMAP
E-mails on-behalf vs e-mails transactionnels APIs
Envoi via l'API unifiée Unipile
CRM, assistant IA et cas d'utilisation du support
Conformité juridique et permissions utilisateur
Essayez l'API Email d'Unipile Lire la documentation
Envoyé depuis la boîte mail de l'utilisateur Adresse " De " réelle
API d'e-mail Unipile
Envoyer au nom de POST
POST /api/v1/emails
200 OK
GET /api/v1/courriels/{id}
200 OK
GET /api/v1/comptes/{id}
200 OK
Charge utile JSON
{ "account_id": "utilisateur_abc123", "à": [{ "identifier": "prospect@acme.com" }], "sujet": "Suivi", "corps": "Salut Sarah..." }
Sécurisé par OAuth 2.0 L'utilisateur donne la permission
Construction d'une intégration d'e-mails ?

Lisez le nôtre Guide complet de l'API d'e-mail - Flux OAuth, synchronisation, envoi et comparaison des fournisseurs.

Pourquoi les produits SaaS ont besoin de l'envoi d'e-mails "on behalf of"

La plupart des produits SaaS qui touchent à l'e-mail finissent par être confrontés à la même exigence : l'utilisateur souhaite que les messages proviennent de sa propre adresse, et non d'un domaine générique de plateforme. Qu'il s'agisse d'un CRM, d'un assistant d'écriture IA ou d'un outil de support, au moment où votre produit envoie des messages pour les utilisateurs, vous avez besoin de l'envoi en votre nom. Voici pourquoi c'est important – et comment les trois principaux cas d'utilisation correspondent à l'API.

Cas d'utilisation CRM

Les commerciaux envoient depuis leur vrai Gmail ou Outlook

Dans un contexte de CRM, le commercial est celui qui construit la relation. Si votre plateforme envoie des relances à partir de noreply@yourcrm.com, la délivrabilité chute et le prospect est confus. Avec l'envoi pour le compte de, votre CRM appelle l'API Unipile en utilisant le compte lié du commercial. Chaque e-mail atterrit dans la boîte de réception du prospect en affichant la véritable adresse du représentant.

Les fils d'e-mails restent dans le dossier "Envoyés" du représentant, conservant l'historique en un seul endroit
Les réponses arrivent dans la boîte de réception du commercial pour une continuité de conversation naturelle
La réputation de l'expéditeur est liée au domaine du représentant, et non à un domaine de plateforme partagé.
Cas d'utilisation de l'assistant IA

IA rédige et envoie depuis la boîte aux lettres de l'utilisateur

Les assistants d'e-mails IA – qu'ils rédigent automatiquement des réponses, planifient des suivis ou résument des fils de discussion – ont besoin d'un accès en écriture à la boîte aux lettres de l'utilisateur. Sans l'envoi "au nom de", l'IA ne peut que suggérer ; elle ne peut pas exécuter. Avec un compte lié via l'API Unipile, votre assistant peut envoyer le message approuvé directement depuis Gmail ou Outlook de l'utilisateur en un seul appel d'API.

Projet approuvé : un appel d'API le diffuse depuis l'adresse réelle de l'utilisateur
Fonctionne que l'utilisateur utilise Gmail, Outlook, ou n'importe quel fournisseur IMAP
Prend en charge le multithreading via le paramètre reply_to pour maintenir les conversations intactes
Cas d'utilisation de l'outil de support

Les agents de support répondent à partir d'une boîte de réception de support partagée

Les plateformes de support client acheminent souvent les tickets via une boîte de réception partagée comme support@company.com. Cette boîte de réception est elle-même une boîte aux lettres - elle doit être liée en tant que compte. Avec Unipile, votre plateforme peut connecter cette boîte aux lettres Outlook ou IMAP partagée, permettant à tout agent d'envoyer des réponses qui semblent provenir directement de l'adresse de support officielle, avec le contexte complet du fil de discussion conservé.

Boîte de réception partagée liée une fois, accessible à tous les agents autorisés
Les réponses affichent toujours le bon nom de domaine de l'entreprise dans le champ De
Pièces jointes, CC et BCC tous pris en charge via le même point de terminaison unifié
Meilleure délivrabilité
Les e-mails envoyés depuis le propre domaine de l'utilisateur réussissent les vérifications SPF et DKIM liées à leur compte, et non à un expéditeur partagé.
Accès sécurisé par OAuth
Les utilisateurs accordent l'autorisation via le flux OAuth de leur fournisseur. Aucun mot de passe n'est stocké, entièrement révocable à tout moment.
Une API unifiée
Le même POST /api/v1/emails le point de terminaison gère les comptes Gmail, Outlook et IMAP.
Une mise sur le marché plus rapide
Évitez de créer des intégrations distinctes pour Gmail, Outlook et IMAP. Unipile normalise les trois derrière une seule interface.
L'idée clé : vos utilisateurs ont déjà des adresses e-mail auxquelles leurs contacts font confiance. L'envoi "on-behalf" permet à votre SaaS de tirer parti de cette confiance sans demander à qui que ce soit de changer de fournisseur ou de créer une nouvelle boîte de réception. Pour une vision plus large du fonctionnement des API de messagerie, consultez le Guide de l'API e-mail.
Commencez à construire gratuitement

Comment fonctionne l'API de courrier électronique "On-Behalf" (flux OAuth 2.0)

Envoyer un e-mail au nom d'un utilisateur nécessite trois éléments : le consentement de l'utilisateur, un jeton d'accès valide et un appel d'envoi via l'infrastructure du fournisseur. Voici comment ce flux fonctionne en pratique, et comment Unipile l'abstrait en une seule API unifiée. Pour une référence technique plus large sur les points d'envoi, les paramètres et les différences entre les fournisseurs, consultez notre documentation complète guide API d'envoi d'e-mails.

1

L'utilisateur accorde la permission OAuth

L'utilisateur clique sur " Connecter votre e-mail " dans votre produit SaaS. Unipile le redirige vers l'écran de consentement OAuth de son fournisseur - Google pour les utilisateurs de Gmail, Microsoft pour les utilisateurs d'Outlook et de Microsoft 365. L'utilisateur se connecte et approuve les scopes demandés, qui incluent la possibilité d'envoyer des e-mails en son nom. Aucun mot de passe n'est jamais partagé avec votre application.

Pour les fournisseurs IMAP, l'utilisateur saisit son mot de passe spécifique à l'application ou ses identifiants IMAP directement dans un formulaire hébergé par Unipile. Unipile stocke les identifiants de manière chiffrée et gère la reconnexion automatiquement.
2

Votre application reçoit un identifiant de compte lié

Une fois que l'utilisateur a terminé le flux OAuth, Unipile stocke le jeton d'accès en toute sécurité et renvoie un account_id à votre application. Il s'agit d'un identifiant stable pour la boîte aux lettres liée de l'utilisateur. Vous stockez cet ID dans votre base de données en regard de l'enregistrement utilisateur. Toutes les opérations d'e-mail ultérieures pour cet utilisateur font référence à cet ID de compte ; vous ne touchez jamais au jeton OAuth brut.

Unipile gère le renouvellement des tokens automatiquement. Si le token d'un compte Gmail ou Outlook expire, Unipile le renouvelle en arrière-plan, de sorte que vos appels d'envoi ne échouent jamais en raison de credentials expirés.
3

Envoyer via l'infrastructure du fournisseur

Lorsque votre application doit envoyer un courriel, elle appelle POST /api/v1/emails Avec l'ID de compte et la charge utile du message. Unipile achemine la requête via le bon fournisseur : API Gmail pour les comptes Google, API Microsoft Graph pour les comptes Outlook et Microsoft 365, et SMTP pour les comptes IMAP. L'e-mail est expédié depuis la boîte aux lettres de l'utilisateur et apparaît dans son dossier Éléments envoyés.

Le même appel API fonctionne quel que soit le fournisseur. Vous écrivez une seule intégration ; Unipile la traduit en API Gmail, Microsoft Graph ou SMTP de manière transparente.

Exemples de code

Python
Node.js
Python - Envoyer un e-mail au nom de l'utilisateur
import demandes

# account_id récupéré après que l'utilisateur ait complété le flux OAuth
UNIPILE_DSN = "https://api1.unipile.com:13301"
JETON_ACCÈS = "VOTRE_JETON_D_ACCES"
ID_COMPTE   = "id_utilisateur_depuis_bd"

charge utile = {
    "account_id"ID_COMPTE:,
    "à": [{
        "nom_d_affichage": "Sarah Connor",
        "identifier":   "sarah@acme.com"
    }],
    "sujet": "Suite à notre conversation",
    "corps":    "
Bonjour Sarah, pour faire suite...
 "
}

réponse = requests.poste(
    f"{UNIPILE_DSN}/api/v1/emails",
    json=charge utile,
    en-têtes={"X-API-KEY": ACCESS_TOKEN}
)

print(response.json())  # {"object": "EmailSent", "email_id": "..."}
Node.js - Envoyer un courriel au nom d'un utilisateur
// ID du compte récupéré après que l'utilisateur a terminé le flux OAuth
const UNIPILE_DSN = "https://api1.unipile.com:13301";
const JETON_ACCÈS = "VOTRE_JETON_D_ACCES";
const ID_COMPTE = "id_utilisateur_depuis_bd";

const charge utile = {
  account_idID_COMPTE:,
  à: [{ nom_d'affichage: "Sarah Connor", identificateur: "sarah@acme.com" }],
  sujet: "Suite à notre conversation",
  corps:    "
Bonjour Sarah, pour faire suite...
 "
};

const response = await fetch(`${UNIPILE_DSN}/api/v1/emails`, {
  méthode: "POST",
  en-têtes: {
    "X-API-KEY":     JETON_ACCES,
    "Content-Type": "application/json"
  },
  corpsJSON.filtrer(charge utile)
});

const données = await réponse.json();
console.log(données); // { objet : " EmailEnvoyé ", id_email : " ... " }

API On-Behalf vs. Transactionnelle : La différence clé

Ces deux catégories d'API d'e-mail résolvent des problèmes fondamentalement différents. Les confondre est l'erreur la plus courante que les équipes commettent lors de la spécification d'une intégration d'e-mail. Voici comment elles se comparent selon toutes les dimensions importantes.

Critères
Pour le compte de (Unipile)
Transactionnel (SendGrid, etc.)
De l'adresse
Adresse e-mail réelle de l'utilisateur
Le domaine de votre plateforme
Délivrabilité
Réputation SPF/DKIM de l'utilisateur
Réputation de l'IP d'envoi partagée
Consentement de l'utilisateur requis
Oui - identifiants OAuth 2.0 ou IMAP
Non - la plateforme est propriétaire de l'expéditeur
Suivi du dossier envoyé
Apparaît dans le dossier Envoyé de l'utilisateur
Non - infrastructure d'envoi séparée
Fil de discussion des réponses
Continuité du fil natif
Solutions de contournement manuelles pour les identifiants de message
Meilleur pour
CRM, assistants IA, outils de support, automatisation des ventes
Réinitialisations de mot de passe, reçus, campagnes marketing, notifications
Support du fournisseur
Gmail, Outlook, IMAP
SMTP indépendant du fournisseur
Quand utiliser chaque approche
Utilisez une API « au nom de » lorsque l'identité de l'expéditeur est importante pour le destinataire : prospection commerciale, suivis personnalisés, réponses de support. Utilisez une API transactionnelle lorsque la plateforme est l'expéditeur : réinitialisations de mot de passe, factures, notifications système. De nombreux produits SaaS ont besoin des deux : une API transactionnelle pour les e-mails système et une API « au nom de » pour les messages initiés par l'utilisateur. Pour les détails d'implémentation spécifiques à Gmail, voir API Gmail envoyer un e-mail guide. Pour les comptes Microsoft, voir le API d'e-mail Outlook guide.

Utiliser Unipile pour l'envoi d'e-mails en tant que soi

Unipile fournit une API unifiée unique qui abstrait Gmail, Outlook et IMAP derrière une interface cohérente. Vous écrivez une seule intégration - Unipile gère les flux OAuth spécifiques aux fournisseurs, le rafraîchissement des jetons, le routage SMTP et la gestion des erreurs pour les trois. Voici ce qui est disponible pour chaque fournisseur.

Prêt à ajouter l'envoi d'e-mails au nom de tiers à votre SaaS ?
Essai gratuit - sans carte de crédit. Commencez à envoyer en moins de 30 minutes.
Lire le guide de l'API E-mail
Fournisseurs soutenus
Gmail
Google OAuth 2.0
Envoi via l'API Gmail - prise en charge des fils de discussion complète
Comptes Google Workspace pris en charge
Pièces jointes, CC, Cci, répondre à
Actualisation automatique du token gérée par Unipile
Guide d'envoi d'e-mails avec l'API Gmail
Outlook
Microsoft OAuth 2.0
Envoie via l'API Microsoft Graph
Couvre Outlook personnel et Microsoft 365
Exchange Online entièrement pris en charge
Pièces jointes, CC, Cci, répondre à
Guide de l'API de messagerie Outlook
IMAP
Solution de repli universelle
Envoi via SMTP pour toute boîte aux lettres compatible IMAP
Couvre Yahoo, Fastmail, ProtonMail (pont IMAP), et plus encore
Même point d'accès API unifié que Gmail et Outlook
Identifiants stockés cryptés, jamais exposés à votre application
Guide de l'API IMAP
Comment démarrer en 4 étapes
1 Créer un compte Unipile sur dashboard.unipile.com et récupérez votre DSN et votre clé API.
2 Générer un lien d'authentification hébergé pour votre utilisateur. Unipile gère la redirection OAuth vers Gmail ou Outlook, ou affiche le formulaire d'identification IMAP.
3 Stocker l'identifiant du compte revenu une fois que l'utilisateur a terminé le flux. C'est l'identifiant stable pour toutes les opérations futures sur cette boîte aux lettres.
4 Appeler POST /api/v1/emails avec l'identifiant de compte et la charge utile du message. L'e-mail est envoyé depuis la boîte aux lettres de l'utilisateur, via l'infrastructure de son fournisseur.
Envoyer des e-mails en tant que (on-behalf) dès aujourd'hui Lire la documentation de l'API

API d'envoi d'e-mail au nom de l'utilisateur - FAQ

Questions fréquentes sur l'envoi d'e-mails pour le compte d'autrui avec Unipile

Oui, à condition que l'utilisateur donne explicitement son autorisation. L'envoi d'e-mails pour le compte d'autrui repose sur OAuth 2.0 (pour Gmail et Outlook) ou le partage explicite des identifiants (pour IMAP). Dans les deux cas, l'utilisateur autorise sciemment votre application à envoyer des e-mails depuis sa boîte aux lettres. C'est le même mécanisme utilisé par tous les principaux clients de messagerie et outils de productivité.

Les principales exigences en matière de conformité sont :

  • L'utilisateur doit consentir activement avant que vous n'envoyiez quoi que ce soit en son nom
  • Votre politique de confidentialité doit indiquer que vous accédez et envoyez des informations depuis la boîte aux lettres de l'utilisateur.
  • L'utilisateur doit pouvoir révoquer l'accès à tout moment (révocation OAuth ou déconnexion de compte)
  • Vous ne devez pas envoyer de contenu qui enfreint les conditions d'utilisation du fournisseur (par exemple, du spam)

Ce n'est pas légal pour envoyer depuis l'adresse de quelqu'un à son insu. Le flux de liaison basé sur OAuth d'Unipile garantit que vous obtenez toujours l'autorisation explicite de l'utilisateur avant toute opération d'envoi.

Le destinataire voit le domaine propre à l'utilisateur dans le champ De - pas le domaine de votre plateforme. C'est la proposition de valeur fondamentale de l'envoi pour le compte de quelqu'un. Par exemple, si un représentant commercial avec l'adresse john@acme.com a lié leur compte Gmail, chaque e-mail envoyé via votre CRM via Unipile affichera De : john@acme.com.

L'e-mail est expédié via le fournisseur de messagerie réel de l'utilisateur (API Gmail, Microsoft Graph ou SMTP), ce qui signifie :

  • Les enregistrements SPF réussissent car l'adresse IP de l'expéditeur est autorisée par le domaine de l'utilisateur.
  • Les signatures DKIM sont valides car le fournisseur signe avec la clé de domaine de l'utilisateur
  • L'alignement DMARC réussit pour les mêmes raisons.

Ceci est fondamentalement différent d'une API transactionnelle où vous envoyez à partir d'une infrastructure partagée et le destinataire voit le domaine de votre plateforme.

Les étendues requises dépendent du fournisseur. Unipile gère l'écran de consentement OAuth automatiquement – vos utilisateurs voient une boîte de dialogue de permission Google ou Microsoft standard. Les étendues exactes demandées sont :

  • Gmail : l'étendue de l'API Gmail qui permet d'envoyer des messageshttps://mail.google.com/ ou le plus limité gmail.envoyer portée si vous n'avez besoin que d'un accès en envoi)
  • Outlook / Microsoft 365 : Microsoft Graph Mail.Send portée, plus Mail.ReadWrite si vous avez également besoin de lire ou de synchroniser la boîte de réception
  • IMAP : l'utilisateur fournit son nom d'hôte IMAP, son port, son nom d'utilisateur et soit son mot de passe, soit un mot de passe spécifique à l'application (requis pour les comptes dont l'authentification à deux facteurs est activée)

Les utilisateurs peuvent révoquer ces autorisations à tout moment depuis les paramètres de sécurité de leur compte Google ou Microsoft, ou en déconnectant le compte lié à l'intérieur de votre produit.

Oui. Toute boîte aux lettres pouvant être authentifiée via des identifiants OAuth ou IMAP peut être liée en tant que compte Unipile. Cela inclut :

  • Boîtes aux lettres partagées dans Microsoft 365 (par exemple. support@company.com) - lié via un compte de service avec les autorisations déléguées appropriées
  • Boîtes aux lettres partagées et adresses de groupe Google Workspace avec autorisations d'envoi configurées
  • Toute adresse e-mail alias gérée par une boîte aux lettres accessible via IMAP

Vous pouvez également personnaliser la nom d'affichage dans le champ De en utilisant le from paramètre dans la charge utile de l'API, sans modifier l'adresse d'envoi sous-jacente.

Unipile gère le renouvellement automatique des jetons pour les comptes Gmail et Outlook. Les jetons d'accès OAuth expirent généralement au bout d'une heure, mais le jeton de renouvellement a une longue durée de vie. Lorsque Unipile détecte un jeton d'accès expiré avant une opération d'envoi, il en demande silencieusement un nouveau en utilisant le jeton de renouvellement stocké – votre application ne voit jamais cela se produire et l'appel d'envoi réussit normalement.

La seule fois où vous devez inviter l'utilisateur à se réauthentifier est s'il a accès révoqué manuellement à partir des paramètres de leur compte Google ou Microsoft. Unipile signale cela comme un changement d'état de compte que vous pouvez détecter via un webhook ou en interrogeant le point de terminaison du compte.

Vous avez encore des questions ? Notre équipe est là pour vous aider.

Parler à un expert
fr_FRFR
en_USEN es_ESES de_DEDE it_ITIT pt_BRBR nl_NLNL pl_PLPL tr_TRTR fr_FRFR