LinkedIn
Instagram
WhatsApp
Telegram
Gmail
Outlook
Google Agenda
Rejoindre la communauté SlackLe Google OAuth Playground est l'outil bac à sable officiel de Google pour tester les flux d'autorisation OAuth 2.0 sans écrire une seule ligne de code backend. Ce guide vous accompagne à travers toutes les fonctionnalités : sélection des scopes, échange des codes d'autorisation contre des jetons, appels d'API en direct, et compréhension du moment où vous devez passer du bac à sable à une solution de qualité de production.
Qu'est-ce que le Google OAuth Playground ?
Le Google OAuth Playground est un outil gratuit, basé sur navigateur, à developers.google.com/oauthplayground qui permet aux développeurs de tester le flux d'autorisation OAuth 2.0 complet contre n'importe quelle API Google sans configurer de serveur backend, enregistrer une application ou écrire de code côté serveur.
À la base, cet outil est une interface visuelle pour le flux OAuth 2.0 à trois volets. Vous sélectionnez les scopes de l'API Google que vous souhaitez, cliquez sur "Autoriser les API", complétez l'écran de consentement de Google, puis échangez le code d'autorisation résultant contre un jeton d'accès et un jeton de rafraîchissement. À partir de là, vous pouvez effectuer des requêtes API authentifiées directement dans le navigateur et inspecter les charges utiles brutes de la requête et de la réponse.
Il est particulièrement utile pour les équipes qui développent sur Gmail, Google Calendar, Google Drive ou toute autre API de Google Workspace. Au lieu de déboguer les flux de jetons en production, vous pouvez tout tester en toute sécurité dans un bac à sable d'abord. Le terrain de jeu OAuth 2.0 de Google prend en charge toutes les étendues OAuth de Google publiées et affiche les en-têtes HTTP et les charges utiles JSON exactes à chaque étape du flux.
Pourquoi les développeurs utilisent-ils le Google OAuth Playground
Le terrain de jeu OAuth2 résout quatre problèmes spécifiques pour les développeurs. Comprendre lequel d'entre eux s'applique à vous vous aidera à tirer le meilleur parti de chaque session et à savoir quand passer à une configuration de production.
Avant d'expédier votre application, vous devez savoir exactement quelle portée OAuth accorde l'accès à quelles données. Le terrain de jeu vous permet de comparer gmail.lecture seule vs gmail.modifier vs gmail.envoyer côte à côte, en appelant l'API Gmail réelle et en inspectant ce que chaque portée expose. Cela évite les sur-autorisations (demande d'autorisations excessives, qui déclenchent un examen plus approfondi de l'équipe de révision de Google) et les sous-autorisations (demande d'autorisations insuffisantes, qui provoquent des erreurs d'exécution pour vos utilisateurs).
La mise en place d'un flux de redirection OAuth complet localement prend du temps : il faut un serveur HTTP, une URL de rappel, la gestion des sessions et le stockage des jetons. Le terrain de jeu contourne tout cela. Vous vous authentifiez une fois dans le navigateur, obtenez vos jetons, puis exécutez n'importe quel point de terminaison de l'API Google directement depuis le panneau "Envoyer la requête". Ceci est particulièrement utile pour déboguer les erreurs 403 inattendues ou pour comprendre la structure des réponses de l'API avant d'écrire la logique d'analyse dans votre application.
La aire de jeux est l'un des meilleurs outils d'apprentissage disponibles pour comprendre le fonctionnement d'OAuth 2.0. L'interface utilisateur étape par étape rend le flux abstrait concret : vous voyez l'URL d'autorisation être construite avec les scopes que vous avez choisis, vous voyez le code d'autorisation renvoyé dans la redirection, et vous voyez comment ce code est échangé contre un jeton d'accès et un jeton de rafraîchissement. Pour les équipes qui accueillent des ingénieurs nouveaux à OAuth, une session de 30 minutes dans la aire de jeux remplace des heures de lecture de documentation. Voir notre guide sur Intégrer Google OAuth 2.0 dans votre application pour l'implémentation de la production complète.
Parfois, il suffit d'un jeton d'accès valide pour exécuter un script de migration de données unique, tester une charge utile de webhook ou vérifier manuellement une intégration d'API. Le terrain de jeu génère un jeton d'accès fonctionnel en moins de 60 secondes. Copiez-le, collez-le dans votre commande curl ou Postman, et c'est fait. La mise en garde est que les jetons du terrain de jeu (utilisant les identifiants par défaut de Google) expirent après 24 heures pour le jeton d'actualisation, et le jeton d'accès expire après 1 heure - donc cette approche est limitée aux scripts de courte durée.
Démarrage rapide : Votre première session de Playground en 3 minutes
Suivez ces cinq étapes pour passer de zéro à un appel d'API fonctionnel dans l'aire de jeu. Aucune configuration de la Google Cloud Console n'est requise pour ce flux de base.
Ouvrir developers.google.com/oauthplayground dans votre navigateur. L'interface principale s'affiche alors divisée en trois sections : Étape 1 (Sélectionner et autoriser les API), Étape 2 (Échanger le code d'autorisation contre des jetons) et Étape 3 (Configurer la requête vers l'API). À droite se trouve le panneau de configuration OAuth 2.0, accessible via l'icône en forme de roue dentée. Assurez-vous d'être connecté à votre compte Google avant de continuer.
Dans le panneau Étape 1, faites défiler la liste des API Google ou utilisez la zone de recherche. Cliquez sur Gmail API v1 pour le développer. Sélectionnez https://www.googleapis.com/auth/gmail.readonly pour commencer avec un accès en lecture seule. Vous pouvez sélectionner plusieurs étendues de plusieurs API en une seule session ; elles seront toutes regroupées dans une seule demande d'autorisation. Une fois que vous avez sélectionné votre ou vos étendues, cliquez sur le bouton bleu. "Autoriser les API" bouton.
Vous serez redirigé vers l'écran de consentement de Google. C'est le même Écran de consentement OAuth vos utilisateurs finaux verront dans votre application de production - l'aire de jeu utilise simplement le nom de l'application de Google au lieu du vôtre. Sélectionnez votre compte Google, examinez les autorisations demandées et cliquez sur "Autoriser". Google vous redirigera vers l'aire de jeu avec un code d'autorisation dans l'URL.
Vous êtes maintenant à l'étape 2. L'aire de jeu a automatiquement capturé le code d'autorisation. Cliquez sur "Échangez le code d'autorisation contre des jetons". Le terrain de jeu envoie une requête POST à https://oauth2.googleapis.com/token et affiche la requête brute ainsi que la réponse. Vous verrez votre access_token (valide pendant 1 heure) et votre token_rafraîchissement dans le panneau de réponse. Notez-les si vous avez besoin de les réutiliser en dehors de la zone de jeu.
Dans l'étape 3, entrez le point d'accès de l'API Gmail dans le champ "URI de la requête" : https://gmail.googleapis.com/gmail/v1/users/me/messages. Laissez la méthode HTTP telle quelle GET et cliquez sur " Envoyer la requête ". La zone de jeu injecte automatiquement votre jeton d'accès en tant qu'en-tête Bearer. Le panneau de réponse affiche la charge utile JSON de l'API Gmail - une liste d'ID de messages de votre boîte de réception. Vous venez de terminer un flux OAuth 2.0 complet dans la zone de jeu.
Étape par étape : tester les champs d'application OAuth dans Google OAuth Playground
La sélection de la portée est la décision la plus importante de votre intégration OAuth. Trop large, et l'équipe d'examen de Google signalera votre application. Trop étroite, et vos appels d'API renverront des erreurs 403. Le playground vous permet de tester chaque combinaison avant de vous engager. Pour une référence complète de chaque portée Gmail, consultez notre Guide des étendues de l'API Gmail.
gmail.lecture seule avant de tester gmail.modifier. Ce principe du moindre privilège réduit la surface d'attaque de votre application et simplifie l'examen de sécurité de Google. En savoir plus sur le processus d'examen : Guide de vérification Google OAuth.| Portée | Niveau d'accès | Sensibilité | Cas d'utilisation |
|---|---|---|---|
gmail.lecture seule |
Lire tous les messages et consulter tous les paramètres | Sensible | Analytique d'email, synchronisation de la boîte de réception |
gmail.modifier |
Lire, modifier les étiquettes, supprimer les messages | Accès restreint | Intégration CRM, applications de triage |
gmail.envoyer |
Envoyer des messages uniquement | Accès restreint | Envoi transactionnel au nom de l'utilisateur |
gmail.rediger |
Créer, lire, mettre à jour et supprimer des brouillons | Sensible | Assistants d'email IA, gestion des brouillons |
libellés gmail |
Créer, lire, mettre à jour et supprimer des étiquettes | Sensible | Automatisation des étiquettes, outils d'organisation |
gmail.metadata |
Lire uniquement les métadonnées du message (en-têtes, libellés) | Non-sensible | Indicateurs de présence d'e-mail, suivi des fils de discussion |
La zone de jeu fonctionne également bien pour les tests de l'API Calendrier. Pour tester l'accès en lecture du calendrier, sélectionnez https://www.googleapis.com/auth/calendar.readonly. Pour un accès complet en lecture/écriture, y compris la création et la suppression d'événements, utilisez https://www.googleapis.com/auth/calendar. Les portées du calendrier suivent le même modèle : commencer avec lecture seule, puis escaladez seulement si vous avez besoin d'opérations d'écriture. Une erreur courante est de demander l'intégralité calendrier champ lorsque vous n'avez qu'à lire la disponibilité - cela déclenche inutilement un examen de sécurité plus approfondi.
Le terrain de jeu accepte également des URL de portée personnalisées qui ne figurent pas dans le menu par défaut. Dans le panneau Étape 1, recherchez le champ "Entrez vos propres portées" en bas. Collez toute URL de portée valide - par exemple, une portée du SDK d'administration de Google Workspace ou une portée de l'API Google People - et elle sera ajoutée à la requête d'autorisation aux côtés de toutes les portées que vous avez sélectionnées dans la liste. Ceci est utile pour tester des API Google moins courantes qui ne sont pas mises en évidence dans l'interface utilisateur du terrain de jeu.
Intégrez votre Gmail avec UnipilePas à pas : Génération des jetons d'accès et des jetons d'actualisation
L'étape 2 du terrain de jeu est là où la vraie magie OAuth se produit. Après autorisation, un code d'autorisation se trouve dans le terrain de jeu en attente d'être échangé. Cette section explique les deux jetons que vous recevez, comment forcer un jeton de rafraîchissement et comment reproduire l'échange dans votre code de production.
Le jeton d'accès est un identifiant à durée de vie courte (3600 secondes par défaut) utilisé comme jeton d'authentification (Bearer token) dans le Authorization en-tête de chaque requête API. Lorsqu'il expire, l'API renvoie une erreur 401. Vous utilisez le jeton de rafraîchissement pour obtenir un nouveau jeton d'accès sans obliger l'utilisateur à réautoriser. Dans le bac à sable, le bouton "Actualiser le jeton d'accès" fait cela automatiquement à l'étape 2.
Le jeton de rafraîchissement un identifiant à longue durée de vie qui permet à votre application d'obtenir de nouveaux jetons d'accès sans interaction de l'utilisateur. Il n'expire jamais en production (sauf s'il est révoqué par l'utilisateur, ou si l'application est restée inactive pendant 6 mois). Cependant, dans le bac à sable, en utilisant les identifiants par défaut de Google, les jetons d'actualisation expirent après 24 heures. Ceci est une limitation spécifique à l'aire de jeu, pas une limitation de production.
Par défaut, Google ne renvoie qu'un jeton d'actualisation le première fois un utilisateur autorise votre application. Lors des autorisations ultérieures (si l'utilisateur a déjà consenti), Google ignore le jeton d'actualisation. Pour forcer le terrain de jeu à toujours renvoyer un jeton d'actualisation à l'étape 2, cliquez sur l'icône d'engrenage pour ouvrir la configuration OAuth 2.0 et activez les deux "Force prompt" et "Type d'accès : hors ligne". Avec ces paramètres, chaque flux d'autorisation retourne un nouveau jeton de rafraîchissement.
La zone de jeu vous montre la requête POST exacte qu'elle envoie pour échanger le code d'autorisation. Vous pouvez reproduire cette commande curl directement dans votre backend :
Mise en garde concernant le jeton d'actualisation de 24 heures : Lorsque vous utilisez les identifiants Google par défaut du playground (la configuration la plus courante), Google limite la durée de vie des jetons d'actualisation à 24 heures. C'est intentionnel : le playground utilise un client OAuth unique partagé, et Google révoque fréquemment les jetons pour des raisons de sécurité. Si vous avez besoin d'un jeton d'actualisation qui dure plus de 24 heures, activez "Utiliser vos propres identifiants OAuth" dans les paramètres du playground - abordé dans la section suivante.
Utiliser vos propres identifiants OAuth dans le Google OAuth Playground
La configuration par défaut de l'aire de jeu utilise les identifiants développeur partagés de Google, ce qui entraîne l'expiration du jeton d'actualisation après 24 heures. Le passage à votre propre ID client OAuth résout ce problème et rend le comportement de l'aire de jeu identique à celui de votre application de production. C'est la bonne approche lorsque vous avez besoin de tester Clés API vs différences OAuth ou parcourir le intégral Flux d'intégration Google OAuth.
https://developers.google.com/oauthplayground. C'est l'URI de redirection spécifique qu'attend le playground.gmail.modifier) nécessitent une application vérifiée. Avec vos propres identifiants, vous pouvez tester en mode développement avec jusqu'à 100 utilisateurs de test sans passer par une vérification complète.client_id, secret_client, ou encore uri_de_redirection que votre infrastructure de production utilisera. Vous pouvez copier le code d'échange directement dans votre application.https://developers.google.com/oauthplayground/ mais le terrain de jeu redirige vers l'URL sans la barre oblique, vous obtiendrez un uri_de_redirection_introuvable erreur. Ajoutez les deux versions si vous n'êtes pas sûr. Pour une analyse plus approfondie des codes d'erreur Google, consultez notre guide sur erreurs courantes de Google OAuth.Pièges courants du terrain de jeu Google OAuth
Voici les six erreurs et pièges qui font trébucher le plus souvent les développeurs dans l'aire de jeu. Chacun d'eux a une correction spécifique qui prend moins de 2 minutes à appliquer.
Lorsque vous utilisez les identifiants par défaut de Google Playground, votre jeton d'actualisation devient invalide après 24 heures. Tout script ou intégration s'appuyant sur ce jeton commencera à renvoyer 401 invalide_grant erreurs le lendemain.
Lorsque vous utilisez vos propres identifiants, Google renvoie erreur=redirection_non_conforme lors de l'étape d'autorisation. Cela signifie que l'URI de redirection dans votre client OAuth de la Cloud Console ne correspond pas exactement à ce qu'envoie le terrain de jeu.
https://developers.google.com/oauthplayground (sans barre oblique finale) en tant qu'URI de redirection autorisée. Voir notre guide sur Erreurs OAuth pour plus.L'appel API à l'étape 3 retourne 403 permissions insuffisantes. Cela se produit lorsque vous appelez un point de terminaison qui nécessite une portée que vous n'avez pas incluse à l'étape 1, ou lorsque vous avez oublié de cliquer sur "Autoriser les API" après avoir ajouté une nouvelle portée.
Les jetons d'accès ne sont valables que 3600 secondes. Si votre session de test dure longtemps, les appels à l'étape 3 commenceront à renvoyer des erreurs. 401 Identifiants invalides même si votre jeton de rafraîchissement est toujours valide.
Certaines API Google ont des exigences de portée versionnée. Par exemple, l'API Google Calendar v3 utilise des URL de base différentes de celles des versions antérieures. L'utilisation d'une portée conçue pour la v1 sur un point de terminaison v3 peut entraîner des erreurs inattendues ou des données incomplètes.
Vous rencontrez des erreurs liées à CORS dans les outils de développement lorsque vous utilisez la fonctionnalité "Envoyer la requête" du playground dans certains environnements réseau (proxys d'entreprise, VPN). Il s'agit d'un comportement spécifique au navigateur du playground, et non d'un problème avec l'API Google.
Aire de jeu vs Production : Lorsque vous dépassez l'aire de jeu Google OAuth
Le terrain de jeu est un excellent outil de test - il n'est pas conçu pour une utilisation en production. Voici une comparaison honnête des changements qui interviennent lorsque vous passez des tests sur le terrain de jeu à une véritable intégration OAuth desservant de vrais utilisateurs.
| Fonctionnalité | Aire de jeu OAuth | App de production |
|---|---|---|
| Durée de vie du jeton de rafraîchissement | 24h maximum (avec les identifiants de Google) Illimité avec les propres identifiants |
Illimité jusqu'à révocation par l'utilisateur ou inactivité de 6 mois |
| Base d'utilisateurs | 1 utilisateur (votre compte Google uniquement) | N utilisateurs - n'importe quel nombre de comptes Google peut autoriser votre application |
| Vérification OAuth | Pas nécessaire - contournements de validation du bac à sable | Requis après 100 utilisateurs test, pour des périmètres restreints |
| Examen de sécurité CASA de niveau 2 | Non applicable - Playground est un outil appartenant à Google | Requis pour les applications demandant des portées restreintes de Gmail ou du calendrier |
| Écran de consentement de marque | Affiche " Google OAuth 2.0 Playground " comme nom de l'application | Affiche le nom de votre application, son logo et votre politique de confidentialité |
| Visibilité de la requête / réponse | Visibilité complète - voir tous les en-têtes HTTP et la charge utile | Masqué des utilisateurs finaux - seul votre backend voit les jetons bruts et les réponses de l'API |
| Limites de débit de l'API | Quotas standard de l'API Google (partagés avec d'autres utilisateurs du bac à sable lors de l'utilisation des identifiants Google) | Votre propre quota dédié au projet - pas de partage avec d'autres développeurs |
| Cas d'utilisation prévu | Tests, débogage, apprentissage, génération de jetons ponctuels | Gérer les jetons persistants et multi-utilisateurs à grande échelle pour les utilisateurs finaux |
La règle du pouce : utilisez la zone de jeu jusqu'à ce que votre logique d'intégration soit confirmée, puis passez à un flux OAuth de production pour tout ce qui est destiné aux utilisateurs. Le plus grand point de friction en production est le processus de vérification de Google - pour les applications demandant des scopes sensibles ou restreints, cela peut prendre des semaines. C'est là qu'une solution comme Unipile peut vous aider : utilisez des identifiants pré-vérifiés et sautez complètement l'examen pendant que vous validez l'adéquation du produit au marché. Voir notre guide complet sur Intégration d'API d'e-mail OAuth pour une analyse approfondie des modèles de production.
Des semaines de vérification.
Utilisez La clé d'Unipile et commencez maintenant.
Vous avez testé dans le playground - passez à la production sans les 6 mois d'attente de vérification Google. Connectez des comptes Gmail en 5 minutes avec nos identifiants développeur pré-vérifiés.
Du Google OAuth Playground à la production : sautez l'attente de vérification
Le terrain de jeu a confirmé que votre logique d'intégration fonctionne. La prochaine étape consiste à connecter de vrais comptes utilisateurs en production. Mais voici le problème : le processus de vérification OAuth de Google pour les applications demandant des scopes Gmail sensibles ou restreints peut prendre 4 à 12 semaines, et nécessite un audit de sécurité CASA de niveau 2 pour les champs d'application restreints tels que gmail.modifier et gmail.envoyer.
Unipile résout ce problème avec des identifiants Google OAuth pré-vérifiés. Au lieu d'attendre des mois que Google approuve votre application, vous utilisez Clé de développeur certifié CASA de niveau 2 d'Unipile pour connecter immédiatement des comptes Gmail. Vos utilisateurs autorisent via l'écran de consentement standard de Google, votre application lit et envoie des e-mails via l'API d'Unipile, et vous pouvez passer à vos propres identifiants vérifiés à tout moment lorsque vous êtes prêt. C'est la même approche que celle utilisée par les équipes construisant sur notre Intégration Google OAuth et notre plus large Plateforme d'API d'email.
Google OAuth Playground - FAQ
Réponses aux questions les plus fréquentes concernant les tests, les jetons, les étendues et le passage en production depuis l'environnement de test.
Le Google OAuth Playground est un outil gratuit, basé sur navigateur, à developers.google.com/oauthplayground qui permet aux développeurs de tester les flux d’autorisation OAuth 2.0 avec n’importe quelle API Google. Sélectionnez les étendues, autorisez votre compte Google, échangez le code d’autorisation contre des jetons et effectuez des appels d’API en direct, le tout sans écrire de code backend. Maintenu par Google, il prend en charge toutes les étendues d’API Google publiées.
Les jetons d'accès expire après 1 heure (3600 secondes). Jetons de rafraîchissement les identifiants par défaut de la zone de jeu Google expirent après 24 heures ; il s'agit d'une limitation spécifique à la zone de jeu. Si vous configurez la zone de jeu pour utiliser vos propres identifiants OAuth (ID client et secret client de la Google Cloud Console), les jetons d'actualisation se comportent exactement comme les jetons de production, sans expiration de 24 heures. Vous pouvez également cliquer sur " Actualiser le jeton d'accès " à l'étape 2 à tout moment pour obtenir un nouveau jeton d'accès sans réautoriser.
Non. La cour de récréation est un outil de test et de débogage uniquement. Il est limité à un seul compte utilisateur (le vôtre), les jetons expirent rapidement avec les informations d'identification par défaut, et il ne prend pas en charge les flux d'autorisation multi-utilisateurs nécessaires aux applications de production. Pour la production, vous devez enregistrer votre propre application OAuth, implémenter le flux de redirection d'autorisation dans votre backend, et pour les scopes sensibles comme gmail.modifier, terminez le processus de vérification de Google. Alternativement, utilisez un service comme Les identifiants OAuth pré-vérifiés d'Unipile pour expédier plus vite.
Dans la console Google Cloud, créez une identification d'application Web OAuth 2.0 et ajoutez https://developers.google.com/oauthplayground en tant qu'URI de redirection autorisée. Copiez l'ID client et le secret client. Dans le terrain de jeu, cliquez sur icône d'engrenage, activez "Utiliser vos propres identifiants OAuth", puis collez votre ID client et votre secret client. Cliquez sur "Fermer", puis poursuivez avec la sélection de la portée et l'autorisation de l'étape 1 comme d'habitude. Vos jetons auront désormais des durées de vie équivalentes à celles de la production.
L'expiration de 24 heures est parce que vous utilisez le identifiants partagés par défaut du terrain de jeu (Client OAuth de Google). Google limite intentionnellement ces jetons partagés pour des raisons de sécurité. Ce n'est pas ainsi que fonctionnent les jetons OAuth en production. La solution consiste à activer "Utiliser vos propres informations d'identification OAuth" dans les paramètres de l'engrenage du terrain de jeu et à fournir votre propre ID client et votre secret client. Avec vos propres informations d'identification, les jetons de rafraîchissement sont valides jusqu'à ce que l'utilisateur révoque explicitement l'accès ou que l'application soit inactive pendant 6 mois.
Oui, complètement. Dans le bac à sable Étape 1, développez "API Gmail v1" et sélectionnez une portée Gmail (gmail.lecture seule, gmail.modifier, gmail.envoyer, etc.). Après autorisation, à l'étape 3, entrez l'URL du point de terminaison telle que https://gmail.googleapis.com/gmail/v1/users/me/messages et cliquez sur " Envoyer la requête ". Vous verrez la réponse en direct dans votre boîte de réception Gmail. Pour une référence complète des champs d'application Gmail et de leurs autorisations, consultez notre Guide des étendues de l'API Gmail.
La console prend en charge tous les champs d'application des API Google publiés. La liste intégrée comprend l'API Gmail, Google Agenda, Google Drive, Google Sheets, Google Docs, Google Slides, Google Admin SDK, l'API Google People, Google Tasks, YouTube, et bien d'autres. Vous pouvez également tester des champs d'application personnalisés en saisissant manuellement l'URL complète du champ d'application dans le champ "Saisissez vos propres champs d'application". Plusieurs champs d'application de différentes API peuvent être combinés en une seule requête d'autorisation.
Cette erreur n'apparaît que lorsque vous utilisez vos propres identifiants OAuth. Allez à Console Google Cloud, ouvrez les paramètres de votre client OAuth, et ajoutez https://developers.google.com/oauthplayground comme URI de redirection autorisé. Enregistrez, attendez quelques minutes que les modifications se propagent, puis réessayez. Si l'erreur persiste, essayez également d'ajouter la version avec une barre oblique finale. Pour d'autres solutions aux erreurs OAuth, consultez notre Guide des erreurs Google OAuth.
Oui, le Google OAuth Playground est complètement gratuit. Aucun compte n'est requis pour utiliser l'interface du terrain de jeu elle-même - il suffit de naviguer vers developers.google.com/oauthplayground et connectez-vous avec n'importe quel compte Google. Les appels d'API que vous effectuez via le terrain de jeu comptent pour le quota de votre projet Google Cloud (qui dispose d'un niveau gratuit généreux pour la plupart des API), mais l'outil de terrain de jeu lui-même n'a pas de coût. Pour une alternative entièrement gérée, consultez L'API Gmail prête pour la production d'Unipile.
Pour les applications SaaS connectant des comptes Gmail ou Google Agenda pour plusieurs utilisateurs finaux, Unipile fournit une API OAuth prête pour la production avec des identifiants Google pré-vérifiés (certifiée CASA Tier 2, conforme SOC 2 et GDPR). Au lieu du processus de vérification Google de 4 à 12 semaines pour les champs restreints, vous pouvez connecter immédiatement les comptes Gmail des utilisateurs. Vous pouvez également lire la documentation Google OAuth d'Unipile pour voir les appels d'API exacts requis. Passez à vos propres identifiants vérifiés à tout moment, sans interruption de service.
Vous avez encore des questions sur Google OAuth ou sur le terrain de jeu ?
FR 
EN 
ES 
DE 
IT 
BR 
NL 
PL 
TR