Moodle is not receiving analytics callbacks

BigBlueButton sends analytics callbacks to Moodle after a live meeting. Moodle uses these events for activity completion and for integrations such as BNX DataHub. If the callback is not delivered or Moodle cannot authenticate it, completion may not be processed and session or attendance data may be missing. This page helps Moodle administrators identify the failure and collect evidence. Web-server changes usually require the hosting or infrastructure administrator.

Signs of a callback problem

BigBlueButton activity completion is not awarded after a qualifying meeting.
Session or attendee data is missing from DataHub reports or another callback-dependent integration.
A new meeting has ended, but Moodle has no corresponding callback or event data.

Check a new, completed test meeting. Existing sessions cannot confirm whether the current callback configuration is working.

Check Moodle settings

Go to Site administration → Plugins → Activity modules → BigBlueButton → Experimental features and enable Register live sessions. Some plugin versions label this Register live events.
If you use BNX DataHub, confirm that BNX and DataHub are installed, enabled, and configured.

Moodle’s standard UI does not display the generated analytics-callback-url sent to BBB. Confirming that URL is present in a meeting’s configuration requires access to the BBB-side meeting request or metadata, or relevant BBB server logs. A Moodle administrator without that access can still verify the setting above and run the connectivity test below, then escalate with the results.

Test from the BigBlueButton server

Run this test on the BBB server that sends the callback, or inside the container that sends it. The request uses an intentionally invalid token, so it can test connectivity and header forwarding without processing an event. The deliberately invalid token cannot process an event:

curl --http1.1 -sS -i --connect-timeout 10 --max-time 20 \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer invalid' \
  --data '{}' \
  'https://moodle.example.edu/mod/bigbluebuttonbn/bbb_broker.php?action=meeting_events&bigbluebuttonbn=30'

Replace the example Moodle base URL with your site’s base URL, including any subpath (for example, https://moodle.example.edu/moodle35), and replace 30 with the activity’s BigBlueButton instance ID. To find that ID without SQL, hover over the activity’s Join button and read the link preview. In a URL such as bbb_view.php?action=join&id=32&bn=30, use bn (30), not id (32); id is the course-module ID. If your browser does not show a link preview, right-click Join and copy its link address. Keep the callback URL quoted so the shell does not interpret the ampersands.

Interpret the response

Run the same command before and after the hosting change. The invalid token is deliberate, so the successful result for this test is still an HTTP 400; the response text should change when PHP starts receiving the header.

Result	What it indicates
`400 Bad Request. Authorization failed`	The request reached Moodle, but PHP did not receive the `Authorization` header. This is the failing result; ask hosting support to check header forwarding.
`400 Bad Request. Caught exception: Wrong number of segments`	The header reached Moodle and JWT parsing ran. This is the expected result for the deliberately invalid token after header forwarding is fixed. Other JWT parsing or validation errors also indicate the header arrived.
`200` or `202` from a real callback	Moodle accepted the callback. `200` indicates it was processed; `202` indicates it was already processed.
`404` or `410`	Check the callback path and activity instance ID. `410` can mean the activity no longer exists.
`403`, timeout, DNS, TLS, or connection error	Investigate access controls, routing, DNS, or certificates between BBB and Moodle.

A request from a laptop only tests the laptop-to-Moodle path. It does not prove that BBB can reach Moodle, and the dummy-token test does not verify the shared secret or event payload.

Escalate to hosting support

If the BBB-host test returns Authorization failed, send hosting support:

the UTC time of the test and the source IP of the BBB server
the Moodle callback path and activity instance ID
the HTTP status and response text
the note that Moodle’s callback handler reports a missing or unusable Authorization header

Ask them to verify that the Authorization request header is preserved through every proxy and passed from the web server to PHP. Do not send or log the real JWT or BigBlueButton shared secret.

Apache with CGI or FastCGI

Apache may need to pass the incoming authorization header to the PHP handler. The hosting administrator should check the active virtual host and PHP handler. Depending on the setup, CGIPassAuth On may be appropriate in the Moodle directory configuration, or the following rewrite workaround can expose the header to PHP:

RewriteEngine On
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [E=HTTP_AUTHORIZATION:%1]

If using .htaccess, Apache must allow the relevant rewrite directives there. Scope the change to the Moodle site and have the administrator validate the configuration before reloading Apache.

Nginx with PHP-FPM

In the PHP location block, the administrator should confirm the authorization header is passed to FastCGI:

fastcgi_param HTTP_AUTHORIZATION $http_authorization;

Check the include order so another FastCGI parameter file does not override it. If a load balancer or reverse proxy sits in front of Nginx or Apache, it must also preserve the Authorization header.

If the header reaches Moodle

If the dummy-token test changes from Authorization failed to Caught exception: Wrong number of segments (or another JWT parsing error) after the hosting change, header forwarding is working. This does not validate a real callback’s token or payload. If real callbacks still fail, ask the Moodle and BBB administrators to verify that both sides use the same shared secret, that the callback token is valid and unexpired, and that BBB is sending the expected JSON event payload. For older BBB deployments, event retention and post-event processing may require additional BBB configuration. The required setup depends on the BBB version; the BBB administrator should verify that analytics events are enabled and that the callback worker is running. After a real callback succeeds, check Moodle’s BigBlueButton callback logs and then verify completion or DataHub data. If Moodle accepts the callback but downstream data is still missing, investigate the relevant completion rules, DataHub configuration, and scheduled processing separately.

Overview

Get Started

Teachers

Admins

BNX

Reference

Troubleshooting

Moodle is not receiving analytics callbacks

Signs of a callback problem

Check Moodle settings

Test from the BigBlueButton server

Interpret the response

Escalate to hosting support

Apache with CGI or FastCGI

Nginx with PHP-FPM

If the header reaches Moodle

​Signs of a callback problem

​Check Moodle settings

​Test from the BigBlueButton server

​Interpret the response

​Escalate to hosting support

​Apache with CGI or FastCGI

​Nginx with PHP-FPM

​If the header reaches Moodle

​Related pages

Signs of a callback problem

Check Moodle settings

Test from the BigBlueButton server

Interpret the response

Escalate to hosting support

Apache with CGI or FastCGI

Nginx with PHP-FPM

If the header reaches Moodle

Related pages