docs: enhance Generate Session and Creator Mode documentation with ne…

[vasilev-alex]

…w parameters and examples

Check List

• Tests have been run in packages where changes have been made if available
• Linter has been run for changed code
• Tests for the changes have been added if not covered yet
• Docs have been added / updated if required

[claude]

Claude finished @vasilev-alex's task in 1m 40s —— View job

---

Review of PR #10823

• Gather context and read changed files
• Review generate-session.mdx changes
• Review creator-mode.mdx changes
• Post comprehensive review

---

Overall Assessment

This is a well-written documentation enhancement. The new sections for User Attributes, Groups, Creator Mode bootstrapping, and the Embed-tenant Admin API are clear, well-structured, and follow the repo's docs style guide (reference links at bottom, proper use of InfoBox/WarningBox, code blocks with language specifiers, etc.). The creator-mode page was appropriately trimmed to avoid duplication with the now-canonical reference in generate-session.mdx.

What looks good

• Single-call bootstrap pattern is well-explained — the idempotency semantics, the "upsert-then-validate" ordering, and the immutable-type constraint are all documented clearly.
• Groups behavior table (omitted vs [] vs populated array) is a great addition — this kind of semantic detail prevents common integration bugs.
• Cross-linking between the two files is solid: creator-mode defers to generate-session for the detailed schema, and generate-session links back to creator-mode for the conceptual overview.
• Code examples updated consistently across JS, Python, and cURL with the new deploymentId and groups fields.

Issues to address

I've left 3 inline comments. Summary:

1. roles dropped from InfoBox (generate-session.mdx:46): The old text listed roles as disallowed with internalId. This PR removes it without adding it as a documented field. Meanwhile, chat-api.mdx:95 still references roles in the same sentence. Clarify whether roles was intentionally removed, and if so, update chat-api.mdx for consistency.

2. defaultValue type (generate-session.mdx:160): Documented as string, but userAttributes values can be number, string[], or number_array. Should defaultValue support those types too, or is it always serialized as a string?

3. Embed-tenant admin API response shapes (generate-session.mdx:204-215): The four new endpoints are introduced without response schemas, error codes, or idempotency notes for DELETE. Consider adding brief documentation or linking to a full API reference.

Minor observations (non-blocking)

• The embedTenantName validation rule (lowercase, 5–36 chars, letter start, letter/digit end) is stated in both generate-session.mdx:36 and creator-mode.mdx:17. Not a problem today, but if the rule ever changes, it's two places to update. Consider whether one canonical location with a cross-link would be better.
• The bootstrap example (generate-session.mdx:171-199) uses ACCOUNT_NAME, API_KEY, and DEPLOYMENT_ID as variables, while the code examples section below (generate-session.mdx:237-303) uses string literals like 'YOUR_API_KEY' and 32. Minor inconsistency — both styles work, but unifying would polish the page.

---

[claude]

Nit: The old InfoBox listed roles in the disallowed-with-internalId set. This PR replaces it with groupDefinitions and userAttributeDefinitions but drops roles entirely. Was roles intentionally removed as a supported field, or should it still be mentioned here?

For reference, chat-api.mdx:95 still lists roles in an identical sentence:

You cannot specify roles, groups, userAttributes, or securityContext with internalId…

If roles is no longer a valid field, chat-api.mdx should be updated too for consistency.

[claude]

Question: defaultValue is typed as string here, but value in userAttributes supports string | number | string[] | number[]. If the attribute type can be number, string_array, or number_array, should defaultValue also accept those types (or at least be documented as "serialized as a string")?

[claude]

Suggestion: This new section introduces four admin API endpoints but doesn't document their response shapes or error codes. Consider adding at minimum:

• The response object shape for the GET (list) endpoints (what fields each group/attribute object contains).
• Expected HTTP status codes (e.g. 404 for unknown tenant, 204 for successful delete).
• Whether DELETE is idempotent (what happens if the ID doesn't exist).

If this is intentionally kept brief for now, a note like "See the full API reference for response schemas" with a link would help readers know where to find more detail.