Custom OAuth apps
Set General > Public Base URL before creating provider applications. For an
origin of https://brokerr.example.com, combine it with the callback path below.
| Target | Callback path | Provider setup |
|---|---|---|
| AniList | /api/auth/anilist/callback | Register the full HTTPS URL in the AniList application. |
| MyAnimeList | /api/auth/mal/callback | Register the full HTTPS URL in the MAL API application. |
| TMDB | /api/auth/tmdb/callback | TMDB account approval returns through this instance route; TMDB does not expose the same callback registration field as the OAuth providers. |
| SIMKL | /api/auth/simkl/callback | Register the full HTTPS URL in the SIMKL application. |
| Trakt | /api/auth/trakt/callback | Register the full HTTPS URL in the Trakt application. |
General procedure
Section titled “General procedure”- Create an application in the provider’s developer/API settings.
- Register the exact HTTPS callback where the provider supports that field.
- Copy the client ID and client secret into the Brokerr target.
- Select Custom OAuth application and save Settings.
- Connect, approve access, verify the connected identity, and test reads.
Do not commit client secrets or paste them into screenshots, issue reports, URLs, or reverse-proxy configuration. Leaving the secret field blank during a later edit preserves the encrypted existing value.
An invalid_client provider response normally means the ID/secret pair belongs
to another application, contains whitespace, or does not match the registered
callback. A callback mismatch must be corrected at both the provider and Public
Base URL.