OMeet Developer Docs
OMeet developer documentation
Get started with OMeet accounts, Workspaces, and integration tools.
Content updated: 25 September 202601 / 05
Overview
OMeet provides four entry points so that each tool keeps a clear purpose.
- Read Docs to understand the sequence and concepts to prepare.
- Use API Reference for specific operations, data, and authentication requirements.
- Open Sandbox to try workflows supported by the current service.
- Open Console to sign in and manage authorized Workspaces.
You have chosen the right tool for your next task.
02 / 05
Accounts and Workspaces
An account is a manager’s sign-in identity; a Workspace is the authorized organization or tenant scope in the backend.
- Open Console and follow the service’s sign-in flow.
- Confirm that the Workspace you need appears within the account’s authorized scope.
- If a Workspace or required operation is unavailable, ask the person managing access through your organization’s existing process.
- Use existing permissions; never infer Workspace management access from a Meeting join link.
- A Participant is supplied by the organization or admitted as a guest under Meeting policy. Joining a class does not itself require a management account.
You can sign in and have identified the correct Workspace for testing or integration.
03 / 05
Getting started with Sandbox
Sandbox lets you observe and try tasks currently provided for an authorized Workspace.
- Open Sandbox and follow the service’s sign-in flow.
- If the service asks you to sign in again, follow that flow; do not assume Console sessions are shared across domains.
- Select the correct Workspace and read the displayed environment information.
- Choose an available task, follow each step, and observe the result.
- Do not assume automatic deletion or production isolation unless the service confirms it.
You have confirmed the Workspace, environment, and result of a real test task.
04 / 05
Server-side integration
A secure integration should begin in your organization’s backend and follow real contracts in the API Reference.
- Read the documented authentication method for the operation you need.
- Keep server credentials in the backend; never expose secrets in browser or public app code.
- Distinguish server keys from purpose-specific participation or browser session credentials, and use each according to its documented contract.
- Check requests, responses, opaque identifiers, and errors in the API Reference.
- Keep public Workspace, Meeting, and Participant identifiers as server-issued strings; never coerce them to numbers or infer scope from names or email addresses.
- Handle results and failures before connecting the flow to your user interface.
Your backend follows a documented contract without exposing server credentials.
05 / 05
Troubleshooting
First identify whether the problem concerns sign-in, authorization, Sandbox, or an API call.
- Cannot sign in: return to Console and follow the authentication gateway’s feedback.
- Workspace missing or access denied: check the account’s scope using the current access process.
- Sandbox network error: check connectivity and environment information in the service.
- API error: compare the error code, request, and authentication requirements with API Reference.
You know which tool or permission scope to investigate next and have not shared real credentials.
Need to review a specific integration flow?
Describe your integration task and where you need help. The form currently previews your request without sending it.
Discuss integration requirements