Google Meet User Management API Guide

Auth method: OAuth 2.0

Setup steps

1. Create a project in Google Cloud Console (console.cloud.google.com).
2. Enable the 'Google Meet API' for the project.
3. Configure an OAuth 2.0 consent screen (internal or external).
4. Create OAuth 2.0 credentials (Web, Desktop, or Service Account depending on use case).
5. For domain-wide delegation (service accounts), grant the service account the required OAuth scopes in the Google Workspace Admin Console under Security > API Controls.
6. Request an access token using the appropriate OAuth 2.0 flow (Authorization Code for user context; JWT assertion for service accounts).
7. Include the Bearer token in the Authorization header of each API request.

Required scopes

Create a meeting space

• Method: POST
• URL: https://meet.googleapis.com/v2/spaces
• Watch out for: Spaces are created in the context of the authenticated user. Service accounts require domain-wide delegation to create spaces on behalf of users.

Request example

POST /v2/spaces
Authorization: Bearer {token}
Content-Type: application/json

{}

Response example

{
  "name": "spaces/abc123",
  "meetingUri": "https://meet.google.com/abc-defg-hij",
  "meetingCode": "abc-defg-hij"
}

Get a meeting space

• Method: GET
• URL: https://meet.googleapis.com/v2/spaces/{spaceId}
• Watch out for: Requires meetings.space.created or meetings.space.readonly scope. Only the space creator or a domain admin can retrieve space details.

Request example

GET /v2/spaces/abc123
Authorization: Bearer {token}

Response example

{
  "name": "spaces/abc123",
  "meetingUri": "https://meet.google.com/abc-defg-hij",
  "meetingCode": "abc-defg-hij",
  "config": {"accessType": "TRUSTED"}
}

List conference records

• Method: GET
• URL: https://meet.googleapis.com/v2/conferenceRecords
• Watch out for: Returns only conference records for spaces the authenticated user has access to. Use nextPageToken for pagination.

Request example

GET /v2/conferenceRecords?pageSize=50
Authorization: Bearer {token}

Response example

{
  "conferenceRecords": [
    {"name": "conferenceRecords/xyz", "space": "spaces/abc123",
     "startTime": "2024-01-10T10:00:00Z"}
  ],
  "nextPageToken": "token123"
}

List participants in a conference

• Method: GET
• URL: https://meet.googleapis.com/v2/conferenceRecords/{conferenceRecordId}/participants
• Watch out for: Anonymous participants appear under anonymousUser, not signedinUser. No PII is returned for anonymous users beyond their self-reported display name.

Request example

GET /v2/conferenceRecords/xyz/participants
Authorization: Bearer {token}

Response example

{
  "participants": [
    {"name": "conferenceRecords/xyz/participants/1",
     "signedinUser": {"user": "users/uid123", "displayName": "Jane Doe"}}
  ]
}

Create a Workspace user (Admin SDK)

• Method: POST
• URL: https://admin.googleapis.com/admin/directory/v1/users
• Watch out for: Requires admin.directory.user scope and a super admin or delegated admin account. New users inherit Meet access based on their OU's Meet policy.

Request example

POST /admin/directory/v1/users
Authorization: Bearer {token}

{"primaryEmail":"user@example.com",
 "name":{"givenName":"Jane","familyName":"Doe"},
 "password":"SecurePass1!"}

Response example

{
  "id": "uid123",
  "primaryEmail": "user@example.com",
  "name": {"fullName": "Jane Doe"},
  "suspended": false
}

Suspend a Workspace user (Admin SDK)

• Method: PUT
• URL: https://admin.googleapis.com/admin/directory/v1/users/{userKey}
• Watch out for: Suspending a user immediately revokes their ability to join or host Meet calls. Existing active sessions may not be terminated instantly.

Request example

PUT /admin/directory/v1/users/uid123
Authorization: Bearer {token}

{"suspended": true}

Response example

{
  "id": "uid123",
  "primaryEmail": "user@example.com",
  "suspended": true
}

List Workspace users (Admin SDK)

• Method: GET
• URL: https://admin.googleapis.com/admin/directory/v1/users
• Watch out for: domain or customer parameter is required. Results are paginated via nextPageToken. Deleted users are not returned; use showDeleted=true to include them.

Request example

GET /admin/directory/v1/users?domain=example.com&maxResults=100
Authorization: Bearer {token}

Response example

{
  "users": [
    {"id":"uid123","primaryEmail":"user@example.com","suspended":false}
  ],
  "nextPageToken": "token456"
}

Delete a Workspace user (Admin SDK)

• Method: DELETE
• URL: https://admin.googleapis.com/admin/directory/v1/users/{userKey}
• Watch out for: Deletion is soft for 20 days (user is recoverable). After 20 days, deletion is permanent. Prefer suspension over deletion for offboarding to preserve data.

Request example

DELETE /admin/directory/v1/users/uid123
Authorization: Bearer {token}

Response example

HTTP 204 No Content

• Rate limits: Google Meet API and Admin SDK Directory API enforce per-project and per-user quotas. Meet API default quota is 60 requests per minute per project. Admin SDK Directory API has a default of 1,500 queries per 100 seconds per project and 500 queries per 100 seconds per user.
• Rate-limit headers: No
• Retry-After header: No
• Rate-limit notes: Quota increases can be requested via Google Cloud Console. Exponential backoff is recommended on 429 responses. Admin SDK quotas are shared across all Admin SDK APIs in the project.
• Pagination method: token
• Default page size: 100
• Max page size: 100
• Pagination pointer: pageToken

• Webhooks available: Yes
• Webhook notes: Google Meet API supports push notifications via Google Cloud Pub/Sub. Clients subscribe to conference record events (meeting started, ended, participant joined/left, recording/transcript ready).
• Alternative event strategy: Polling the conferenceRecords and participants endpoints as a fallback if Pub/Sub is not available.
• Webhook events: google.workspace.meet.conference.v2.started, google.workspace.meet.conference.v2.ended, google.workspace.meet.participant.v2.joined, google.workspace.meet.participant.v2.left, google.workspace.meet.recording.v2.fileGenerationEnded, google.workspace.meet.transcript.v2.fileGenerationEnded

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Google Workspace Business Standard and above

• Endpoint: https://www.googleapis.com/admin/directory/v1/scim/v2/Users

• Supported operations: Create user (POST /Users), Retrieve user (GET /Users/{id}), List users (GET /Users), Update user (PUT /Users/{id}), Partial update (PATCH /Users/{id}), Delete/deprovision user (DELETE /Users/{id})

Limitations:

• SCIM manages Google Workspace users broadly; there is no Meet-specific SCIM endpoint.
• Meet access is controlled via Workspace OU policies, not per-user SCIM attributes.
• SCIM provisioning requires configuration in the IdP (e.g., Okta, Azure AD) pointing to Google Workspace SCIM endpoint.
• Google Workspace acts as the SCIM service provider; third-party IdPs act as provisioners.
• Available from Business Standard tier; not available on free Google accounts.

Three integration patterns cover the majority of production use cases.

Provisioning: POST to https://admin.googleapis.com/admin/directory/v1/users with primaryEmail, name, password, and orgUnitPath. Meet access is inherited from the target OU's policy - if Meet is disabled at the OU level, the user will not have access regardless of license tier. Verify OU Meet policy in Admin Console → Apps → Google Workspace → Google Meet before assuming access is live. SCIM via an IdP (Okta, Azure AD) can automate this step; the SCIM endpoint is https://www.googleapis.com/admin/directory/v1/scim/v2/Users, available from Business Standard tier and above.

Offboarding: PATCH or PUT to https://admin.googleapis.com/admin/directory/v1/users/{userKey} with {"suspended": true} to immediately block Meet sign-in. Note that active Meet sessions may not terminate instantly on suspension. Transfer Meet recordings (stored in the departing user's Google Drive) via the Drive API before deletion. DELETE at the same endpoint is soft for 20 days; after that, deletion is permanent and associated recordings are unrecoverable if not transferred.

Participant auditing: GET https://meet.googleapis.com/v2/conferenceRecords to enumerate recent conference records, then GET https://meet.googleapis.com/v2/conferenceRecords/{id}/participants per record. Authenticated participants surface under signedinUser.user; unauthenticated guests appear under anonymousUser with no PII beyond a self-reported display name. Cross-reference signedinUser.user values against the Admin SDK Directory API to resolve full user profiles. Paginate using nextPageToken; default and maximum page size is 100. For domain-wide auditing, a service account with domain-wide delegation is required - the Meet API only returns records for spaces accessible to the authenticated principal.

Provision a new employee with Meet access

1. POST to https://admin.googleapis.com/admin/directory/v1/users with primaryEmail, name, password, and orgUnitPath.
2. Assign the user to an OU that has Meet enabled in the Admin Console (or verify the default OU policy allows Meet).
3. Optionally, use SCIM via your IdP to automate this step if using Okta or Azure AD as the identity provider.
4. Verify the user can sign in and access meet.google.com.

Watch out for: Meet access is inherited from the OU policy. If the OU has Meet disabled, the user will not have access even after provisioning. Check Admin Console > Apps > Google Workspace > Google Meet for OU-level settings.

Offboard a departing employee and revoke Meet access

1. PATCH or PUT to https://admin.googleapis.com/admin/directory/v1/users/{userKey} with {"suspended": true} to immediately block Meet access.
2. Transfer ownership of any Meet recordings stored in Google Drive using the Drive API (files.update with new owner).
3. After data retention period, DELETE the user at https://admin.googleapis.com/admin/directory/v1/users/{userKey}.
4. If using SCIM, set the user's active attribute to false in the IdP to trigger automatic suspension.

Watch out for: Suspension is immediate for new sign-ins but active Meet sessions may not be terminated instantly. Deletion is irreversible after 20 days and removes associated Drive files (recordings) unless transferred first.

Audit participants in recent meetings

1. GET https://meet.googleapis.com/v2/conferenceRecords to list recent conference records for the authenticated user's spaces.
2. For each conferenceRecord, GET https://meet.googleapis.com/v2/conferenceRecords/{id}/participants to list all participants.
3. Check signedinUser.user to identify authenticated participants; anonymousUser entries indicate unauthenticated guests.
4. Cross-reference signedinUser.user values with Admin SDK Directory API to get full user profile details.
5. Use nextPageToken to paginate through all participants if the meeting was large.

Watch out for: The Meet API only returns conference records for spaces the authenticated principal has access to. For domain-wide auditing, use a service account with domain-wide delegation. Anonymous participants cannot be identified beyond their self-reported display name.

The primary integration trap is conflating the Meet REST API with a user management API - it is not one. Developers who build against meet.googleapis.com/v2 expecting to provision, suspend, or enumerate users will find no such endpoints; all identity operations route through the Admin SDK.

A second trap is scope underestimation: meetings.space.created is principal-scoped and will silently return empty or partial results when used in a service account context without domain-wide delegation, producing integration behavior that appears correct in testing (single-user OAuth flow) but fails in production (service account flow).

Rate limits compound this: the Meet API enforces 60 requests per minute per project, and the Admin SDK enforces 1,500 requests per 100 seconds per project with a tighter 500 requests per 100 seconds per user - both without rate-limit response headers, so exponential backoff on 429s must be implemented proactively rather than reactively.

Admin SDK quotas are shared across all Admin SDK APIs in the project, meaning a high-volume Directory API integration can exhaust quota that a Meet audit job depends on.

Finally, the SCIM endpoint manages Workspace accounts broadly; there is no Meet-specific SCIM attribute, so Meet access cannot be toggled via SCIM alone - OU policy state in the Admin Console remains the authoritative control plane.

Integrations building an identity graph across Workspace services should model Meet access as a function of (license tier, orgUnitPath, OU Meet policy) rather than a directly settable user attribute.