Problem
workos doctor reports dashboardUris: [] and match: false even when redirect URIs are correctly configured in the dashboard. This is because the WorkOS API doesn't expose a public endpoint to list configured redirect URIs.
The source code in src/doctor/checks/dashboard.ts initializes redirectUris as an empty array and never populates it. Comments in the codebase acknowledge this:
// Redirect URI mismatch detection disabled - WorkOS API doesn't expose a public endpoint to list configured redirect URIs for verification
The comparison logic in compareRedirectUris() is fully implemented and ready to work — it just never receives dashboard URIs to compare against.
Impact
doctor reports a misleading match: false for redirect URIs, even when everything is correctly configured
- Users can't verify their redirect URI setup without going to the dashboard UI or trying the POST endpoint and checking for a 422 "already exists" response
- This undermines trust in the
doctor output — if one section is always wrong, users may ignore real issues in other sections
Proposed solution
- WorkOS API: Expose a
GET /user_management/redirect_uris endpoint that lists configured redirect URIs for the current environment
- CLI: Call that endpoint in
fetchDashboardSettings() and populate redirectUris so the existing comparison logic works
Workaround
You can confirm a redirect URI exists by attempting to add it via POST — a 422 "already exists" response confirms it's configured:
curl -s -H "Authorization: Bearer $WORKOS_API_KEY" \
-H "Content-Type: application/json" \
-X POST "https://api.workos.com/user_management/redirect_uris" \
-d '{"uri":"http://localhost:3210/api/auth/callback"}'
Related
Problem
workos doctorreportsdashboardUris: []andmatch: falseeven when redirect URIs are correctly configured in the dashboard. This is because the WorkOS API doesn't expose a public endpoint to list configured redirect URIs.The source code in
src/doctor/checks/dashboard.tsinitializesredirectUrisas an empty array and never populates it. Comments in the codebase acknowledge this:The comparison logic in
compareRedirectUris()is fully implemented and ready to work — it just never receives dashboard URIs to compare against.Impact
doctorreports a misleadingmatch: falsefor redirect URIs, even when everything is correctly configureddoctoroutput — if one section is always wrong, users may ignore real issues in other sectionsProposed solution
GET /user_management/redirect_urisendpoint that lists configured redirect URIs for the current environmentfetchDashboardSettings()and populateredirectUrisso the existing comparison logic worksWorkaround
You can confirm a redirect URI exists by attempting to add it via POST — a 422 "already exists" response confirms it's configured:
Related
redirect removecommand (same underlying gap: no list/delete API)