Integrate BigBlueButton with Schoology

01

Choose the supported integration path

BigBlueButton’s integration directory identifies Schoology as an LTI integration. Use a dedicated BBB LTI key and secret, then install and assign the app only to a pilot organization or course before wider rollout.

• Schoology system-administrator access.
• BBB LTI endpoint tested independently.
• App assignment and data-sharing policy approved.

02

Prepare BigBlueButton and credentials

Use a production BigBlueButton endpoint with a trusted TLS certificate. Keep the API shared secret or LTI secret on the server side: it is equivalent to an application credential and must never be placed in browser code, a public repository or a screenshot.

1. 1

   Confirm the BigBlueButton server is healthy and that its public hostname resolves correctly.

2. 2

   Retrieve the API URL and shared secret with sudo bbb-conf --secret, or create a dedicated LTI key and secret where the integration uses LTI.

3. 3

   Record the platform version, connector version, owner and rollback point before making the change.

sudo bbb-conf --check
sudo bbb-conf --secret

03

Configure Schoology

Make the first connection in a staging course, workspace or tenant. Use a dedicated test teacher and test learner so role mapping can be observed rather than inferred from an administrator account.

1. 1

   Create a Schoology organization app/custom LTI tool with the BBB /lti launch URL.

2. 2

   Enter the dedicated consumer key and secret and select only required privacy fields.

3. 3

   Install the app for a pilot organization, course or users.

4. 4

   Place the tool in the course and verify instructor visibility before publishing.

04

Run an end-to-end acceptance test

A green “connection successful” message proves only that one API request worked. The useful test follows the complete classroom lifecycle from creation through recording publication.

1. 1

   Launch as course administrator, instructor and student.

2. 2

   Verify a student cannot create or end instructor meetings unless intended.

3. 3

   Test copied courses and new academic-term provisioning.

4. 4

   Confirm recording visibility and removal after unenrolment.

05

Common problems and practical fixes

Start with timestamps, browser developer tools and the logs on both sides. Repeatedly replacing secrets rarely fixes a hostname, TLS, role or callback problem and makes the evidence harder to follow.

• An installed app may still need organization or course assignment.
• Wrong privacy settings can result in generic names or broken role mapping.
• Iframe restrictions may require launching in a new window.

06

Production hardening and upgrades

Restrict who can create rooms, define recording retention, test accessibility and document the integration owner. Pin or approve connector updates, subscribe to upstream releases and repeat the acceptance test after changes to the LMS, connector, BigBlueButton or reverse proxy.

• Do not expose the BigBlueButton shared secret to course authors or client-side JavaScript.
• Use least-privilege teacher roles and test guest, suspended and unenrolled users.
• Monitor API errors, failed joins, recording processing and disk growth.
• Keep a short rollback runbook: previous package, configuration backup and maintenance window.