LinkedIn
Instagram
WhatsApp
Telegram
Google Agenda
Rejoindre la communauté SlackPortées de l'API Gmail expliquées : Choisissez le Droits d'accès pour votre application
Toutes les portées de l'API Gmail répertoriées : de gmail.lecture seule à mail.google.com. Familiarisez-vous avec les trois niveaux de sensibilité, choisissez le champ d'application minimal dont votre application a réellement besoin et mettez en place votre flux OAuth plus rapidement.
// Demander les étendues des API Gmail dans le flux OAuth
const PORTÉES = [
'https://www.googleapis.com/auth/gmail.readonly',
'https://www.googleapis.com/auth/gmail.send',
'https://www.googleapis.com/auth/gmail.labels',
];
const authUrl = oauth2Client.générerURLAuthentification({
type_accès : 'hors ligne',
portée : SCOPES,
Veuillez fournir le texte que vous souhaitez traduire en français. 'consentement',
});Que sont les champs d'application de l'API Gmail ?
Avant d'écrire la moindre ligne de code OAuth, vous devez comprendre ce que sont les champs d'application de l'API Gmail et pourquoi le choix d'un champ d'application inadapté peut empêcher votre application d'être mise en production. Cette section vous fournit les connaissances de base en moins de deux minutes.
Portées de l'API Gmail Il s'agit de chaînes d'autorisation OAuth 2.0 qui définissent précisément les ressources Gmail auxquelles votre application peut accéder au nom d'un utilisateur. Lorsqu'un utilisateur autorise votre application, Google affiche un écran de consentement répertoriant les champs d'application de l'API Gmail demandés par votre application. L'utilisateur accorde ou refuse l'accès en fonction de ces champs d'application. Une fois l'accès accordé, votre jeton d'accès est limité strictement aux actions autorisées par ces champs d'application, et rien de plus.
Les champs d'application de l'API Gmail définissent des limites strictes quant aux actions que votre jeton peut effectuer. Même si votre serveur est compromis, un pirate disposant d'un gmail.lecture seule Le jeton ne peut ni envoyer ni supprimer d'e-mails. Les étendues sont appliquées côté serveur par Google.
Les champs d'application restreints de l'API Gmail exigent que votre application réussisse l'évaluation de sécurité de Google avant de pouvoir les utiliser en production avec plus de 100 utilisateurs de test. Un mauvais choix de champ d'application peut ajouter des semaines ou des mois à votre calendrier de lancement.
Demander plus d'autorisations pour l'API Gmail que ce dont votre application a besoin déclenche un avertissement indiquant : " Cette application souhaite un accès étendu à votre compte Google ". Des périmètres d'accès minimaux à l'API Gmail permettent d'afficher un écran de consentement plus simple, ce qui améliore le taux de conversion et renforce la confiance des utilisateurs.
Ignorer complètement la gestion du périmètre. Unipile gère en interne l'OAuth et les champs d'application de Gmail : votre équipe peut ainsi se concentrer sur la logique métier, et non sur les chaînes d'autorisation.
Construisez-le avec UnipileLes 3 niveaux de sensibilité expliqués
Google classe toutes les étendues de l'API Gmail en 3 niveaux de sensibilité. Chaque niveau détermine les exigences de vérification avant que votre application ne puisse être mise en production. Comprendre cette classification est la décision la plus importante que vous prendrez lors de la planification de votre intégration Gmail.
Le niveau de risque le plus bas. Ces portées accèdent à des données Gmail limitées et non personnelles. Google ne requiert pas d'évaluation de sécurité formelle pour les utiliser en production.
Catégorie de risque moyen. Ces scopes accèdent aux données des messages Gmail susceptibles de divulguer des informations personnelles. Une vérification supplémentaire est requise avant toute utilisation en production.
Niveau de risque le plus élevé. Ces applications accordent un accès étendu ou sensible aux données Gmail. Google exige une évaluation de sécurité officielle réalisée par un auditeur tiers agréé.
| Critères | Non-sensible | Sensible | Accès restreint |
|---|---|---|---|
| Accède au corps du message | Non | Parfois | Oui, |
| Évaluation de sécurité requise | Non | Non | Oui, |
| Évaluation de l'application requise | Oui, | Oui, | Oui, |
| Recertification annuelle | Non | Non | Oui, |
| Niveau d'avertissement de l'écran de consentement | Standard | Standard + divulgation | Avertissement d'accès large |
| Coût typique de vérification | Gratuit | Gratuit | ~1 TP4T500/an (évaluateur) |
Référence complète des champs d'application de l'API Gmail
La liste complète des portée de l'API Gmail, regroupées par niveau de sensibilité. Utilisez ce tableau comme référence unique lors du choix des autorisations de l'API Gmail pour votre application. Les portées marquées "2026" reflètent les derniers ajouts à la liste des portée de Google.
| URI de portée | Niveau d'accès | Ce qu'il accède à | Quand utiliser |
|---|---|---|---|
| gmail.addons.current.action.compose | Non-sensible | Permet aux extensions de composer et d'envoyer des e-mails lors d'une action de composition | Extensions Gmail qui rédigent ou envoient des e-mails au nom de l'utilisateur dans la fenêtre de composition |
| gmail.addons.current.message.action | Non-sensible | Permet aux extensions d'afficher l'e-mail actuel lors d'une action de message | Modules complémentaires Gmail qui réagissent à une action de message (archivage, étiquetage) dans le contexte du message |
| libellés gmail 2026 | Non-sensible | Voir et modifier les étiquettes (créer, renommer, supprimer), mais pas le contenu des messages | Applications qui organisent les e-mails avec des étiquettes sans avoir besoin de lire le corps des messages |
| URI de portée | Niveau d'accès | Ce qu'il accède à | Quand utiliser |
|---|---|---|---|
| métadonnées du message.gmail.addons.current | Sensible | En-têtes et métadonnées d'e-mail (De, À, Objet, Date) dans le contexte d'un module complémentaire - pas le corps du message | Modules complémentaires qui affichent des informations contextuelles basées sur l'expéditeur ou le sujet sans lire le corps du message |
| gmail.addons.current.message.readonly | Sensible | Accès complet en lecture à l'e-mail actuel, y compris le corps et les pièces jointes, dans le contexte du module complémentaire | Modules complémentaires qui analysent ou extraient des données du message actuellement ouvert |
| gmail.envoyer | Sensible | Envoyer un e-mail au nom de l'utilisateur authentifié - aucun accès en lecture ou modification | Applications qui envoient uniquement des e-mails transactionnels ou de prospection et qui n'ont pas besoin de lire la boîte de réception |
| URI de portée | Niveau d'accès | Ce qu'il accède à | Quand utiliser |
|---|---|---|---|
| mail.google.com/ | Accès restreint | Accès complet à la boîte aux lettres : lire, composer, envoyer et supprimer définitivement les e-mails et les paramètres | Seulement lorsque vous avez besoin de toutes les fonctionnalités de Gmail dans un seul périmètre - typiquement pour les intégrations héritées |
| gmail.lecture seule | Accès restreint | Accès en lecture seule à tous les messages, fils, étiquettes et paramètres - impossible d'envoyer ou de modifier | Outils d'analyse, d'archivage, de recherche ou d'intelligence de messagerie qui ne lisent que les données de la boîte de réception |
| gmail.rediger | Accès restreint | Créer et gérer des brouillons, et envoyer ces brouillons - aucun accès aux e-mails existants | Outils de gestion de brouillons, compositeurs d'e-mails, ou applications qui mettent des e-mails en file d'attente avant de les envoyer |
| gmail.insérer 2026 | Accès restreint | Insérer des messages dans la boîte aux lettres Gmail uniquement - impossible de lire ou d'envoyer des e-mails existants | Outils ou systèmes de migration qui importent des e-mails dans Gmail à partir de sources externes |
| gmail.modifier | Accès restreint | Lire, composer, envoyer et gérer des e-mails et des libellés - impossible de supprimer définitivement | Clients d'e-mail complets, outils de synchronisation CRM, intégrations de centre d'aide nécessitant la lecture+envoi+Étiquetage |
| gmail.metadata | Accès restreint | En-têtes et étiquettes uniquement - pas d'accès au corps ou aux pièces jointes des e-mails | Applications qui classent ou acheminent les e-mails en fonction des métadonnées sans lire le contenu privé |
| paramètres de gmail.basiques | Accès restreint | Gérer les paramètres de base de Gmail : filtres, règles de transfert, paramètres POP/IMAP | Outils de productivité de messagerie qui configurent le routage ou le filtrage de Gmail pour le compte des utilisateurs |
| partages des paramètres gmail | Accès restreint | Gestion des paramètres sensibles : alias d'envoi, délégués, répondeurs d'absence (administrateur de domaine uniquement) | Outils d'administration de l'espace de travail uniquement - nécessite des privilèges d'administrateur de domaine pour activer |
Ne gérez pas ces scopes de l'API Gmail manuellement. L'intégration Gmail d'Unipile gère automatiquement les requêtes de portée OAuth, le rafraîchissement des jetons et les flux de réautorisation sur les comptes liés de vos utilisateurs.
Créez votre application GmailQuelle portée d'API Gmail vous faut-il ?
Le principe le plus important dans la sélection des scopes de l'API Gmail est le principe d'accès minimum : demandez uniquement les permissions de l'API Gmail dont votre application a réellement besoin. Ce tableau met en correspondance les cas d'utilisation courants avec le scope minimum recommandé, vous aidant ainsi à éviter les frais de vérification inutiles et à protéger la confiance des utilisateurs.
| Cas d'utilisation | Portée minimale | Niveau de vérification | Notes |
|---|---|---|---|
| Envoyer des courriels uniquement (ne pas lire la boîte de réception) | gmail.envoyer | Sensible | Idéal pour les outils transactionnels ou de prospection. Pas d'accès aux messages existants. |
| Lire la boîte de réception pour les analyses ou rechercher | gmail.lecture seule | Accès restreint | Accès en lecture intégral à tous les messages et paramètres. Nécessite une évaluation de sécurité annuelle. |
| Client de messagerie complet (lire + envoyer + étiqueter) | gmail.modifier | Accès restreint | Préféré par mail.google.com/ car il exclut la suppression permanente. Couvre la plupart des cas d'utilisation CRM et de helpdesk. |
| Archiver ou sauvegarder des courriels de manière permanente | mail.google.com/ | Accès restreint | N'utilisez que lorsque vous avez vraiment besoin d'un accès en suppression. Déclenche l'avertissement de consentement Google le plus large. |
| Organiser les étiquettes uniquement | libellés gmail | Non-sensible | Nouveau en 2026. Permissions minimales pour la gestion des étiquettes sans lecture des messages. |
| Gestion des brouillons (file d'attente avant envoi) | gmail.rediger | Accès restreint | Accès aux brouillons et capacité d'envoi, mais pas d'accès en lecture aux messages existants. |
| Routage ou catégorisation des métadonnées | gmail.metadata | Accès restreint | En-têtes et étiquettes seulement - aucun accès au corps. Idéal pour les moteurs de routage qui respectent la confidentialité des messages. |
| Migration / importation d'e-mails dans Gmail | gmail.insérer | Accès restreint | Nouveau en 2026. Accès en insertion seulement - alternative mieux définie à mail.google.com/ pour importer des outils. |
| Configurer les filtres et la redirection de Gmail | paramètres de gmail.basiques | Accès restreint | Gérer les filtres, les étiquettes, les règles de transfert. Pas d'accès au corps des messages. |
| Add-on Gmail : afficher le contexte de l'expéditeur | métadonnées du message.gmail.addons.current | Sensible | En-têtes uniquement dans le contexte des modules complémentaires. Évite l'accès complet au message. |
Vous pouvez combiner plusieurs portées de l'API Gmail dans une seule requête OAuth (par exemple, gmail.envoyer + libellés gmail), mais chaque portée ajoute à la divulgation de l'écran de consentement. Auditez toujours votre liste de portées avant de passer en production. Si vous créez un produit de synchronisation Gmail complet, Guide de l'API OAuth pour les e-mails couvre le flux complet, y compris la gestion des jetons et la réautorisation des étendues.
Des semaines de vérification.
Utilisez La clé d'Unipile et commencez maintenant.
Ne perdez pas de clients en attendant les avis Google. Connectez les comptes Gmail en 5 minutes grâce à nos identifiants développeur pré-vérifiés.
Vérification de portée restreinte : ce que cela signifie pour votre application
Si votre application nécessite une portée restreinte de l'API Gmail, y compris gmail.lecture seule, gmail.modifierou mail.google.com/ - vous devez terminer le processus d'évaluation de la sécurité de Google avant de passer à plus de 100 utilisateurs test. Voici à quoi ressemble ce processus et comment en minimiser les contraintes.
Créez un projet, activez l'API Gmail et configurez l'écran de consentement OAuth. Remplissez tous les champs requis : nom de l'application, e-mail de support, domaines autorisés et URL de la politique de confidentialité. Cette étape est obligatoire pour tout niveau de périmètre de l'API Gmail.
Sur l'écran de consentement OAuth, cliquez sur " Préparer la vérification ". Déclarez chaque périmètre de l'API Gmail restreint et fournissez une justification expliquant pourquoi votre application en a besoin. L'équipe de Google examine cela avant de vous orienter vers un évaluateur de sécurité.
Google confie les applications à portée restreinte à un évaluateur agréé (Leviathan Security, Coalfire, etc.). L'évaluation coûte environ 1 450 £ par an. Vous devez fournir une démonstration, expliquer vos pratiques en matière de traitement des données et passer avec succès un examen technique de votre implémentation OAuth.
Les champs d'application restreints de l'API Gmail nécessitent une recertification annuelle. Si vous manquez la fenêtre de renouvellement, Google peut révoquer l'accès de votre application à la production. Planifiez ce coût récurrent et ce cycle de conformité dès le premier jour de l'architecture de votre intégration Gmail.
Choisir gmail.envoyer sur gmail.modifier quand votre application envoie uniquement des e-mails et n'a pas besoin de lire la boîte de réception. gmail.envoyer est une portée sensible (non restreinte) et saute complètement l'évaluation de sécurité.
Utilisez gmail.metadata au lieu de gmail.lecture seule si votre application achemine ou catégorise des e-mails sans lire le contenu du corps. Vous avez toujours besoin d'une vérification, mais la portée est plus restreinte et plus facile à justifier auprès de Google.
Utilisez une plateforme qui détient déjà la vérification Google. Lorsque vous construisez sur Intégration Gmail d'Unipile, votre application bénéficie des identifiants OAuth pré-vérifiés d'Unipile, vous n'avez donc pas besoin de passer vous-même par l'évaluation des champs d'application restreints. C'est la voie la plus rapide vers la production pour la plupart des produits SaaS. Pour connaître les identifiants complets et le guide de vérification, consultez notre Guide de vérification des applications Google OAuth.
Restez dans la fenêtre de test des 100 utilisateurs pendant le développement initial. Vous pouvez tester des scopes restreints de l'API Gmail avec jusqu'à 100 comptes Google sans accomplir la vérification complète. Ajoutez des comptes de test dans les paramètres de l'écran de consentement OAuth de la Google Cloud Console.
Si votre cas d'utilisation est interne à une organisation Google Workspace et que vous avez besoin d'accéder à plusieurs boîtes aux lettres sans consentement individuel, un compte de service avec délégation d'administration est l'alternative à considérer - voir notre Compte de service Gmail et guide DWD.
Ignorez complètement le processus de vérification Google. L'OAuth Gmail hébergé d'Unipile est déjà vérifié pour lesitized API Gmail restreintes - vos comptes liés se connectent immédiatement sans évaluation supplémentaire.
Commencez à construire dès aujourd'huiComment demander des étendues Gmail dans votre flux OAuth
Une fois que vous savez quels champs Gmail OAuth votre application nécessite, vous les déclarez lors de la génération de l'URL d'autorisation. Voici des exemples de code fonctionnels en Node.js et Python montrant exactement comment passer les autorisations de l'API Gmail à l'écran de consentement OAuth.
// Node.js — Portées de l’API Gmail dans le flux OAuth
// Utilise google-auth-library (client officiel de Google)
const { OAuth2Client } = require('bibliothèque-d'authentification-google');
const oauth2Client = new OAuth2Client(
process.env.GOOGLE_CLIENT_ID,
process.env.GOOGLE_CLIENT_SECRET,
process.env.REDIRECT_URI
);
// Définir les portées de l'API Gmail dont votre application a besoin
// Principe : demander le périmètre minimum requis
const PORTÉES = [
'https://www.googleapis.com/auth/gmail.readonly', // restreint
'https://www.googleapis.com/auth/gmail.send', // sensible
'https://www.googleapis.com/auth/gmail.labels', // non-sensible
];
// Générer l'URL d'autorisation OAuth
const authUrl = oauth2Client.générerURLAuthentification({
type_accès : 'hors ligne', // requête de renouvellement de jeton
portée : PORTÉES,
Veuillez fournir le texte que vous souhaitez traduire en français. 'consentement', // forcer le consentement pour obtenir le jeton de rafraîchissement
});
console.log('Rediriger l'utilisateur vers :', url_authentification);
// Après que l'utilisateur ait autorisé, échanger le code contre des jetons
async function getTokens{
const { jetons } = await oauth2Client.jeton(code);
oauth2Client.définirLesIdentifiantsjetons ;
return jetons;
}# Python — Domaines d'application de l'API Gmail dans le flux OAuth
# utilise google-auth-oauthlib (bibliothèque officielle de Google)
from google_auth_oauthlib.flow import FluxApplicationInstallée
from google.oauth2.credentials import Indentifications
from google.auth.transport.requests import Requête
import système d'exploitation
# Définir les champs d'application de l'API Gmail : ne demandez que ce dont vous avez besoin
PORTÉES = [
'https://www.googleapis.com/auth/gmail.readonly', # (accès restreint)
'https://www.googleapis.com/auth/gmail.send', sensible au #
'https://www.googleapis.com/auth/gmail.labels', # non sensible
]
déf obtenir_identifiants_gmail():
identifiants = Aucun
# Charger le jeton existant s'il est disponible
si os.path.existe('jeton.json'):
crédits = Credentials.depuis_fichier_utilisateur_autorisé(
'jeton.json', PORTÉES
)
# Actualiser ou demander de nouveaux identifiants
sinon identifiants ou pas crédits.valide :
si identifiants et crédits.expirés et credss.jeton_rafraîchissement :
identifiants.Actualiser(Requête())
sinon:
# : Afficher l'écran de consentement OAuth avec les champs d'application déclarés
flux = FluxInstalléApplication.from_client_secrets_file(
'credentials.json', PORTÉES
)
créds = flow.exécuter_serveur_local(port=0)
# : jeton de persistance pour les exécutions futures
avec ouvrir('jeton.json', 'w') en tant que jeton :
jeton.écrire(crédits.vers_json())
return identifiantsImportant : Le consentement' (Node.js) ou exécuter_serveur_local l'appel (Python) force l'affichage de l'écran de consentement Google même si l'utilisateur a déjà autorisé. Ceci est requis pour obtenir de manière fiable un token_rafraîchissement. Sans jeton d'actualisation, votre jeton d'accès expire après 1 heure et les utilisateurs doivent ré-autoriser. Pour un guide complet sur la gestion de l'actualisation des jetons et la ré-autorisation des champs d'application, consultez le Guide de l'API OAuth pour les e-mails et le Documentation Google OAuth Unipile.
Principe de portée minimale et de conformité
Le principe du périmètre minimum n'est pas seulement une recommandation de Google ; il affecte directement votre posture de conformité RGPD et SOC 2. Demander des autorisations excessives à l'API Gmail crée des risques d'exposition de données inutiles et complique vos accords de traitement des données avec les utilisateurs finaux.
Le principe de portée minimale reflète le concept de sécurité du moindre privilège. Votre intégration de l'API Gmail devrait demander la périmètre de l'API Gmail à autorisation minimale qui active la fonctionnalité. Si votre CRM n'envoie que des e-mails de suivi, gmail.envoyer est suffisant gmail.modifier est excessif et crée un risque inutile.
Google affiche vos étendues d'API Gmail déclarées directement sur l'écran de consentement. Des étendues plus larges déclenchent un langage plus alarmant (" Cette application souhaite accéder à l'intégralité de votre boîte de réception Gmail "). Les étendues OAuth minimales pour Gmail sont généralement celles qui sont strictement nécessaires pour les fonctionnalités que vous souhaitez offrir. Voici quelques étendues courantes et minimales, souvent utilisées pour une authentification et des besoins de base : * **`https://www.googleapis.com/auth/userinfo.email`**: Permet d'accéder à l'adresse e-mail de l'utilisateur. C'est souvent le minimum requis pour identifier l'utilisateur. * **`https://www.googleapis.com/auth/userinfo.profile`**: Permet d'accéder aux informations de profil de base de l'utilisateur (nom, image de profil, etc.). Si vous avez besoin d'interagir avec les e-mails eux-mêmes, voici quelques étendues minimales supplémentaires qui dépendent de ce que vous voulez faire : * **Pour lire les e-mails (sans modification) :** * `https://www.googleapis.com/auth/gmail.readonly` : Permet de lire les messages et les en-têtes des messages de l'utilisateur. * **Pour envoyer des e-mails :** * `https://www.googleapis.com/auth/gmail.send` : Permet d'envoyer des e-mails au nom de l'utilisateur. * **Pour gérer les brouillons (créer, lire, supprimer) :** * `https://www.googleapis.com/auth/gmail.drafts` : Permet de créer, lire, supprimer et envoyer des brouillons de messages. **Principes clés pour des étendues minimales :** 1. **Principe du moindre privilège :** N'accordez que les autorisations strictement nécessaires à votre application. 2. **Demande d'étendues au besoin :** Vous pouvez commencer par demander des étendues minimales (comme `userinfo.email`) et demander des étendues supplémentaires plus tard, lorsque l'utilisateur utilise une fonctionnalité qui les nécessite. Cela améliore l'expérience utilisateur et la confiance. 3. **Réviser régulièrement :** Vérifiez périodiquement les étendues demandées par votre application pour vous assurer qu'elles sont toujours nécessaires. **Exemple concret d'une application simple qui ne fait que lire l'adresse e-mail de l'utilisateur et affiche son nom :** * `https://www.googleapis.com/auth/userinfo.email` * `https://www.googleapis.com/auth/userinfo.profile` Dans la plupart des cas, vous utiliserez l'API Google Identity Toolkit (ou des bibliothèques similaires) pour gérer l'authentification OAuth 2.0, qui inclut souvent ces étendues de base pour l'identité de l'utilisateur. Si vous interagissez directement avec l'API Gmail, vous devrez spécifier les étendues appropriées dans votre configuration OAuth. créer des écrans de consentement plus simples et moins intimidants, ce qui permet généralement d'améliorer les taux de conversion des autorisations de 15 à 30 % dans les flux OAuth destinés aux utilisateurs.
Voir notre étape par étape Guide de configuration de l'écran de consentement OAuth pour la procédure de configuration complète, y compris la sélection de la portée et le choix Interne vs Externe.
Votre politique de confidentialité et votre DPA (accord de traitement des données) doivent refléter avec précision quelles données Gmail votre application accède. Si votre application demande gmail.lecture seule mais votre politique de confidentialité ne mentionne que "l'envoi d'e-mails", vous avez une lacune dans votre documentation RGPD. Faites correspondre vos champs d'application de l'API Gmail déclarés à vos pratiques de données publiées.
Les exigences de portée de l'API Gmail évoluent au fur et à mesure que des fonctionnalités sont ajoutées ou supprimées. Effectuez un audit de portée à chaque version majeure : supprimez toutes les autorisations de l'API Gmail dont votre ensemble de fonctionnalités actuel n'a plus besoin. Les portées inutilisées dans votre déclaration OAuth constituent un passif de conformité : elles représentent un accès aux données que vous affirmez avoir besoin mais que vous n'utilisez pas.
gmail.metadata au lieu de gmail.lecture seule lorsque l'accès au corps n'est pas nécessaire
Intégration Gmail prête pour la conformité. L'implémentation de l'API Gmail par Unipile suit par défaut le principe du périmètre minimum - votre application ne demande que les scopes OAuth Gmail nécessaires aux fonctionnalités que vous activez.
Créer des applications Gmail conformesScopes de l'API Gmail avec Unipile : Évitez la complexité des scopes
La gestion manuelle des scopes de l'API Gmail implique de naviguer dans le processus de vérification de Google, de gérer le rafraîchissement des tokens lors des changements de scopes, et de mettre à jour votre documentation de traitement des données chaque fois que vous ajoutez une fonctionnalité. Unipile abstrait entièrement cela, votre équipe se concentre sur le produit, pas sur les chaînes d'autorisations.
Gmail
Outlook
IMAP
Unipile détient la vérification OAuth de Google pour les scopes restreints de l'API Gmail. Votre application en bénéficie immédiatement sans avoir à réaliser une évaluation de sécurité distincte. La recertification annuelle est gérée par l'équipe de conformité d'Unipile.
Unipile gère le renouvellement des jetons OAuth, la validation des scopes et les flux de ré-autorisation pour chacun des comptes liés de vos utilisateurs. Lorsque Google met à jour ses exigences de scope, Unipile s'adapte sans casser votre intégration.
Les mêmes appels d'API Unipile fonctionnent pour Gmail, Outlook et IMAP. Vous écrivez votre fonctionnalité e-mail une seule fois et elle fonctionne sur tous les fournisseurs, sans gestion de portée d'API Gmail distincte par fournisseur, sans branches de code spécifiques au protocole.
Pour les équipes qui ont besoin d'utiliser leurs propres identifiants Google, Unipile prend en charge la configuration OAuth en marque blanche. Vos utilisateurs voient votre marque sur l'écran de consentement pendant qu'Unipile gère la déclaration des scopes et le cycle de vie des jetons en arrière-plan.
L'intégration Gmail d'Unipile ne demande que les autorisations d'API Gmail nécessaires aux fonctionnalités que vous activez. Lire, envoyer, synchroniser, chaque capacité correspond à la portée la plus restreinte possible, afin de maintenir un profil de conformité clair.
Recevez les nouveaux messages Gmail à mesure qu'ils arrivent via les webhooks Unipile. Pas de polling, pas de gestion manuelle des abonnements Gmail Pub/Sub. Fonctionne avec le même jeton OAuth que votre application utilise déjà pour d'autres opérations de l'API Gmail.
Questions fréquemment posées sur les scopes de l'API Gmail
Questions fréquentes sur les champs d'application de l'API Gmail, les champs d'application OAuth Gmail et le processus de vérification - réponses concises pour les développeurs créant des intégrations Gmail.
gmail.lecture seule et gmail.modifier sont des étendues d'API Gmail restreintes. gmail.lecture seule fournit un accès en lecture seule à tous les messages, fils de discussion, étiquettes et paramètres - votre application ne peut rien envoyer ni modifier. gmail.modifier ajoute la capacité de lire, composer et envoyer des e-mails, ainsi que de gérer les libellés, mais exclut la suppression permanente de messages. Si votre application a besoin de lire et d'envoyer sans supprimer, gmail.modifier est préféré au plus large mail.google.com/ champ. Voir notre comment lire les e-mails des utilisateurs via une API unifiée.libellés gmail nécessite uniquement une révision standard de l'application OAuth. Les scopes sensibles tels que gmail.envoyer exigent le processus de vérification OAuth de Google mais pas d'évaluation de sécurité. Portées restreintes – y compris gmail.lecture seule, gmail.modifier, gmail.rediger, gmail.metadata, gmail.insérer, ou encore mail.google.com/ - exigent l'intégralité du processus d'évaluation. Plus d'informations à ce sujet dans notre Modèles d'API de messagerie sécurisée pour les secteurs réglementés.gmail.modifier la portée accorde un accès en lecture, composition, envoi et gestion des étiquettes à Gmail, mais exclut la possibilité de supprimer définitivement les messages. C'est la portée restreinte recommandée pour les intégrations de messagerie complètes telles que Synchronisation d'e-mails CRM, outils de helpdesk et clients de messagerie qui doivent à la fois lire et envoyer des messages. Il est préférable à mail.google.com/ parce qu'il limite l'exposition des données en excluant la fonctionnalité de suppression définitive. Connexes : envoyer un e-mail au nom des utilisateurs.portée paramètre. Par exemple, vous pouvez demander gmail.envoyer + libellés gmail ensemble. Cependant, la combinaison de scopes augmente les autorisations affichées sur l'écran de consentement de Google et peut déclencher des exigences de vérification supplémentaires si un scope combiné est restreint. Demandez toujours uniquement la combinaison minimale dont votre application a réellement besoin. Pour le côté Microsoft, voir Étendues OAuth Microsoft Graph équivalentes. Pour tester, consultez notre comment tester les scopes Gmail dans OAuth Playground.gmail.metadata scope est une portée limitée de l'API Gmail qui accorde l'accès à en-têtes et étiquettes d'e-mail uniquement, sans aucun accès au contenu du corps de l'e-mail ou aux pièces jointes. Il est utile pour les moteurs de routage, les systèmes de catégorisation ou les outils d'analyse qui traitent les e-mails en fonction de l'expéditeur, du destinataire, de l'objet ou des libellés sans lire le contenu des messages privés. Bien qu'il soit restreint, il a une empreinte de données plus restreinte que gmail.lecture seule et peut-être plus facile à justifier lors d'une évaluation de sécurité. Nous approfondissons dans notre API de synchronisation d'e-mails pour la synchronisation complète de la boîte de réception.gmail.envoyer portée est une Portée d'API Gmail sensible qui permet à votre application d'envoyer des e-mails au nom d'un utilisateur authentifié, sans accorder d'accès en lecture ou en modification aux messages existants. C'est la portée minimale recommandée pour les applications qui envoient uniquement des e-mails : outils de prospection, systèmes de notification ou automatisation des suivis. En utilisant gmail.envoyer au lieu de gmail.modifier évite complètement l'évaluation de sécurité du périmètre restreint, accélérant considérablement votre chemin vers la production. Voir notre guide API d'envoi d'e-mails dédié.
FR 
EN 
ES 
DE 
IT 
BR 
NL 
PL 
TR