H5P Scheduled Task fails with HTTP 405 on hub-api.h5p.org/v1/sites (Moodle 5.2)
Hi everyone,
I am facing an issue with the H5P content types download task (core\task\h5p_get_content_types_task) on a fresh Moodle 5.2 installation hosted on Hostinger.
Whenever the scheduled task runs (either via cron or forced through CLI), it fails with an HTTP 405 Method Not Allowed error when trying to reach the H5P registration endpoint.
Here is the output when running the task via CLI:
[Execute scheduled task: Download available H5P content types from h5p.org (core\task\h5p_get_content_types_task)
... started 15:01:51. Current memory use 13.2 MB.
Debugging increased temporarily due to faildelay of 60
++ cURL request for "https://hub-api.h5p.org/v1/sites" failed, HTTP response code: HTTP/2 405
++
* line 1670 of /public/lib/filelib.php: call to debugging()
* line 380 of /public/h5p/classes/core.php: call to download_file_content()
* line 367 of /public/h5p/classes/core.php: call to core_h5p\core->register_site()
...
Scheduled task failed: Download available H5P content types from h5p.org (core\task\h5p_get_content_types_task),Invalid response value detected (No information could be obtained on the H5P content types available. H5P repository connection failure)]
Troubleshooting already done:
I suspected a hosting firewall block, so I ran a connectivity test via SSH directly from the server:
- curl -I https://h5p.org -> Returns HTTP/2 200 (Cloudflare)
- curl -I https://api.h5p.org -> Returns HTTP/1.1 404 (Nginx)
This confirms that outbound cURL requests are fully enabled on my server and it can talk to H5P servers. The 405 error seems to be specific to the POST/registration request that Moodle sends to https://hub-api.h5p.org/v1/sites.
Has anyone encountered this HTTP 405 error during site registration/content type updates recently? Is there any specific PHP or user-agent setting required to prevent the Hub API from rejecting Moodle's request?
Thank you in advance for your help!
otacke
Sat, 05/23/2026 - 22:26
Permalink
That error message may be a
That error message may be a lie. I remember getting it as well when exploring the new hub-api. h5p.org endpoints which do not behave the same way the old api.h5p.org endpoints do. What endpoint were you trying to call exactly?
otacke
Sat, 05/23/2026 - 22:31
Permalink
Oh, silly me. "sites". Will
Oh, silly me. "sites". Will check what it expects later.
otacke
Sun, 05/24/2026 - 17:28
Permalink
Hi!Here's what a POST call to
Hi!
Here's what a POST call to the path `/sites/` requires.
The requestBody needs at least these four key/value pairs:
I am not aware whether the values are actually evaluated on the server, but at least for retrieving the response, they can be arbitrary within the given type constraints.
So, something like ...
curl --location 'hub-api.h5p.org/v1/sites' --form 'platform_name="My cool H5P platform"' --form 'disabled="0"' --form 'local_id="12345678"' --form 'type="foo"'will yield something like ...
{"uuid": "019e5a8b-5f47-734f-bb3d-157b1fd98734"}That UUID is supposed to be stored on the platform as the "site uuid" and to be sent with other requests.
From what I figure, Moodle's own H5P integration also puts the key `uuid` onto the request body set, and then the endpoint indeed sends an error message: HTTP error code 405 and the nonsense response message
{"message": "The GET method is not supported for route v1/sites. Supported methods: POST."}).My best guess is that H5P Group silently changed the API endpoint, Moodle HQ was not informed and also did not test the cron job. So, Moodle HQ would need to fix this (and not set the uuid when calling `sites`.