Graph API: POST /solutions/virtualEvents/webinars fails with "Could not find culture info for organizer locale: *." (BadRequest)

We're creating Teams webinars via delegated Graph API calls (VirtualEvent.ReadWrite scope,

POST /solutions/virtualEvents/webinars → POST .../publish → GET .../registrationConfiguration),

and intermittently hit this error on the initial create call:

Microsoft Graph 400: {"error":{"code":"BadRequest","message":"Could not find culture info for

organizer locale: *.","innerError":{...}}}

Request IDs from three separate occurrences:

• 6a06bd0e-98f6-492c-b495-53400ef7f59f (2026-09-01T18:42:18)
• 967cd8cb-f27d-4070-bdef-6e02d6a28882 (2026-08-27)
• a52ed5b8-4ce0-41ad-9a73-280fd9946111 (2026-08-27)

What we've already tried, all without resolving it:

1. Explicitly setting the organizer's Exchange mailbox locale (PATCH /me/mailboxSettings, { language: { locale: "nb-NO" } }) — both once at OAuth-connect time and freshly re-asserted immediately before every single creation attempt.
2. Explicitly setting the organizer's Entra ID preferredLanguage attribute (PATCH /me, { preferredLanguage: "nb-NO" }) — same "re-assert immediately before every attempt" treatment, run in parallel with #1.
3. Verifying the delegated token actually carries the scopes needed for #1/#2 (User.ReadWrite, MailboxSettings.ReadWrite) before every creation attempt — confirmed present, not the cause.
4. Retrying the create call once, immediately, after re-asserting both fields again — still fails with the identical error on the retry.

The one reproducible pattern we've found: creation succeeds immediately after a fresh

interactive OAuth reconnect (disconnect + reconnect the same organizer), then fails again

on the next attempt with no code or configuration change in between. That, plus #1-4 above

having zero effect even when re-applied seconds before the failing call, suggests the

"organizer locale" this endpoint reads isn't coming from either mailboxSettings.language.locale

or Entra ID preferredLanguage at all — possibly a tenant-level Teams/virtual-events policy

default, or a backend-side caching/propagation issue we can't see from the client side.

Could someone with access to the backend logs for these request IDs tell us which field this

error actually reads, and why it would reset to unset again after a successful creation?

Tenant: Making View AS (Norwegian M365 tenant). Organizer license: [E3/E5/Teams Premium —

confirm which]. Happy to provide a HAR capture or additional request IDs on request.