Skip to content

OMeet Developer Docs

OMeet developer documentation

Get started with OMeet accounts, Workspaces, and integration tools.

Content updated: 25 September 2026

01 / 05

Overview

OMeet provides four entry points so that each tool keeps a clear purpose.

  1. Read Docs to understand the sequence and concepts to prepare.
  2. Use API Reference for specific operations, data, and authentication requirements.
  3. Open Sandbox to try workflows supported by the current service.
  4. Open Console to sign in and manage authorized Workspaces.
You are done when

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.

  1. Open Console and follow the service’s sign-in flow.
  2. Confirm that the Workspace you need appears within the account’s authorized scope.
  3. If a Workspace or required operation is unavailable, ask the person managing access through your organization’s existing process.
  4. Use existing permissions; never infer Workspace management access from a Meeting join link.
  5. 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 are done when

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.

  1. Open Sandbox and follow the service’s sign-in flow.
  2. If the service asks you to sign in again, follow that flow; do not assume Console sessions are shared across domains.
  3. Select the correct Workspace and read the displayed environment information.
  4. Choose an available task, follow each step, and observe the result.
  5. Do not assume automatic deletion or production isolation unless the service confirms it.
You are done when

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.

  1. Read the documented authentication method for the operation you need.
  2. Keep server credentials in the backend; never expose secrets in browser or public app code.
  3. Distinguish server keys from purpose-specific participation or browser session credentials, and use each according to its documented contract.
  4. Check requests, responses, opaque identifiers, and errors in the API Reference.
  5. Keep public Workspace, Meeting, and Participant identifiers as server-issued strings; never coerce them to numbers or infer scope from names or email addresses.
  6. Handle results and failures before connecting the flow to your user interface.
You are done when

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.

  1. Cannot sign in: return to Console and follow the authentication gateway’s feedback.
  2. Workspace missing or access denied: check the account’s scope using the current access process.
  3. Sandbox network error: check connectivity and environment information in the service.
  4. API error: compare the error code, request, and authentication requirements with API Reference.
You are done when

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