Notes on Creating and Getting Google Meet API Information

To integrate Google Meet with your application, you need to set up a project in Google Cloud Platform (GCP) and obtain the necessary API credentials.

Prerequisites:

• A Google Account (personal or Google Workspace).

• Access to Google Cloud Platform.

Step-by-Step Guide:

Part 1: Setting up a Project in Google Cloud Platform (GCP)

1. Go to Google Cloud Console:

   • Open your web browser and navigate to https://console.cloud.google.com/.

   • Sign in with your Google Account if prompted.

2. Create a New Project (if you don’t have one):

   • In the top-left corner, click on the project dropdown (usually shows “My First Project” or the name of your current project).

   • Click on “New Project.”

   • Enter a Project Name (e.g., “My Meet Integration,” “Meeting Scheduler App”).

   • (Optional) Select an Organization and Location if you are part of a Google Cloud Organization.

   • Click “Create.”

   • Once the project is created, ensure it is selected in the project dropdown.

Part 2: Enabling Necessary APIs

For Google Meet integration, you will primarily need to enable the Google Calendar API. The Meet functionality is often tied to calendar events.

1. Navigate to APIs & Services Dashboard:

   • In the Google Cloud Console, from the navigation menu (the three horizontal lines in the top-left), go to “APIs & Services” > “Dashboard.”

2. Enable Google Calendar API:

   • Click on “+ ENABLE APIS AND SERVICES.”

   • In the search bar, type “Google Calendar API.”

   • Click on “Google Calendar API” from the search results.

   • Click the “ENABLE” button.

   • Wait for the API to be enabled. This might take a few moments.

   Self-correction/Important Note: While there isn’t a dedicated “Google Meet API” directly listed for client-side integration in the same way as Calendar or Drive, Google Meet links are generated and managed through the Google Calendar API when creating events. So, enabling the Google Calendar API is crucial for interacting with Meet. If you are building a more advanced integration that requires direct Meet control, you might need to explore Google Workspace APIs, but for generating and managing Meet links via events, Calendar API is the primary one.

Part 3: Creating OAuth Consent Screen

Before creating credentials, you must configure the OAuth consent screen. This is what users will see when they grant your application permission to access their Google Account data.

1. Go to OAuth Consent Screen:

   • From the navigation menu, go to “APIs & Services” > “OAuth consent screen.”

2. Configure Consent Screen:

   • User Type: Choose “External” (unless your application is exclusively for users within your Google Workspace organization). Click “CREATE.”

   • App Information:

     • App name: Enter a user-friendly name for your application (e.g., “My Meeting App,” “Meeting Scheduler”).

     • User support email: Select an email address for users to contact.

     • Developer contact information: Enter your email address(es).

   • Click “SAVE AND CONTINUE.”

3. Scopes:

   • This is crucial. You need to define what data your application will request access to. For Google Meet integration via Calendar, you’ll need scopes related to Calendar.

   • Click “ADD OR REMOVE SCOPES.”

   • In the right-hand panel, search for and select the following scopes (at a minimum):

     • .../auth/calendar (Full access to Google Calendar)

     • Or, a more restricted scope like .../auth/calendar.events (View and edit events on all calendars you can access)

     • A commonly used scope that provides broad access for creating and managing events is https://www.googleapis.com/auth/calendar.

   • Click “ADD TO TABLE.”

   • Click “UPDATE” at the bottom of the scope selection window.

   • Click “SAVE AND CONTINUE.”

4. Test Users (for “External” apps in Testing status):

   • If your app is in “Testing” publication status, you need to add Google accounts that can test your application.

   • Click “+ ADD USERS.”

   • Enter the email addresses of the test users.

   • Click “ADD.”

   • Click “SAVE AND CONTINUE.”

5. Summary: Review your settings and click “BACK TO DASHBOARD.”

   Note: For production applications, you’ll eventually need to verify your OAuth consent screen with Google.

Part 4: Creating OAuth Client ID Credentials

Now, you will create the credentials your application will use to authenticate with Google’s APIs.

1. Go to Credentials:

   • From the navigation menu, go to “APIs & Services” > “Credentials.”

2. Create Credentials:

   • Click on “+ CREATE CREDENTIALS.”

   • Select “OAuth client ID.”

3. Application Type:

   • Application type: This depends on where your application is running:

     • Web application: If your application has a web server backend (most common for this type of integration).

     • Desktop app: If it’s a standalone desktop application.

     • Android/iOS: For mobile applications.

     • Based on the screenshot, “Web application” is the most likely candidate given the “Redirect URI” field.

   • Select “Web application.”

4. Web application details:

   • Name: Give a name to your OAuth 2.0 client (e.g., “My Web Client”). This is for your reference in GCP.

   • Authorized JavaScript origins (Optional): If your application uses JavaScript to make API calls directly from the browser, add your domain (e.g., http://localhost:8000, https://your-domain.com). This is typically for frontend-only applications.

   • Authorized redirect URIs: This is critical and corresponds to the “Redirect URI” field in your screenshot. This is the URL to which Google will send the user after they have authorized your application.

     • Add the exact URL where your application expects the OAuth redirect. This must match perfectly. In the screenshot, it looks like https://gocsp*****oud.h. You’ll need to get this exact URL from your application’s configuration.

     • Click “ADD URI” and paste your redirect URI.

   • Click “CREATE.”

5. Get Your Credentials:

   • A pop-up window will appear displaying your Client ID and Client Secret.

   • Client ID: This is a public string that identifies your application to Google. Copy this value.

   • Client Secret: This is a confidential string that should be kept secure and never exposed on the client-side (browser). Copy this value.

   • Click “OK.”

Part 5: Understanding and Obtaining the Access Token

The “Access Token” in your screenshot is not a static value you get from Google Cloud Console directly. It’s a short-lived token generated through the OAuth 2.0 flow after a user grants your application permission.

How to obtain an Access Token (OAuth 2.0 Flow):

1. User Initiates Authorization: Your application will redirect the user’s browser to Google’s authorization URL, including your Client ID, Redirect URI, and the requested Scopes.

2. User Grants Permission: The user sees the OAuth consent screen (which you configured earlier) and decides to grant or deny your application access.

3. Google Redirects Back: If the user grants permission, Google redirects the user’s browser back to your Redirect URI with an authorization code (for web server applications) or an access_token (for implicit flow, less common for server-side).

4. Exchange Code for Tokens (for Web Applications):

   • Your server-side application receives the authorization code.

   • Your server then makes a direct, secure request to Google’s token endpoint, including the code, your Client ID, and your Client Secret.

   • Google responds with an Access Token (short-lived, usually an hour) and often a Refresh Token (long-lived).

   • Access Token: This is the token your application uses to make authenticated API calls to Google Calendar (and thus manage Meet links).

   • Refresh Token: This token can be used to obtain new Access Tokens after the current one expires, without requiring the user to re-authorize.

Therefore, for the “Access Token” field in your screenshot:

• It means your application needs to implement the OAuth 2.0 authorization flow.

• The “Access Token” displayed there implies that your application stores the currently active access token obtained from a user’s successful authentication.

• The “Status: Active” likely means the current access token stored is valid.

Summary of Google-provided information and your application’s role:

• Module: Google Meet (selected in the dropdown, internal application setting).

• Client ID: Obtained from Google Cloud Platform (OAuth Client ID).

• Client Secret: Obtained from Google Cloud Platform (OAuth Client ID).

• Redirect URI: Configured in Google Cloud Platform (OAuth Client ID) and must match your application’s redirect endpoint.

• Access Token: Generated dynamically by your application after a successful OAuth 2.0 flow. Your application will store and manage this.

• Status: Internal application status based on the validity of the Access Token.

By following these steps, you will be able to obtain the necessary credentials from Google Cloud Platform to configure your “Meeting Config” page and enable Google Meet integration within your application. Remember to keep your Client Secret secure.