feat(ui): migrate api-keys landing to App Router path route#30699
Merged
ryan-crabbe-berri merged 2 commits intoJun 19, 2026
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Contributor
Greptile SummaryThis PR continues the App Router migration by moving the "Virtual Keys" landing from the legacy
Confidence Score: 5/5Safe to merge — this is a routing refactor with no backend changes, and the core logic (bare landing inline render, invitation flow, return-URL handling) is preserved correctly. The explicitPage !== null guard is the critical correctness hinge and it is applied correctly, preventing the bare /ui/ landing from bouncing to /ui/api-keys and breaking the post-login return-URL and invitation flows. The shared ApiKeysDashboard component faithfully reproduces the prefill-param validation from the old index page. All changed constants are updated in lockstep across production code, unit tests, and e2e fixtures. No files require special attention. The e2e spec has a minor no-op iteration for the api-keys segment, but it does not mask any real regression.
|
| Filename | Overview |
|---|---|
| ui/litellm-dashboard/src/app/(dashboard)/api-keys/ApiKeysDashboard.tsx | New shared component extracting the UserDashboard + team/org fetch into a reusable widget; used by both the new path route and the bare landing index page. |
| ui/litellm-dashboard/src/app/(dashboard)/api-keys/page.tsx | New App Router route for /ui/api-keys; gates on useAuthorized (same auth pattern as every other migrated route) and renders ApiKeysDashboard inside Suspense. |
| ui/litellm-dashboard/src/app/(dashboard)/page.tsx | Non-invitation path now renders ApiKeysDashboard directly; isLegacyRedirect correctly guards on explicitPage !== null so bare /ui/ landing stays inline; invitation flow unchanged. |
| ui/litellm-dashboard/src/utils/migratedPages.ts | Adds api-keys → api-keys entry to MIGRATED_PAGES, enabling the sidebar repoint and ?page=api-keys redirect. |
| ui/litellm-dashboard/e2e_tests/tests/migration/migratedPages.spec.ts | Round-trip step updated from legacy ?page=api-keys to the new path route; variable renamed legacyAnchor → virtualKeysLink. For the api-keys segment itself the round-trip is now a no-op (navigate to api-keys, then back to api-keys), so cross-navigation is not exercised for that segment. |
Reviews (2): Last reviewed commit: "feat(ui): migrate api-keys landing to Ap..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
ryan-crabbe-berri
force-pushed
the
litellm_migrate_api_keys_page
branch
from
5601798 to
df9a710
Compare
Cut the default "Virtual Keys" landing (?page=api-keys) over to a path route at (dashboard)/api-keys. The dashboard is extracted into a shared ApiKeysDashboard component used by both the new route and the index's inline render, so there's no duplication. Adding the MIGRATED_PAGES entry repoints the sidebar item and redirects ?page=api-keys to /ui/api-keys. The index is the post-login landing and still hosts the legacy switch for the not-yet-migrated pages (models, pass-through, usage) plus the invitation flow, so it stays. The auto-redirect now fires only for an explicit ?page= param, leaving the bare /ui/ landing to render inline; this keeps the return-URL handling and the invitation_id flow (both of which run at the bare landing) intact, where a blanket redirect would have dropped them. The new route uses useAuthorized for the login gate, matching every other migrated route.
ryan-crabbe-berri
force-pushed
the
litellm_migrate_api_keys_page
branch
from
df9a710 to
526a594
Compare
Collaborator
Author
|
@greptileai re review |
…itellm_migrate_api_keys_page # Conflicts: # ui/litellm-dashboard/src/app/(dashboard)/page.tsx
yuneng-berri
approved these changes
Jun 19, 2026
ryan-crabbe-berri
merged commit 32bdd00
into
litellm_internal_staging
120 of 122 checks passed
fzowl
pushed a commit
to fzowl/litellm
that referenced
this pull request
Jun 24, 2026
…30699) Cut the default "Virtual Keys" landing (?page=api-keys) over to a path route at (dashboard)/api-keys. The dashboard is extracted into a shared ApiKeysDashboard component used by both the new route and the index's inline render, so there's no duplication. Adding the MIGRATED_PAGES entry repoints the sidebar item and redirects ?page=api-keys to /ui/api-keys. The index is the post-login landing and still hosts the legacy switch for the not-yet-migrated pages (models, pass-through, usage) plus the invitation flow, so it stays. The auto-redirect now fires only for an explicit ?page= param, leaving the bare /ui/ landing to render inline; this keeps the return-URL handling and the invitation_id flow (both of which run at the bare landing) intact, where a blanket redirect would have dropped them. The new route uses useAuthorized for the login gate, matching every other migrated route.
13 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Relevant issues
Linear ticket
Refs LIT-3687
Pre-Submission checklist
Please complete all items before asking a LiteLLM maintainer to review your PR
make test-unit@greptileaiand received a Confidence Score of at least 4/5 before requesting a maintainer reviewCI (LiteLLM team)
Branch creation CI run
Link:
CI run for the last commit
Link:
Merge / cherry-pick CI run
Links:
Screenshots / Proof of Fix
UI routing change, no backend component. To verify locally against the built export or the proxy that serves it:
/ui/api-keysand the keys dashboard renders (key table, Create Key, teams)/ui/api-keysdirectly and confirm it still renders (no 404) and that an unauthenticated session is redirected to login/ui/and confirm it renders the dashboard inline (it does not bounce to/ui/api-keys), and that an old bookmark/ui/?page=api-keysredirects to/ui/api-keys/ui/?invitation_id=<id>still renders the invitation dashboard (it must not redirect)Type
🧹 Refactoring
Changes
Continues the App Router migration by cutting the default "Virtual Keys" landing (
?page=api-keys) over from the?page=switch in(dashboard)/page.tsxto a path route at(dashboard)/api-keys/page.tsx. The dashboard rendering and its state are extracted into a sharedApiKeysDashboardcomponent used by both the new route and the index's inline render, so the page is defined once. Adding theapi-keys -> api-keysentry toMIGRATED_PAGESrepoints the sidebar item and redirects?page=api-keysdeep links to/ui/api-keys.This is the root/landing page, so it is more coupled than the earlier cutovers. With models, pass-through, and old-usage now merged, the index no longer hosts a
?page=switch; its non-invitation render is simply<ApiKeysDashboard />, and it still holds the survey/Claude-Code nudges, theinvitation_idflow, and the login/return-URL effects. The one behavioral change is that the legacy auto-redirect now fires only when a page is explicitly requested via?page=; the bare/ui/landing renders inline as before. That keeps the post-login return-URL handling and the invitation flow (both of which run at the bare landing) working, where redirecting/ui/to/ui/api-keyswould have dropped the stored return URL and theinvitation_id. The new route gates onuseAuthorized, the same login path every other migrated route uses.Scope note: this is the partial step. The index still holds the nudges, the invitation flow, and the login/return-URL effects; the closeout PR thins it to a redirect and relocates that cross-cutting logic into the layout. This branch was rebased onto the merged models, pass-through, and old-usage PRs.
Added a unit test asserting the
api-keys -> api-keysmapping and its redirect href, and the e2e migration fixture entry so the navigation smoke covers it. The migration smoke also had a round-trip step that bounced to the api-keys page as a legacy?page=api-keysURL; since api-keys is now a path route, that helper was renamed (legacyAnchor->virtualKeysLink) and the assertion updated to/ui/api-keys.