Feat/meet authenticated bots - #128
Conversation
…eference Adds the Google Meet authenticated-bot endpoints (meet-workspaces, meet-logins, meet_config on bot creation, MEET_LOGIN_* end reasons) to the v2 OpenAPI spec and regenerates the API reference. Also excludes untagged internal /v2/meet-sso/* SAML callback endpoints from reference generation so they no longer leak into the docs.
Adds the getting-started/meet guide (overview, Legacy SSO setup, sending authenticated bots) and documents the feature in new-features, the MEET_LOGIN_* error codes in error-codes, and the meet login alert types in alerts.
Google Admin Console walkthrough images for the Meet authentication setup guide.
…ection limit The Orama search indexes were never synced (updateSearchIndexes/updateOramaAi were never called), leaving the index stale. Wires both into post-build, caps indexed content blocks per page so the document count stays under the collection limit, and adds runnable search:sync / search:sync:ai scripts.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThis PR adds Google Meet authentication docs and references, regenerates API and webhook docs, updates generated LLM mirrors, adds search sync scripts and indexing safeguards, and records a generated Speaking Bots update entry. ChangesDocumentation and generation updates
Estimated code review effort🎯 4 (Complex) | ⏱️ ~70 minutes Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches🧪 Generate unit tests (beta)
|
…wording Removes "configurable per environment" (the 20-session limit is fixed in our environment config; users can't change it) from the spec, reference, and guide. Reworks the utilization guidance to recommend configuring the Meet Login Utilization / Meet Login Unavailable alerts first, with the utilization endpoint as an on-demand check, and expands the alerts page with a Meet login alerts section.
There was a problem hiding this comment.
Actionable comments posted: 9
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (5)
content/docs/api-v2/reference/zoom-credentials/createZoomCredential.mdx (1)
13-19:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAlign the Zoom credential request fields with the schema.
The doc still tells users to send
client_id/client_secret, butCreateConnectionRequestrequireszoom_client_id/zoom_client_secret. Anyone copying this will submit an invalid payload.Suggested fix
- **App-only credentials:** Provide only `name`, `client_id`, and `client_secret`. + **App-only credentials:** Provide only `name`, `zoom_client_id`, and `zoom_client_secret`. ... - client_id: The Client ID from your Zoom OAuth App. + zoom_client_id: The Client ID from your Zoom OAuth App. ... - client_secret: The Client Secret from your Zoom OAuth App. + zoom_client_secret: The Client Secret from your Zoom OAuth App.Also applies to: 41-51
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@content/docs/api-v2/reference/zoom-credentials/createZoomCredential.mdx` around lines 13 - 19, The documentation currently instructs users to provide `client_id` and `client_secret` fields for Zoom credentials, but the actual schema requires `zoom_client_id` and `zoom_client_secret`. Update all references to these field names throughout the document to match the schema exactly. Replace `client_id` with `zoom_client_id` and `client_secret` with `zoom_client_secret` in all code examples, field descriptions, and explanatory text to ensure users submitting requests will use the correct field names.content/llm/api-v2.md (3)
4018-4038:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winDefine
userIdbefore using it.This callback example references
userIdtwice, but never shows where it comes from, so it isn't copy/pasteable as written. Thread the authenticated user/session ID into the handler before building the request.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@content/llm/api-v2.md` around lines 4018 - 4038, The code snippet uses userId in two places (the name field and the saveZoomCredential call) but doesn't show where this variable comes from, making it impossible to copy and use as written. Before constructing the request body in the credential exchange handler, retrieve the authenticated user's ID from your session or authentication context and store it in a userId variable. This should be done at the start of the handler function so it's available both when building the request body with the name field and when calling saveZoomCredential.
2805-2814:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winUse a Python boolean literal here.
trueis not valid Python, so this example will raise aNameErrorif copied as written.♻️ Proposed fix
- "transcription_enabled": true, + "transcription_enabled": True,🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@content/llm/api-v2.md` around lines 2805 - 2814, The code example in the data dictionary uses the JSON boolean literal `true` instead of the Python boolean literal `True` in the `transcription_enabled` field. Change the `true` value to `True` so the example code is valid Python and won't raise a NameError when executed.
3914-3920:⚠️ Potential issue | 🟡 MinorAwait
cookies()in the Next.js 15 snippets.In Next.js 15,
cookies()is asynchronous and must be awaited before calling methods. This code will fail at runtime:
- Line 3930:
cookies().set()in the Server Action- Line 4017:
cookies().get()in the callback route handler- Line 4023:
cookies().delete()in the callback route handlerStore the resolved cookie store and reuse it:
Proposed fix
- cookies().set("zoom_oauth_state", state, { + const cookieStore = await cookies(); + cookieStore.set("zoom_oauth_state", state, { ... - const storedState = cookies().get("zoom_oauth_state")?.value; + const cookieStore = await cookies(); + const storedState = cookieStore.get("zoom_oauth_state")?.value; ... - cookies().delete("zoom_oauth_state"); + cookieStore.delete("zoom_oauth_state");🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@content/llm/api-v2.md` around lines 3914 - 3920, In Next.js 15, the cookies() function is asynchronous and must be awaited before calling methods on it. Fix this by awaiting the cookies() call and storing the result in a variable before using it. At the first location around line 3930 in the Server Action, change cookies().set() to const cookieStore = await cookies(); followed by cookieStore.set(). Apply the same pattern at line 4017 where cookies().get() is called and at line 4023 where cookies().delete() is called in the callback route handler. Store the awaited cookies() result once and reuse it for all operations within the same function scope.public/assets/meet-sso/README.md (1)
18-18:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winRemove the stray trailing
18.That line will render as literal text in the README and looks like an accidental artifact from the line numbering, not intended content.
🛠️ Suggested fix
-18🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@public/assets/meet-sso/README.md` at line 18, Remove the stray trailing `18` from line 18 of the README.md file in the public/assets/meet-sso directory. This appears to be an accidental artifact from line numbering that will render as unwanted literal text in the rendered markdown, so delete it to clean up the file.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@content/docs/api-v2/getting-started/meet/setup.mdx`:
- Line 72: The documentation in the setup.mdx file at line 72 contains
misleading wording about private key recovery. The phrase "only retrievable by
rotating the keypair" incorrectly suggests that rotation can recover the
original private_key_pem, when in fact rotation replaces the key material
entirely. Update the sentence to clarify that private_key_pem is non-recoverable
once lost, and that if the original key is lost, it must be replaced by
generating a new keypair through rotation rather than recovered from the
existing one.
In `@content/docs/api-v2/reference/bots/batchCreateBots.mdx`:
- Around line 32-39: The API documentation across multiple bot endpoint files
contains inconsistent and overlapping definitions of the `error` and `message`
fields in error response schemas, causing API contract drift. Fix this by
standardizing the error-field definitions across all affected files: in
content/docs/api-v2/reference/bots/batchCreateBots.mdx (lines 32-39) establish a
canonical non-overlapping definition where `error` and `message` map to
distinct, non-redundant fields from the API error object; then apply this same
canonical mapping to
content/docs/api-v2/reference/bots/batchCreateScheduledBots.mdx (lines 37-45),
content/docs/api-v2/reference/bots/createBot.mdx (lines 229-237),
content/docs/api-v2/reference/bots/createScheduledBot.mdx (lines 237-246),
content/docs/api-v2/reference/bots/deleteBotData.mdx (lines 33-41),
content/docs/api-v2/reference/bots/deleteScheduledBot.mdx (lines 29-37),
content/docs/api-v2/reference/bots/getBotDetails.mdx (lines 87-95), and
content/docs/api-v2/reference/bots/getBotScreenshots.mdx (lines 32-40) to ensure
all error response schemas use consistent field labels and descriptions aligned
to the canonical API error object structure.
In `@content/docs/api-v2/reference/bots/updateScheduledBot.mdx`:
- Around line 97-102: The example value for the `join_at` parameter in the
updateScheduledBot.mdx documentation shows "2025-12-25T10:00:00Z", which is
already in the past and violates the documented requirement that the timestamp
must be at least 4 minutes in the future and no more than 90 days in the future.
Update the example date on line 101 to use a future ISO8601 timestamp that
clearly demonstrates compliance with the endpoint's temporal constraints, such
as a date that is 30 days in the future from the documentation's perspective.
In `@content/docs/api-v2/reference/calendars/deleteCalendarBot.mdx`:
- Line 68: The error field description is inconsistently documented across
multiple API reference files. Update the error field description in
content/docs/api-v2/reference/calendars/deleteCalendarBot.mdx (line 68),
deleteCalendarConnection.mdx (line 34), getCalendarDetails.mdx (line 77),
getEventDetails.mdx (line 108), listCalendars.mdx (line 33), listEventSeries.mdx
(line 36), listEvents.mdx (line 33), and listRawCalendars.mdx (line 43) by
changing the description from "Error name" to the canonical wording describing
it as a human-readable error message to align with the API contract schema.
- Around line 53-58: The series_id parameter description in the
deleteCalendarBot endpoint documentation currently uses "schedule bots"
language, but this is a DELETE operation for cancelling bots, not scheduling
them. Update the parameter documentation text to use cancellation semantics
instead of scheduling semantics. Change the references from "schedule bots" to
"cancel bots" in the series_id description, particularly in the phrase about
recurring events and all_occurrences, to accurately reflect the DELETE
operation's purpose.
In `@content/docs/api-v2/reference/callbacks/callbackcompleted.mdx`:
- Around line 12-14: The raw pipe character in the `object | null` union type is
breaking the markdown table rendering at multiple locations. Wrap the type
annotation in backticks to escape the pipe so the table parses correctly. Apply
this fix at all five affected sites: in
`content/docs/api-v2/reference/callbacks/callbackcompleted.mdx` lines 12-14, in
`content/docs/api-v2/reference/callbacks/callbackfailed.mdx` lines 12-14, in
`content/docs/api-v2/reference/webhooks/botwebhookchatmessage.mdx` lines 12-14,
in `content/docs/api-v2/reference/webhooks/botwebhookcompleted.mdx` lines 12-14,
and in `content/docs/api-v2/reference/webhooks/botwebhookfailed.mdx` lines
12-14. At each location, change the `extra` row's type cell from `object | null`
to `` `object | null` ``.
In `@content/docs/api-v2/reference/meet-logins/createMeetLogin.mdx`:
- Around line 14-20: The current explanation incorrectly bundles `credential_id`
and `email_group` together in the round-robin assignment description, but these
represent two different bot dispatch mechanisms. The `credential_id` parameter
is an explicit selector for direct login selection, not a round-robin assignment
method. Separate these concepts by keeping the round-robin assignment
explanation tied exclusively to `email_group`, and either add a separate
sentence clarifying that `credential_id` provides explicit/direct login
selection as an alternative to round-robin, or restructure the text to clearly
distinguish between these two dispatch modes when a bot is dispatched via `POST
/v2/bots`.
In `@content/docs/api-v2/reference/meet-logins/listMeetLogins.mdx`:
- Line 15: Remove the stale v1 reference from the State Field description in the
listMeetLogins documentation. The phrase "A login flipping to `invalid` is rare
in v1 —" should be updated to remove the v1 comparison, since this documentation
is for v2 API reference and the v1 reference creates confusion about current
behavior. Simplify the sentence to focus on current v2 behavior without the
historical v1 context.
In `@content/docs/api-v2/reference/meet-workspaces/createMeetWorkspace.mdx`:
- Around line 21-38: The "Error Scenarios:" section documents the "both
provided" and "neither provided" cases for the keypair parameters, but is
missing documentation for the partial payload case. Add a new 422 error scenario
that explicitly states providing only one of `cert_pem` or `private_key_pem`
without the other (while neither generating a keypair nor providing both cert
and key) is invalid, so clients know partial BYO-keypair payloads are rejected.
---
Outside diff comments:
In `@content/docs/api-v2/reference/zoom-credentials/createZoomCredential.mdx`:
- Around line 13-19: The documentation currently instructs users to provide
`client_id` and `client_secret` fields for Zoom credentials, but the actual
schema requires `zoom_client_id` and `zoom_client_secret`. Update all references
to these field names throughout the document to match the schema exactly.
Replace `client_id` with `zoom_client_id` and `client_secret` with
`zoom_client_secret` in all code examples, field descriptions, and explanatory
text to ensure users submitting requests will use the correct field names.
In `@content/llm/api-v2.md`:
- Around line 4018-4038: The code snippet uses userId in two places (the name
field and the saveZoomCredential call) but doesn't show where this variable
comes from, making it impossible to copy and use as written. Before constructing
the request body in the credential exchange handler, retrieve the authenticated
user's ID from your session or authentication context and store it in a userId
variable. This should be done at the start of the handler function so it's
available both when building the request body with the name field and when
calling saveZoomCredential.
- Around line 2805-2814: The code example in the data dictionary uses the JSON
boolean literal `true` instead of the Python boolean literal `True` in the
`transcription_enabled` field. Change the `true` value to `True` so the example
code is valid Python and won't raise a NameError when executed.
- Around line 3914-3920: In Next.js 15, the cookies() function is asynchronous
and must be awaited before calling methods on it. Fix this by awaiting the
cookies() call and storing the result in a variable before using it. At the
first location around line 3930 in the Server Action, change cookies().set() to
const cookieStore = await cookies(); followed by cookieStore.set(). Apply the
same pattern at line 4017 where cookies().get() is called and at line 4023 where
cookies().delete() is called in the callback route handler. Store the awaited
cookies() result once and reuse it for all operations within the same function
scope.
In `@public/assets/meet-sso/README.md`:
- Line 18: Remove the stray trailing `18` from line 18 of the README.md file in
the public/assets/meet-sso directory. This appears to be an accidental artifact
from line numbering that will render as unwanted literal text in the rendered
markdown, so delete it to clean up the file.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 037fe7ae-c35a-4494-a52c-09caab9809ad
⛔ Files ignored due to path filters (5)
public/assets/meet-sso/1-find-sso-setting.pngis excluded by!**/*.pngpublic/assets/meet-sso/2-open-legacy-profile.pngis excluded by!**/*.pngpublic/assets/meet-sso/3-configure-profile.pngis excluded by!**/*.pngpublic/assets/meet-sso/4-assign-select-group.pngis excluded by!**/*.pngpublic/assets/meet-sso/5-assign-legacy-profile.pngis excluded by!**/*.png
📒 Files selected for processing (96)
content/docs/api-v2/alerts.mdxcontent/docs/api-v2/error-codes.mdxcontent/docs/api-v2/getting-started/meet/index.mdxcontent/docs/api-v2/getting-started/meet/meta.jsoncontent/docs/api-v2/getting-started/meet/sending-authenticated-bots.mdxcontent/docs/api-v2/getting-started/meet/setup.mdxcontent/docs/api-v2/getting-started/meta.jsoncontent/docs/api-v2/new-features.mdxcontent/docs/api-v2/reference/bots/batchCreateBots.mdxcontent/docs/api-v2/reference/bots/batchCreateScheduledBots.mdxcontent/docs/api-v2/reference/bots/createBot.mdxcontent/docs/api-v2/reference/bots/createScheduledBot.mdxcontent/docs/api-v2/reference/bots/deleteBotData.mdxcontent/docs/api-v2/reference/bots/deleteScheduledBot.mdxcontent/docs/api-v2/reference/bots/getBotDetails.mdxcontent/docs/api-v2/reference/bots/getBotScreenshots.mdxcontent/docs/api-v2/reference/bots/getBotStatus.mdxcontent/docs/api-v2/reference/bots/getScheduledBotDetails.mdxcontent/docs/api-v2/reference/bots/leaveBot.mdxcontent/docs/api-v2/reference/bots/listBots.mdxcontent/docs/api-v2/reference/bots/listScheduledBots.mdxcontent/docs/api-v2/reference/bots/meta.jsoncontent/docs/api-v2/reference/bots/pauseBotRecording.mdxcontent/docs/api-v2/reference/bots/resendFinalWebhook.mdxcontent/docs/api-v2/reference/bots/resumeBotRecording.mdxcontent/docs/api-v2/reference/bots/retranscribeBot.mdxcontent/docs/api-v2/reference/bots/retryCallback.mdxcontent/docs/api-v2/reference/bots/sendChatMessage.mdxcontent/docs/api-v2/reference/bots/updateBotConfig.mdxcontent/docs/api-v2/reference/bots/updateScheduledBot.mdxcontent/docs/api-v2/reference/calendars/createCalendarBot.mdxcontent/docs/api-v2/reference/calendars/createCalendarConnection.mdxcontent/docs/api-v2/reference/calendars/deleteCalendarBot.mdxcontent/docs/api-v2/reference/calendars/deleteCalendarConnection.mdxcontent/docs/api-v2/reference/calendars/getCalendarDetails.mdxcontent/docs/api-v2/reference/calendars/getEventDetails.mdxcontent/docs/api-v2/reference/calendars/listCalendars.mdxcontent/docs/api-v2/reference/calendars/listEventSeries.mdxcontent/docs/api-v2/reference/calendars/listEvents.mdxcontent/docs/api-v2/reference/calendars/listRawCalendars.mdxcontent/docs/api-v2/reference/calendars/resubscribeCalendar.mdxcontent/docs/api-v2/reference/calendars/syncCalendar.mdxcontent/docs/api-v2/reference/calendars/updateCalendarBot.mdxcontent/docs/api-v2/reference/calendars/updateCalendarConnection.mdxcontent/docs/api-v2/reference/callbacks/callbackcompleted.mdxcontent/docs/api-v2/reference/callbacks/callbackfailed.mdxcontent/docs/api-v2/reference/meet-logins/createMeetLogin.mdxcontent/docs/api-v2/reference/meet-logins/deleteMeetLogin.mdxcontent/docs/api-v2/reference/meet-logins/getMeetLogin.mdxcontent/docs/api-v2/reference/meet-logins/getMeetLoginUtilization.mdxcontent/docs/api-v2/reference/meet-logins/listMeetLogins.mdxcontent/docs/api-v2/reference/meet-logins/meta.jsoncontent/docs/api-v2/reference/meet-logins/updateMeetLogin.mdxcontent/docs/api-v2/reference/meet-workspaces/createMeetWorkspace.mdxcontent/docs/api-v2/reference/meet-workspaces/deleteMeetWorkspace.mdxcontent/docs/api-v2/reference/meet-workspaces/getMeetWorkspace.mdxcontent/docs/api-v2/reference/meet-workspaces/listMeetWorkspaces.mdxcontent/docs/api-v2/reference/meet-workspaces/meta.jsoncontent/docs/api-v2/reference/meet-workspaces/updateMeetWorkspace.mdxcontent/docs/api-v2/reference/meta.jsoncontent/docs/api-v2/reference/webhooks/botwebhookchatmessage.mdxcontent/docs/api-v2/reference/webhooks/botwebhookcompleted.mdxcontent/docs/api-v2/reference/webhooks/botwebhookfailed.mdxcontent/docs/api-v2/reference/webhooks/botwebhookstatuschange.mdxcontent/docs/api-v2/reference/webhooks/calendarwebhookconnectioncreated.mdxcontent/docs/api-v2/reference/webhooks/calendarwebhookconnectiondeleted.mdxcontent/docs/api-v2/reference/webhooks/calendarwebhookconnectionupdated.mdxcontent/docs/api-v2/reference/webhooks/calendarwebhookeventcancelled.mdxcontent/docs/api-v2/reference/webhooks/calendarwebhookeventcreated.mdxcontent/docs/api-v2/reference/webhooks/calendarwebhookeventssynced.mdxcontent/docs/api-v2/reference/webhooks/calendarwebhookeventupdated.mdxcontent/docs/api-v2/reference/webhooks/index.mdxcontent/docs/api-v2/reference/webhooks/meta.jsoncontent/docs/api-v2/reference/zoom-credentials/createZoomCredential.mdxcontent/docs/api-v2/reference/zoom-credentials/deleteZoomCredential.mdxcontent/docs/api-v2/reference/zoom-credentials/getZoomCredential.mdxcontent/docs/api-v2/reference/zoom-credentials/listZoomCredentials.mdxcontent/docs/api-v2/reference/zoom-credentials/updateZoomCredential.mdxcontent/llm-config.jscontent/llm-config.tscontent/llm/api-v2-all.mdcontent/llm/api-v2-bots.mdcontent/llm/api-v2-callbacks.mdcontent/llm/api-v2-meet-logins.mdcontent/llm/api-v2-meet-workspaces.mdcontent/llm/api-v2-webhooks.mdcontent/llm/api-v2.mdcontent/llm/updates.mdcontent/llm/webhooks.mdopenapi-v2.jsonpackage.jsonpublic/assets/meet-sso/README.mdscripts/generate-docs.mtsscripts/post-build.mtsscripts/update-orama-ai.mtsscripts/update-orama-index.mts
Common questions: when authentication is needed, using the main domain with a scoped bot group/OU, concurrency and scaling, waiting-room bypass, credential_id vs email_group, pool saturation, recovering an invalid resource, the private key, and Zoom/Teams support.
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (5)
content/llm/api-v2.md (5)
9885-9907:⚠️ Potential issue | 🟠 Major | ⚡ Quick winUse
video, notmp4, in the completed webhook example.The detailed webhook docs in this file expose the field as
video;mp4is a different contract and will mislead consumers copying this payload.🔧 Proposed fix
- "mp4": "https://s3.amazonaws.com/.../video.mp4", + "video": "https://s3.amazonaws.com/.../video.mp4",🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@content/llm/api-v2.md` around lines 9885 - 9907, The bot.completed webhook example in the documentation shows the field as `mp4`, but the detailed webhook documentation uses `video` as the field name. To maintain consistency and prevent misleading API consumers, change the field name from `mp4` to `video` in the webhook payload example within the data object.
9977-9984:⚠️ Potential issue | 🟠 Major | ⚡ Quick winReplace
TRANSCRIPTION_ERRORwithTRANSCRIPTION_FAILED.This list conflicts with the error-code section below, which documents
TRANSCRIPTION_FAILEDfor transcription failures.🔧 Proposed fix
- - `TRANSCRIPTION_ERROR`: Error occurred during transcription + - `TRANSCRIPTION_FAILED`: Error occurred during transcription🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@content/llm/api-v2.md` around lines 9977 - 9984, Replace the error code `TRANSCRIPTION_ERROR` in the Common Error Codes list with `TRANSCRIPTION_FAILED` to maintain consistency with the error-code section documented elsewhere in the API documentation. This resolves the naming conflict where the same error condition is documented under two different names.
7571-7575:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix the version reference.
This note is describing v2 login behavior, so
v1is misleading here.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@content/llm/api-v2.md` around lines 7571 - 7575, In the State Field section describing login behavior, the text currently references "v1" when discussing when a login flips to invalid state, but since this documentation is for the v2 API and describes v2 behavior, change the "v1" reference to "v2" to correctly reflect which version's behavior is being documented.
10000-10101:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAlign the calendar webhook examples with the payload reference.
These overview snippets still use legacy names (
platform,events_synced, etc.), but the dedicated payload docs later in the file usecalendar_platformand anevents-based structure. Copy-pasting from here will produce the wrong handler shape.🔧 Example fix
- "platform": "google", + "calendar_platform": "google",Update the
calendar.events_syncedexample to match the reference payload (calendar_id+events), and keep the calendar connection examples consistent with the detailed webhook docs.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@content/llm/api-v2.md` around lines 10000 - 10101, The calendar webhook example payloads in the file use legacy field names that do not match the canonical payload reference documentation elsewhere. Update all calendar connection events (calendar.connection_created, calendar.connection_updated, calendar.connection_deleted, and calendar.connection_error) to replace the field "platform" with "calendar_platform". Additionally, update the calendar.events_synced event payload to replace the "events_synced" and "sync_type" fields with an "events"-based structure that aligns with the reference payload documentation referenced in the comment. Ensure all example payloads are consistent with the detailed webhook payload docs to prevent copy-paste errors for users implementing webhook handlers.
2820-2825:⚠️ Potential issue | 🟡 MinorReplace
truewithTruein the Python example.This is a Python code block, which uses
Truefor booleans. The lowercasetrueis JSON/JavaScript syntax and will cause aNameErrorif executed as-is.Proposed fix
- "transcription_enabled": true, + "transcription_enabled": True,🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@content/llm/api-v2.md` around lines 2820 - 2825, The Python code example in the file uses lowercase `true` for the boolean value in the `data` dictionary assignment, which is JSON/JavaScript syntax and will cause a NameError when executed as Python. Replace the lowercase `true` with uppercase `True` for the `"transcription_enabled"` field and any other boolean values in this Python code block to use proper Python boolean syntax.
♻️ Duplicate comments (1)
content/docs/api-v2/reference/meet-logins/createMeetLogin.mdx (1)
14-14:⚠️ Potential issue | 🟠 MajorCross-file inconsistency: API reference incorrectly bundles
credential_idwith round-robin assignment.The OpenAPI-derived text at line 14 (and mirrored at line 105) states:
Round-robin assignment picks the least-loaded active login when a bot is dispatched with `meet_config.email_group` (or `credential_id`) on `POST /v2/bots`.The
(orcredential_id)phrasing impliescredential_idis also a round-robin mechanism. However, the guides in this PR (sending-authenticated-bots.mdx and index.mdx) correctly clarify that:
email_groupselects the least-loaded active login (round-robin pool assignment)credential_idpins one specific login directly (explicit selection, not round-robin)- When both are set,
email_grouptakes priorityThis inconsistency misleads users about how bot dispatch mechanisms work. The issue originates in the OpenAPI spec (openapi-v2.json description field for
POST /v2/meet-logins). To fix this generated doc, the upstream OpenAPI text should be corrected to separate the two mechanisms.Recommended fix to the OpenAPI spec description:
Replace:
Round-robin assignment picks the least-loaded active login when a bot is dispatched with `meet_config.email_group` (or `credential_id`) on `POST /v2/bots`.With:
When a bot is dispatched via `POST /v2/bots`, its `meet_config` controls login assignment: - With `email_group`: round-robin assignment picks the least-loaded active login in that pool. - With `credential_id`: the specified login is used directly. - If both are set, `email_group` takes priority.Also applies to: 105-105
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@content/docs/api-v2/reference/meet-logins/createMeetLogin.mdx` at line 14, The OpenAPI spec description for POST /v2/meet-logins (in openapi-v2.json) incorrectly bundles credential_id with round-robin assignment, implying both mechanisms work the same way. Update the description field to clearly separate the two: email_group uses round-robin assignment to pick the least-loaded active login, while credential_id pins a specific login directly, and email_group takes priority when both are set. This fix will automatically correct the generated documentation in createMeetLogin.mdx at both line 14 and line 105, aligning the API reference with the guidance provided in sending-authenticated-bots.mdx and index.mdx.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@content/llm/api-v2.md`:
- Around line 9885-9907: The bot.completed webhook example in the documentation
shows the field as `mp4`, but the detailed webhook documentation uses `video` as
the field name. To maintain consistency and prevent misleading API consumers,
change the field name from `mp4` to `video` in the webhook payload example
within the data object.
- Around line 9977-9984: Replace the error code `TRANSCRIPTION_ERROR` in the
Common Error Codes list with `TRANSCRIPTION_FAILED` to maintain consistency with
the error-code section documented elsewhere in the API documentation. This
resolves the naming conflict where the same error condition is documented under
two different names.
- Around line 7571-7575: In the State Field section describing login behavior,
the text currently references "v1" when discussing when a login flips to invalid
state, but since this documentation is for the v2 API and describes v2 behavior,
change the "v1" reference to "v2" to correctly reflect which version's behavior
is being documented.
- Around line 10000-10101: The calendar webhook example payloads in the file use
legacy field names that do not match the canonical payload reference
documentation elsewhere. Update all calendar connection events
(calendar.connection_created, calendar.connection_updated,
calendar.connection_deleted, and calendar.connection_error) to replace the field
"platform" with "calendar_platform". Additionally, update the
calendar.events_synced event payload to replace the "events_synced" and
"sync_type" fields with an "events"-based structure that aligns with the
reference payload documentation referenced in the comment. Ensure all example
payloads are consistent with the detailed webhook payload docs to prevent
copy-paste errors for users implementing webhook handlers.
- Around line 2820-2825: The Python code example in the file uses lowercase
`true` for the boolean value in the `data` dictionary assignment, which is
JSON/JavaScript syntax and will cause a NameError when executed as Python.
Replace the lowercase `true` with uppercase `True` for the
`"transcription_enabled"` field and any other boolean values in this Python code
block to use proper Python boolean syntax.
---
Duplicate comments:
In `@content/docs/api-v2/reference/meet-logins/createMeetLogin.mdx`:
- Line 14: The OpenAPI spec description for POST /v2/meet-logins (in
openapi-v2.json) incorrectly bundles credential_id with round-robin assignment,
implying both mechanisms work the same way. Update the description field to
clearly separate the two: email_group uses round-robin assignment to pick the
least-loaded active login, while credential_id pins a specific login directly,
and email_group takes priority when both are set. This fix will automatically
correct the generated documentation in createMeetLogin.mdx at both line 14 and
line 105, aligning the API reference with the guidance provided in
sending-authenticated-bots.mdx and index.mdx.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 917ea7b0-c455-4866-b995-f31c1851c16d
📒 Files selected for processing (8)
content/docs/api-v2/alerts.mdxcontent/docs/api-v2/getting-started/meet/index.mdxcontent/docs/api-v2/getting-started/meet/sending-authenticated-bots.mdxcontent/docs/api-v2/reference/meet-logins/createMeetLogin.mdxcontent/llm/api-v2-all.mdcontent/llm/api-v2-meet-logins.mdcontent/llm/api-v2.mdopenapi-v2.json
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@content/docs/api-v2/getting-started/meet/index.mdx`:
- Around line 117-119: The documentation incorrectly states that the Legacy SSO
profile can be scoped to specific bot-only groups or organizational units.
According to Google Workspace documentation, the Legacy SSO profile is
domain-wide and does not support granular scoping—only modern SSO profiles
support that capability. Revise the Q&A section to either recommend using modern
SSO profiles if granular scoping to groups/OUs is required, or clarify that the
Legacy SSO profile applies domain-wide and cannot be restricted to specific OUs
or groups, then adjust the guidance accordingly for users who must use the
Legacy profile.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: fdb94ac1-30c3-4451-92f9-c24c80790eef
📒 Files selected for processing (2)
content/docs/api-v2/getting-started/meet/index.mdxcontent/llm/api-v2.md
Converts the bold-Q&A FAQ blocks to <Accordions> across the Meet and Zoom getting-started guides so the pages stay short and scannable. Per review feedback from Yusuf.
…"FAQ" fumadocs-ui's Accordion only renders the copy-link button when an `id` is set, so drop the `id` from the FAQ accordions to remove it. Also titles the calendars FAQ heading "FAQ".
2f4dc36 to
c284d33
Compare
No description provided.