[Feature] Key list endpoint: Add project_id and access_group_id filters

[yuneng-jiang]

Summary

Added project_id and access_group_id filtering parameters to the /key/list endpoint. Both filters are applied as global AND conditions that narrow results across all visibility rules (user keys, team keys, etc.) and work with existing sort/pagination parameters. The access_group_id filter uses Prisma's hasSome operator to check if a key's access_group_ids array contains the specified ID.

Testing

Added 3 unit tests:

• test_build_key_filter_project_id: Verifies project_id creates proper AND condition
• test_build_key_filter_access_group_id: Verifies access_group_id uses hasSome for array filtering
• test_build_key_filter_project_id_and_access_group_id: Verifies both filters stack correctly

All existing tests pass with no regressions.

Type

🆕 New Feature
✅ Test

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Building	Preview, Comment	Feb 28, 2026 5:26am

[greptile-apps]

Greptile Summary

Adds project_id and access_group_id query parameters to the /key/list endpoint, allowing callers to filter keys by project or access group. Both filters are applied as global AND conditions in _build_key_filter_conditions, so they narrow results across all visibility rules (own keys, team keys, etc.). The access_group_id filter correctly uses Prisma's hasSome operator for the String[] column.

• Added project_id and access_group_id as optional query params to list_keys
• Threaded both params through _list_key_helper into _build_key_filter_conditions
• Applied filters as global AND conditions that compose with existing visibility OR conditions
• Added 3 unit tests covering individual and combined filter behavior
• No new DB queries introduced — only filter construction is modified

Confidence Score: 4/5

• This PR is safe to merge — it adds optional query filters with sensible defaults and does not alter existing behavior.
• The change is minimal, well-scoped, and follows established patterns in the codebase. New parameters default to None, so existing callers are unaffected. The Prisma schema confirms both project_id (String?) and access_group_ids (String[]) exist on the key table, and hasSome is the correct operator for array containment checks. Unit tests cover the key scenarios. Minor deduction because the nested AND structure when both filters are applied creates deeper nesting than necessary, though it is functionally correct.
• No files require special attention.

Important Files Changed

Filename	Overview
litellm/proxy/management_endpoints/key_management_endpoints.py	Adds project_id and access_group_id query parameters to list_keys, threads them through _list_key_helper to _build_key_filter_conditions, where they are applied as global AND filters. Clean, minimal change with correct Prisma hasSome usage for the array field.
tests/test_litellm/proxy/management_endpoints/test_key_management_endpoints.py	Adds 3 unit tests covering project_id filtering, access_group_id filtering with hasSome, and the combination of both filters. Tests are pure mock-free unit tests verifying filter construction — no network calls.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["GET /key/list"] -->|"project_id, access_group_id params"| B["list_keys()"]
    B --> C["validate_key_list_check()"]
    C --> D["_list_key_helper()"]
    D --> E["_build_key_filter_conditions()"]
    E --> F{"Build visibility\nOR conditions"}
    F --> G["user_condition\n(own keys)"]
    F --> H["admin_team_ids\n(team admin keys)"]
    F --> I["member_team_ids\n(service accounts)"]
    G --> J{"project_id\nprovided?"}
    H --> J
    I --> J
    J -->|Yes| K["Wrap in AND:\nwhere + project_id filter"]
    J -->|No| L{"access_group_id\nprovided?"}
    K --> L
    L -->|Yes| M["Wrap in AND:\nwhere + hasSome filter"]
    L -->|No| N["Return where\ndict to Prisma"]
    M --> N

Loading

_{Last reviewed commit: 6d8b5b7}

[greptile-apps]

_{2 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Nested AND creates deep nesting

When both project_id and access_group_id are provided, the sequential wrapping produces a doubly-nested AND: {"AND": [{"AND": [where, project_filter]}, access_group_filter]}. This works correctly with Prisma but could be flattened into a single AND list for readability and consistency with the pattern used above on line 4350.

Suggested change

	if project_id:
	where = {"AND": [where, {"project_id": project_id}]}
	if access_group_id:
	where = {"AND": [where, {"access_group_ids": {"hasSome": [access_group_id]}}]}
	if project_id or access_group_id:
	and_parts = [where]
	if project_id:
	and_parts.append({"project_id": project_id})
	if access_group_id:
	and_parts.append({"access_group_ids": {"hasSome": [access_group_id]}})
	where = {"AND": and_parts}

Note: adopting this would require updating the combined-filter test (test_build_key_filter_project_id_and_access_group_id) to expect a flat 3-element AND list instead of nested ANDs.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}