Developer guide

Integrating with the BigBlueButton API

A sound integration does more than generate join URLs. It owns meeting identity, authorisation, idempotency, callbacks and the recording lifecycle without leaking the shared secret.

7 min read Reviewed July 1, 2026 3 primary & community sources

01 Your application Authenticates user and decides role

→

02 Server-side signer Builds checksum with the shared secret

→

03 BBB API Creates meeting and returns signed join path

→

04 Callbacks Meeting-ended and recording-ready events

Keep signing and policy on the trusted side of your application.

Executive brief

What matters

01
Make every API call from trusted server-side code; the BigBlueButton shared secret must never reach the client.
02
Use a stable internal meeting ID and treat create as an idempotent lifecycle operation.
03
Verify callback authenticity and reconcile state by querying the API rather than trusting one delivery.

Build a narrow server-side adapter

BigBlueButton’s HTTPS API uses a checksum derived from the call name, encoded query string and shared secret, and returns XML. Put signing, transport, parsing, timeouts and error translation in one adapter. The rest of your application should call domain methods such as createClassroom or publishRecording, not assemble query strings.

Own identity and authorisation

BigBlueButton does not provide your user database or application permission model. Authenticate users in your LMS or service, decide attendee versus moderator server-side, and issue a short-lived join flow. Never accept a moderator password or arbitrary role from a browser request without re-authorising it.

Model meeting state carefully

Use a non-secret meeting ID that is stable for the intended session and an unpredictable attendee path or access control in your application. Store the parameters used to create it. Handle a repeated create safely, check isMeetingRunning when useful and do not infer that a successful redirect means the meeting completed.

Treat callbacks as notifications

Meeting-ended and recording-ready callbacks reduce polling, but delivery can be duplicated, delayed or blocked by proxy configuration. Validate the callback mechanism supported by your version, authenticate where possible, make handlers idempotent and confirm the current recording state through getRecordings before changing user-visible status.

Evidence base

Sources and further reading

We prefer project documentation and first-party product guidance. Community links are included where they reveal recurring operational questions rather than establish product guarantees.

Practical answers

Questions teams ask

Can the browser call the BigBlueButton API directly?

It should not. Signing requires the shared secret, which must remain in trusted server-side code.

Does BigBlueButton return JSON?

The documented API primarily returns XML. Parse it defensively and preserve error codes and messages for operations.

How should recordings be managed?

Use getRecordings as the source of current state, then publish, unpublish, update metadata or delete through authorised server-side operations.

What matters

Build a narrow server-side adapter

Own identity and authorisation

Model meeting state carefully

Treat callbacks as notifications

Sources and further reading

Questions teams ask

Related guides and infrastructure

How to integrate BigBlueButton with Moodle

SSO with Microsoft Entra ID, Google Workspace and LDAP

Scalelite architecture and operations