The application token endpoint implements the client credentials
grant (RFC 6749 section 4.4), but its errors did not follow section
5.2: serializer errors were keyed by field, and the other errors used
either `detail` or a free-text `error`. Standard OAuth 2.0 client
libraries could not parse them.
Every error is now rendered as
`{"error": <code>, "error_description": <text>}` by a view-specific
exception handler:
- missing or blank client credentials and wrong credentials or
inactive applications return `invalid_client`
- an unsupported grant type returns `unsupported_grant_type`
- an invalid email, a denied domain or an unknown user return
`invalid_scope`;
- the provisional user creation conflict returns `server_error`,
since the RFC defines no code for server-side failures here
- any other error returns `invalid_request`.
Serializer errors are flattened into one description listing every
invalid field. Descriptions are restricted to the characters allowed
by the RFC, as DRF messages may be translated or contain quotes.
Accept `application/x-www-form-urlencoded` requests on the user
token endpoint, in addition to the existing JSON support.
This aligns the endpoint with the OAuth 2.0 specification for token
endpoint requests (RFC 6749, sections 3.2 and 4.4.2), so standard
OAuth 2.0 client libraries can call it without any customization,
while keeping backward compatibility with existing JSON clients.
Document the changes introduced in #128333, which allows passing
configuration to the external API when creating a room.
Warning: this documentation was generated in a rush using an LLM and
may contain minor errors.
Plan to factorize these YAML files into a common and shared
structure.
Allow external platforms using the public API to create provisional users
with email-only identification when the user doesn't yet exist in our
system. This removes a key friction point blocking third-party integrations
from fully provisioning access on behalf of new users.
Provisional users are created with email as the primary identifier. Full
identity reconciliation (sub assignment) occurs on first login, ensuring
reliable user identification is eventually established.
While email-only user creation is not ideal from an identity perspective,
it provides a pragmatic path to unlock integrations and accelerate adoption
through external platforms that are increasingly driving our videoconference
tool's growth.
Document the external API using a simple Swagger file that can be opened
in any Swagger editor.
The content was mostly generated with the help of an LLM and has been human-
reviewed. Corrections or enhancements to the documentation are welcome.
Currently, my professional email address is included as a contact. A support
email will be added later once available. The documentation will also be
expanded as additional endpoints are added.
briquet