LinkedIn
Instagram
WhatsApp
Telegram
Google Agenda
Rejoindre la communauté SlackLes champs d'application de l'API Gmail expliqués : Choisissez le Droits d'accès pour votre application
Chaque portée de l'API Gmail documentée : de gmail.lecture seule à mail.google.com. Comprenez les 3 niveaux de sensibilité, choisissez la portée minimale dont votre application a réellement besoin et expédiez 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',
});Quels sont les scopes 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 choisir le mauvais peut empêcher votre application d'être mise en production. Cette section vous donne les connaissances fondamentales en moins de deux minutes.
Scopes de l'API Gmail sont des 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 que votre application a demandés. L'utilisateur accorde ou refuse l'accès en fonction de ces champs d'application. Une fois accordé, votre jeton d'accès est limité aux actions exactes que ces champs d'application autorisent, et rien de plus.
Les champs d'application de l'API Gmail créent une limite stricte à ce que votre jeton peut faire. Même si votre serveur est compromis, un attaquant 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 étendues Gmail API restreintes 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 d'étendue peut ajouter des semaines ou des mois au calendrier de lancement de votre produit.
Demander plus d'autorisations pour l'API Gmail que votre application n'en a besoin déclenche un avertissement "Cette application souhaite un accès étendu à votre compte Google". Des portées minimales de l'API Gmail produisent un écran de consentement plus simple, augmentant la conversion et la confiance des utilisateurs.
Sauter la gestion de la portée entièrement. Unipile gère l'authentification OAuth et les scopes Gmail en interne – votre équipe se concentre sur la logique produit, pas sur les chaînes d'autorisations.
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 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 demande pas d'évaluation de sécurité formelle pour les utiliser en production.
Niveau de risque moyen. Ces portées accèdent aux données des messages Gmail qui pourraient exposer des informations personnelles. Une vérification supplémentaire est requise avant l'utilisation en production.
Niveau de risque le plus élevé. Ces accès accordent des autorisations étendues ou sensibles aux données Gmail. Google exige une évaluation de sécurité formelle par un auditeur tiers approuvé.
| 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 étendues 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 pour 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 champs d'application de l'API Gmail est le principe du minimum d'accès : demandez uniquement les autorisations de l'API Gmail dont votre application a réellement besoin. Ce tableau met en correspondance les cas d'utilisation courants avec le champ d'application minimum recommandé, vous aidant à éviter les frais de vérification inutiles et à protéger la confiance des utilisateurs.
| Cas d'utilisation | Périmètre minimum | Niveau de vérification | Notes |
|---|---|---|---|
| Envoyer des e-mails 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 l'analytique ou la recherche | gmail.lecture seule | Accès restreint | Accès complet en lecture à tous les messages et paramètres. Nécessite une évaluation annuelle de la sécurité. |
| Client de messagerie complet (lire + envoyer + étiqueter) | gmail.modifier | Accès restreint | Préféré à mail.google.com/ car il exclut la suppression définitive. Couvre la plupart des cas d'utilisation des CRM et des centres d'assistance. |
| Archiver ou sauvegarder les courriels de manière permanente | mail.google.com/ | Accès restreint | Utiliser uniquement lorsque vous avez réellement besoin d'un accès en suppression. Déclenche l'avertissement de consentement Google le plus général. |
| Organiser les étiquettes seulement | 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 uniquement - pas d'accès au corps. Idéal pour les moteurs de routage qui respectent la confidentialité des messages. |
| Migration / importation d'e-mails vers Gmail | gmail.insérer | Accès restreint | Nouveau en 2026. Accès en insertion uniquement - alternative mieux définie à mail.google.com/ pour importer des outils. |
| Configurer les filtres et le transfert de Gmail | paramètres de gmail.basiques | Accès restreint | Gérer les filtres, les libellés, les règles de transfert. Accès au corps des messages impossible. |
| Module complémentaire Gmail : afficher le contexte de l'expéditeur | métadonnées du message.gmail.addons.current | Sensible | En-têtes uniquement dans le contexte du module complémentaire. Évite l'accès complet à la lecture des messages. |
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 périmètre s'ajoute à la divulgation de l'écran de consentement. Auditez toujours votre liste de périmètres avant de passer en production. Si vous créez un produit de synchronisation Gmail complet, le Guide de l'API OAuth pour les e-mails couvre le flux complet, y compris la gestion des jetons et la réautorisation d'une portée.
Vérification de portée restreinte : ce que cela signifie pour votre application
Si votre application a besoin d'une portée API Gmail restreinte - y compris gmail.lecture seule, gmail.modifierou mail.google.com/ Vous devez terminer le processus d'évaluation de sécurité de Google avant de passer en production au-delà de 100 utilisateurs test. Voici à quoi ressemble ce processus et comment en minimiser la charge.
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 requise pour tous les niveaux d'étendue de l'API Gmail.
Sur l'écran de consentement OAuth, cliquez sur "Préparer pour la vérification". Déclarez chaque champ d'application Gmail API 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 scopes 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 en production de votre application. Prévoyez 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 lorsque 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 ignore 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 à passer vous-même par l'évaluation des périmètres restreints. C'est le chemin le plus rapide vers la production pour la plupart des produits SaaS.
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.
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.
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 conformesPortées de l'API Gmail avec Unipile : Évitez la complexité des portées
Gérer les étendues de l'API Gmail manuellement signifie naviguer dans le processus de vérification de Google, gérer le renouvellement des jetons lors des modifications d'étendues et mettre à jour votre documentation de traitement des données à chaque ajout de fonctionnalité. Unipile abstrait cela entièrement, votre équipe se concentre sur le produit, pas sur les chaînes d'autorisation.
Gmail
Outlook
IMAP
Unipile détient la vérification OAuth de Google pour les champs d'application restreints de l'API Gmail. Votre application bénéficie immédiatement sans avoir à effectuer 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 scopes, Unipile s'adapte sans interrompre votre intégration.
Les mêmes appels API Unipile fonctionnent pour Gmail, Outlook et IMAP. Vous écrivez votre fonctionnalité d'e-mail une seule fois et elle fonctionne sur tous les fournisseurs, sans gestion de périmètre 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 tandis 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 de l'API Gmail nécessaires aux fonctionnalités que vous activez. Lire, envoyer, synchroniser, chaque capacité correspond à la portée la plus étroite possible, afin de maintenir votre profil de conformité propre.
Recevez de nouveaux messages Gmail dès leur arrivée 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 champs d'application de l'API Gmail
Questions courantes sur les étendues de l'API Gmail, les étendues OAuth Gmail et le processus de vérification - répondues de manière concise pour les développeurs créant des intégrations Gmail.
gmail.lecture seule et gmail.modifier sont des champs d'application restreints de l'API Gmail. gmail.lecture seule fournit un accès en lecture seule à tous les messages, fils de discussion, libellés et paramètres - votre application ne peut rien envoyer ni modifier. gmail.modifier ajoute la possibilité de lire, composer, envoyer des e-mails et gérer des libellés, mais exclut la suppression permanente des messages. Si votre application a besoin de lire et d'envoyer, mais pas de supprimer, gmail.modifier est préférée à la plus large mail.google.com/ portée. Voir notre comment lire les e-mails des utilisateurs via une API unifiée.libellés gmail requièrent uniquement une révision standard de l'application OAuth. Les scopes sensibles comme gmail.envoyer require le processus de vérification OAuth de Google mais pas d'évaluation de sécurité. Lots restreints - y compris gmail.lecture seule, gmail.modifier, gmail.rediger, gmail.metadata, gmail.insérer, ou encore mail.google.com/ - exigent le processus d'évaluation complet. Plus d'informations à ce sujet dans notre modèles d'API de messagerie sécurisée pour les industries réglementées.gmail.modifier La portée des autorisations accorde un accès en lecture, composition, envoi et gestion des libellés à 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 des e-mails CRM, outils de helpdesk et clients de messagerie qui permettent à la fois de lire et d'envoyer des messages. Il est préférable à mail.google.com/ parce qu'elle limite l'exposition des données en excluant la fonctionnalité de suppression définitive. Connexe : 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 des étendues augmente les autorisations affichées sur l'écran de consentement de Google et peut déclencher des exigences de vérification supplémentaires si une étendue combinée est restreinte. Demandez toujours la combinaison minimale dont votre application a réellement besoin. Pour le côté Microsoft, voir Portées Microsoft Graph OAuth équivalentes.gmail.metadata scope est une portée limitée de l'API Gmail qui accorde l'accès à en-têtes et libellés d'e-mail uniquement, sans aucun accès au corps du courriel 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 courriels en fonction de l'expéditeur, du destinataire, de l'objet ou des étiquettes sans lire le contenu des messages privés. Malgré cette restriction, son empreinte de données est plus faible que gmail.lecture seule et pourront être plus faciles à justifier dans une évaluation de sécurité. Nous approfondissons dans notre API de synchronisation d'e-mails pour synchronisation complète de la boîte de réception.gmail.envoyer scope est un portée sensible de l'API Gmail 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 de suivi. Utilisation gmail.envoyer au lieu de gmail.modifier évite entièrement l'évaluation de sécurité à portée restreinte, accélérant considérablement votre mise en production. Voir notre Guide dédié à l'API d'envoi d'e-mails.
FR 
EN 
ES 
DE 
IT 
BR 
NL 
PL 
TR