feat(datadog): add team-scoped Datadog callback support

[aanchal22]

Relevant issues

Issue addressed - #29939

Pre-Submission checklist

• I have added meaningful tests
• My PR passes all unit tests on make test-unit
• My PR's scope is as isolated as possible; it only solves 1 specific problem

Type

Feature

Changes

Adds team-scoped Datadog callback support, following the same pattern as Langfuse. Teams can now configure their own Datadog credentials via POST /team/{team_id}/callback to route logs to their own Datadog org.

What was missing

1. DataDogLogger only read DD_API_KEY/DD_SITE from env vars — no per-team credential support
2. No client isolation — all traffic went to one DD org
3. dd_api_key/dd_site not in StandardCallbackDynamicParams allow-list

What changed

• DataDogLogger.__init__() now accepts dd_api_key, dd_site, dd_agent_host, dd_agent_port as kwargs (falls back to env vars for global use)
• DataDogHandler (new) resolves per-team DataDogLogger instances using DynamicLoggingCache, same pattern as LangFuseHandler
• StandardCallbackDynamicParams and _supported_callback_params include DD params
• _init_custom_logger_compatible_class uses DataDogHandler when team credentials are present
• 15 unit tests covering credential kwargs, handler resolution, caching, and isolation

Existing behavior unchanged

Global Datadog callback (env-var based) continues to work exactly as before.

Screenshots / Proof of Fix

Adding team-scoped Datadog callback:

$ curl -sS "$BASE/team/dd-test-team/callback" \
  -H "Authorization: Bearer $MASTER" \
  -H "Content-Type: application/json" \
  -d '{"callback_name":"datadog","callback_type":"success_and_failure","callback_vars":{"dd_api_key":"test-team-dd-key-123","dd_site":"us5.datadoghq.com"}}' | jq .status

"success"

Callback stored in team metadata:

$ curl -sS "$BASE/team/info?team_id=dd-test-team" \
  -H "Authorization: Bearer $MASTER" | jq '.team_info.metadata'

{
  "logging": [
    {
      "callback_name": "datadog",
      "callback_type": "success_and_failure",
      "callback_vars": {
        "dd_site": "us5.datadoghq.com",
        "dd_api_key": "test-team-dd-key-123"
      }
    }
  ]
}

Request with team key routes logs to team's DD site (403 expected with fake key):

$ curl -sS "$BASE/v1/chat/completions" \
  -H "Authorization: Bearer $TEAM_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"dd-test-model","messages":[{"role":"user","content":"test"}]}' | jq .choices[0].message.content

"hello from dd test"

Proxy log confirms team's DD site was used:

Datadog Error sending batch API - Client error '403 Forbidden'
  for url 'https://http-intake.logs.us5.datadoghq.com/api/v2/logs'

The logger correctly used us5.datadoghq.com (from team's dd_site) instead of any global default.

[CLAassistant]

All committers have signed the CLA.

[aanchal22]

@greptileai

[codecov]

Codecov Report

❌ Patch coverage is 92.06349% with 5 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
litellm/litellm_core_utils/litellm_logging.py	54.54%	5 Missing ⚠️

📢 Thoughts on this report? Let us know!

[greptile-apps]

Greptile Summary

This PR adds team-scoped Datadog callback support by extending DataDogLogger.__init__ with explicit credential kwargs, introducing DataDogHandler for per-team logger resolution via DynamicLoggingCache, and wiring the routing logic through _init_custom_logger_compatible_class. The ordering fix in Logging.__init__ (initializing standard_callback_dynamic_params before process_dynamic_callbacks) is necessary and correct.

• DataDogLogger now accepts dd_api_key/dd_site/dd_agent_host/dd_agent_port as constructor kwargs, falling back to env vars for global use — existing deployments are unaffected.
• _process_dynamic_callback_list filters dd_* keys from standard_callback_dynamic_params and forwards them exclusively to the datadog callback path, avoiding cross-integration credential leakage.
• DD params are added to both _supported_callback_params and _request_blocked_callback_params, which correctly allows team-metadata sourcing while preventing per-request injection.

Confidence Score: 5/5

The change is safe to merge — team credential routing is correctly isolated via DynamicLoggingCache, the global env-var path is untouched, and DD credentials are blocked from per-request injection.

The credential resolution, cache keying, and routing logic are all correct. The reordering of initialization in Logging.init is sound, the security boundary (blocking dd_* from request metadata) is properly enforced, and tests cover caching, isolation, and detection. The one open concern is a dead method that duplicates the inline credential detection check, but it does not affect runtime behavior.

datadog_team_handler.py — the unused _dynamic_datadog_credentials_are_passed method duplicates logic that lives inline in litellm_logging.py and could drift over time.

Important Files Changed

Filename	Overview
litellm/integrations/datadog/datadog.py	DataDogLogger.init extended with explicit dd_api_key/dd_site/dd_agent_host/dd_agent_port kwargs that fall back to env vars; _configure_dd_agent and _configure_dd_direct_api updated to accept the same kwargs.
litellm/integrations/datadog/datadog_team_handler.py	New DataDogHandler class provides per-team DataDogLogger resolution via DynamicLoggingCache; _dynamic_datadog_credentials_are_passed is defined but never called from production code.
litellm/litellm_core_utils/litellm_logging.py	Reordered Logging.init to initialize standard_callback_dynamic_params before process_dynamic_callbacks; process_dynamic_callback_list now forwards filtered dd* keys to _init_custom_logger_compatible_class for the datadog callback; datadog branch in _init_custom_logger_compatible_class routes to DataDogHandler when team credentials are present.
litellm/litellm_core_utils/initialize_dynamic_callback_params.py	Adds dd_api_key, dd_site, dd_agent_host, dd_agent_port to both _supported_callback_params and _request_blocked_callback_params, correctly allowing team-config sourcing while blocking per-request injection.
litellm/types/utils.py	Adds dd_api_key, dd_site, dd_agent_host, dd_agent_port to StandardCallbackDynamicParams TypedDict.
tests/test_litellm/integrations/datadog/test_datadog_team_handler.py	15 new unit tests covering credential kwargs, handler resolution, caching, isolation, and allow-list membership; all use mocks with no real network calls.

_{Reviews (3): Last reviewed commit: "feat(datadog): add team-scoped Datadog c..." | Re-trigger Greptile}

[greptile-apps]

Greptile Summary

This PR adds team-scoped Datadog callback support to LiteLLM, following the same pattern already established for LangFuse. DataDogLogger.__init__ now accepts per-team credentials as kwargs (falling back to env vars for the global case), and a new DataDogHandler class resolves and caches per-team logger instances via the shared DynamicLoggingCache.

• StandardCallbackDynamicParams and _supported_callback_params gain four new dd_* fields so team credentials flow through the existing callback-params pipeline.
• Logging.__init__ initialization order is fixed: standard_callback_dynamic_params is now set before process_dynamic_callbacks() runs, allowing _init_callback_list to surface team credentials to _init_custom_logger_compatible_class for per-request logger resolution.
• 15 mock-only unit tests cover credential kwargs, handler resolution, cache hit/miss, and team isolation.

Confidence Score: 4/5

The change is additive and isolated to the Datadog logging path; global Datadog behavior and all other callbacks are unchanged.

The core logic is correct and the LangFuse pattern is followed closely. The two issues worth watching are a latent dual-logger risk in _return_global_datadog_logger (unreachable from the main flow today but a footgun for future callers) and a now-redundant hasattr guard that could mislead future readers about initialization invariants. Neither affects current production behavior.

litellm/integrations/datadog/datadog_team_handler.py — specifically the _return_global_datadog_logger fallback path and its relationship to _in_memory_loggers.

Important Files Changed

Filename	Overview
litellm/integrations/datadog/datadog.py	Adds dd_api_key/dd_site/dd_agent_host/dd_agent_port kwargs to DataDogLogger.init, with env-var fallback; configures agent or direct-API path based on resolved values.
litellm/integrations/datadog/datadog_team_handler.py	New DataDogHandler class following the LangFuse pattern: resolves and caches per-team DataDogLogger instances via DynamicLoggingCache; _return_global_datadog_logger creates a logger in DynamicLoggingCache with empty credentials, parallel to _in_memory_loggers and unreachable from the main production flow.
litellm/litellm_core_utils/litellm_logging.py	Initialization order fixed so standard_callback_dynamic_params is set before process_dynamic_callbacks; _init_callback_list passes params to _init_custom_logger_compatible_class; datadog branch routes to DataDogHandler when team credentials are present.
litellm/litellm_core_utils/initialize_dynamic_callback_params.py	Adds dd_api_key, dd_site, dd_agent_host, dd_agent_port to _supported_callback_params allow-list; straightforward addition following existing pattern.
litellm/types/utils.py	Adds four Datadog dynamic params to StandardCallbackDynamicParams TypedDict; no logic changes.
tests/test_litellm/integrations/datadog/test_datadog_team_handler.py	15 new mock-only unit tests covering credential kwargs, handler resolution, caching, team isolation, and fallback; no real network calls; asyncio.create_task is patched throughout.

_{Reviews (2): Last reviewed commit: "feat(datadog): add team-scoped Datadog c..." | Re-trigger Greptile}

[veria-ai]

PR overview

All previously flagged issues have been addressed. No open security concerns remain on this pull request.

Security review

No open security issues remain on this pull request.

Fixed/addressed: 1 · PR risk: 0/10

[aanchal22]

@greptile-apps re review please