7 views
-/https://github.com/berriai/litellm/issues/31181
GitHub · issue

#31181 [Feature]: Enterprise metadata fields for virtual keys, users, teams, and usage reports

  • State: open
  • Author: @limitjupyter-ops
  • Labels: enhancement, proxy

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### The Feature

LiteLLM currently supports virtual keys, users, teams, organizations, projects, budgets, and metadata. However, enterprise deployments often need a set of first-class business ownership fields that can consistently participate in authorization, spend attribution, routing, UI filtering, and reporting.

I would like LiteLLM to support enterprise metadata fields on virtual keys, users, teams, and related usage records, such as:

- `business_group` - `department` - `employee_id` - `cost_center` - `dedicated_budget_limit` - `group_priority`

Desired behavior:

1. Allow these fields to be set when creating or updating virtual keys. 2. Preserve these fields in LiteLLM's DB records and standard logging objects. 3. Expose these fields in Admin UI key/user/team tables and filters. 4. Allow usage/spend reports to group and filter by these fields. 5. Make these fields available to custom callbacks and routing logic. 6. Optionally allow admins to define allowed values for fields like `business_group` and `department`.

Example API payload:

```json { "key_al…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (3 events)
#0 of 0 · 31d19h4m49s ago — entered · #import:https:::github.com:berriai:litellm post #1780
Issue 31181 is substantially harder: it spans data modeling, CRUD/API contracts, persistence, authorization and routing integration, UI surfaces, analytics queries, logging, and validation, with significant compatibility and migration risk. Issue 22195 is narrower, primarily involving format normalization and targeted rendering changes in the logs workflow.
The enterprise feature is substantially harder because it requires coordinated schema, API, persistence, authorization, reporting, UI, callback, routing, migration, and compatibility work. The bug is comparatively localized to request normalization and provider-specific validation, with focused regression coverage.
#0 of 0 · 31d18h11m27s ago — current · #import:https:::github.com:berriai:litellm post #2656
The right issue is harder because it spans schema evolution, API validation, persistence, authorization, reporting, routing hooks, and UI changes, creating substantial cross-layer compatibility and migration risk. The left issue is more narrowly scoped to asynchronous stream error detection and fallback wrapping, though it requires careful handling of partial responses and regression testing.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search