Orgstructure children and children/paged routes return HTTP 500 for Semester parents after July 2026

Question

We are experiencing a reproducible Brightspace Organization Structure API regression that was first observed around July 7, 2026. Both GET /d2l/api/lp/{version}/orgstructure/{semesterOrgUnitId}/children/ and GET /d2l/api/lp/{version}/orgstructure/{semesterOrgUnitId}/children/paged/ return HTTP 500 Internal Server Error when the parent is a Semester org unit. For example, GET /d2l/api/lp/1.62/orgstructure/1127845/children/paged/?ouTypeId=3 returns {"type":"about:blank","title":"Internal Server Error","status":500}. The same failure occurs with LP API versions 1.54 and 1.62, with and without the ouTypeId filter, and against both newly created and older semesters, so it is not limited to newly created course offerings or one client implementation. The organization-root children call succeeds, exact course-offering searches succeed, individual org-unit reads succeed, and parent and ancestor calls for the same courses succeed. The failure occurs specifically while enumerating children beneath a Semester. We reproduced this using both our established legacy integration and a new Python client, ruling out a client-library issue. The OAuth application has the documented organizations:organization:read scope, the access token was refreshed, and the calling service account uses a cascading administrative role. We also explicitly enabled both View Org Unit Editor and Can Create and Edit Org Units for the role at the Organization and Department org-unit types; the Permissions API confirms all four grants are allowed, but the children request continues to return 500. Brightspace documentation states that insufficient org-structure permission should return 403 Forbidden, not 500. Could D2L please confirm whether this is a known regression involving Organization Structure or Distributed Administration permission evaluation, provide a defect tracking number, and advise on a supported workaround and expected resolution timeline? We can provide tenant details, org-unit IDs, timestamps, and request correlation information privately through a support case.

Carolina.A.7123 · Answer

Hi @Ian.H.495,

Yes, that is correct.

20.26.7.20575 is older than both 20.26.7.22255 (which contains the fix) and 20.26.7.23576.

In this case, a hotfix was released for the defect and applied to Production environments, which would explain why your Production environment running 20.26.7.23576 is no longer exhibiting the behavior.

Your Dev and QA environments, however, are still running 20.26.7.20575, which predates the fix. Non-production environments generally do not receive hotfix deployments and are instead updated according to their normal wave schedule.

You can review the update schedule here:

https://community.d2l.com/brightspace/kb/articles/1048-wave-schedule

That page should help you determine when your Dev and QA environments (Wave 2) are expected to receive a newer build.

I hope this helps clarify the version differences.

Thank you,

Carolina

Ian.H.495 · Answer

Our dev and qa are 20.26.7.20575 if I am reading your version numbering correctly seem like dev and qa are outdated. Our prod is 20.26.7.23576. So that explains why prod is still running properly.  I will have to get in touch with our Admins to see why our dev and qa environments don't seem to be getting updated. Can you please confirm that 20.26.7.20575 is older than 20.26.7.22255 and 20.26.7.23576. Thanks for your help.

Carolina.A.7123 · Answer

Hi @Ian.H.495,

Thank you for reaching out to us within the Brightspace Community!

The behaviour you are describing seems to be related to the following known issue:

https://community.d2l.com/brightspace/kb/articles/35151-organization-structure-apis-giving-error-when-querying-at-organization

This issue was resolved in 20.26.7.22255.

While the article specifically references failures when querying at the organization level, I have also seen cases where organization structure API requests returning larger result sets (requiring pagination) exhibited similar HTTP 500 behaviour. In those instances, the issue was resolved after the deployment of the fix associated with this defect.

If your environment is running a version earlier than 20.26.7.22255, I would expect the issue to still occur. If your environment is on 20.26.7.22255 or later and you continue to encounter the error, please open a Support case and include the affected org unit IDs, timestamps, and any request correlation information so that we can investigate further.

I hope this helps clarify what you're seeing.

Thank you,

Carolina