feat(seer-infra-telemetry): Add DatadogIdentityProvider for OAuth2 by srest2021 · Pull Request #117035 · getsentry/sentry

srest2021 · 2026-06-05T22:03:46Z

Depends on #117026

Adds DatadogIdentityProvider, an OAuth2 identity provider for Datadog using PKCE and DCR.

linear-code · 2026-06-05T22:03:50Z

…copes Replace GET /api/v2/current_user with MCP datadog://mcp/whoami resource for user identity resolution. Add resource-specific OAuth scopes alongside mcp_read for tool access. Update tests to match new whoami response format. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

…e sure we fail loudly if not present

cursor

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 1b9dd17. Configure here.}

cursor · 2026-06-11T17:23:28Z

+        json={"jsonrpc": "2.0", "id": 1, "method": "initialize", "params": {}},
+    )
+    init_resp.raise_for_status()
+    headers["Mcp-Session-Id"] = init_resp.headers["mcp-session-id"]


Missing MCP session header crash

Medium Severity

In get_user_info, the MCP initialize response uses subscript access on init_resp.headers["mcp-session-id"]. If the server returns HTTP 200 without that header (optional per discussion), linking raises an uncaught KeyError instead of a controlled identity error like the whoami body parsing below.

^{Reviewed by Cursor Bugbot for commit 1b9dd17. Configure here.}

…API endpoints (#117478) Resolves https://linear.app/getsentry/issue/CW-1499/monitoring-provider-connection-api-endpoints. Adds API endpoints for listing, connecting, and disconnecting monitoring providers (currently Datadog & GCP). These endpoints wrap the existing identity pipeline to let users initiate the per-user OAuth flow for connecting their monitoring provider accounts to Sentry. The identity providers for Datadog & GCP were previously implemented in #117035 & #117279, respectively. All endpoints are gated behind the `organizations:seer-infra-telemetry` feature flag, which is enabled only internally in the Sentry org for now. Note that monitoring provider connections are per-user (each user links their own account via OAuth), not per-organization. There is some provider-specific config baked into this implementation: Datadog requires a `site` parameter in the POST body (e.g. `datadoghq.com`) for site resolution, while GCP needs no extra config. For Datadog, the `IdentityProvider` is not created in the POST endpoint; it is auto-created by `IdentityPipeline.finish_pipeline()` using the Datadog org UUID from the MCP whoami response as the external ID (see #117491 & #117705). For GCP, the `IdentityProvider` is created upfront by the endpoint. `GET /api/0/organizations/{org}/monitoring-providers/` lists the available providers and the current user's connection status. This will be used to inform the monitoring provider settings UI tracked in https://linear.app/getsentry/issue/CW-1500/monitoring-providers-settings-page. `POST /api/0/organizations/{org}/monitoring-providers/{provider}/` represents a request to connect a given monitoring provider for a given user. It initiates the OAuth flow and returns a redirect URL to the provider's authorize page, based on the identity pipeline for that provider. `DELETE /api/0/organizations/{org}/monitoring-providers/{provider}/` represents a request to disconnect/delete a given monitoring provider for a given user. It deletes the current user's linked identity for that provider, if one exists. **Note on support for a single user connecting multiple Datadog orgs:** - For v0, we're mainly considering the case where a user has a single Datadog org connected, but in the future we will support multiple - The GET endpoint currently collapses to one entry per provider type (shows `connected: true` if _any_ exist - The POST endpoint currently allows multiple connections to be created - The DELETE endpoint currently deletes all identities for the provider (`idp__type=provider_key`) --------- Co-authored-by: getsantry[bot] <66042841+getsantry[bot]@users.noreply.github.com>

…API endpoints (#117854) Recreated after reverting #117478. Depends on #117851. Resolves https://linear.app/getsentry/issue/CW-1499/monitoring-provider-connection-api-endpoints. Adds API endpoints for listing, connecting, and disconnecting monitoring providers (currently Datadog & GCP). These endpoints wrap the existing identity pipeline to let users initiate the per-user OAuth flow for connecting their monitoring provider accounts to Sentry. The identity providers for Datadog & GCP were previously implemented in #117035 & #117279, respectively. All endpoints are gated behind the `organizations:seer-infra-telemetry` feature flag, which is enabled only internally in the Sentry org for now. Note that monitoring provider connections are per-user (each user links their own account via OAuth), not per-organization. There is some provider-specific config baked into this implementation: Datadog requires a `site` parameter in the POST body (e.g. `datadoghq.com`) for site resolution, while GCP needs no extra config. For Datadog, the `IdentityProvider` is not created in the POST endpoint; it is auto-created by `IdentityPipeline.finish_pipeline()` using the Datadog org UUID from the MCP whoami response as the external ID (see #117491 & #117705). For GCP, the `IdentityProvider` is created upfront by the endpoint. `GET /api/0/organizations/{org}/monitoring-providers/` lists the available providers and the current user's connection status. This will be used to inform the monitoring provider settings UI tracked in https://linear.app/getsentry/issue/CW-1500/monitoring-providers-settings-page. `POST /api/0/organizations/{org}/monitoring-providers/{provider}/` represents a request to connect a given monitoring provider for a given user. It initiates the OAuth flow and returns a redirect URL to the provider's authorize page, based on the identity pipeline for that provider. `DELETE /api/0/organizations/{org}/monitoring-providers/{provider}/` represents a request to disconnect/delete a given monitoring provider for a given user. It deletes the current user's linked identity for that provider, if one exists. **Note on support for a single user connecting multiple Datadog orgs:** - For v0, we're mainly considering the case where a user has a single Datadog org connected, but in the future we will support multiple - The GET endpoint currently collapses to one entry per provider type (shows `connected: true` if _any_ exist - The POST endpoint currently allows multiple connections to be created - The DELETE endpoint currently deletes all identities for the provider (`idp__type=provider_key`) --------- Co-authored-by: getsantry[bot] <66042841+getsantry[bot]@users.noreply.github.com>

…API endpoints (#117478) Resolves https://linear.app/getsentry/issue/CW-1499/monitoring-provider-connection-api-endpoints. Adds API endpoints for listing, connecting, and disconnecting monitoring providers (currently Datadog & GCP). These endpoints wrap the existing identity pipeline to let users initiate the per-user OAuth flow for connecting their monitoring provider accounts to Sentry. The identity providers for Datadog & GCP were previously implemented in #117035 & #117279, respectively. All endpoints are gated behind the `organizations:seer-infra-telemetry` feature flag, which is enabled only internally in the Sentry org for now. Note that monitoring provider connections are per-user (each user links their own account via OAuth), not per-organization. There is some provider-specific config baked into this implementation: Datadog requires a `site` parameter in the POST body (e.g. `datadoghq.com`) for site resolution, while GCP needs no extra config. For Datadog, the `IdentityProvider` is not created in the POST endpoint; it is auto-created by `IdentityPipeline.finish_pipeline()` using the Datadog org UUID from the MCP whoami response as the external ID (see #117491 & #117705). For GCP, the `IdentityProvider` is created upfront by the endpoint. `GET /api/0/organizations/{org}/monitoring-providers/` lists the available providers and the current user's connection status. This will be used to inform the monitoring provider settings UI tracked in https://linear.app/getsentry/issue/CW-1500/monitoring-providers-settings-page. `POST /api/0/organizations/{org}/monitoring-providers/{provider}/` represents a request to connect a given monitoring provider for a given user. It initiates the OAuth flow and returns a redirect URL to the provider's authorize page, based on the identity pipeline for that provider. `DELETE /api/0/organizations/{org}/monitoring-providers/{provider}/` represents a request to disconnect/delete a given monitoring provider for a given user. It deletes the current user's linked identity for that provider, if one exists. **Note on support for a single user connecting multiple Datadog orgs:** - For v0, we're mainly considering the case where a user has a single Datadog org connected, but in the future we will support multiple - The GET endpoint currently collapses to one entry per provider type (shows `connected: true` if _any_ exist - The POST endpoint currently allows multiple connections to be created - The DELETE endpoint currently deletes all identities for the provider (`idp__type=provider_key`) --------- Co-authored-by: getsantry[bot] <66042841+getsantry[bot]@users.noreply.github.com>

…API endpoints (#117854) Recreated after reverting #117478. Depends on #117851. Resolves https://linear.app/getsentry/issue/CW-1499/monitoring-provider-connection-api-endpoints. Adds API endpoints for listing, connecting, and disconnecting monitoring providers (currently Datadog & GCP). These endpoints wrap the existing identity pipeline to let users initiate the per-user OAuth flow for connecting their monitoring provider accounts to Sentry. The identity providers for Datadog & GCP were previously implemented in #117035 & #117279, respectively. All endpoints are gated behind the `organizations:seer-infra-telemetry` feature flag, which is enabled only internally in the Sentry org for now. Note that monitoring provider connections are per-user (each user links their own account via OAuth), not per-organization. There is some provider-specific config baked into this implementation: Datadog requires a `site` parameter in the POST body (e.g. `datadoghq.com`) for site resolution, while GCP needs no extra config. For Datadog, the `IdentityProvider` is not created in the POST endpoint; it is auto-created by `IdentityPipeline.finish_pipeline()` using the Datadog org UUID from the MCP whoami response as the external ID (see #117491 & #117705). For GCP, the `IdentityProvider` is created upfront by the endpoint. `GET /api/0/organizations/{org}/monitoring-providers/` lists the available providers and the current user's connection status. This will be used to inform the monitoring provider settings UI tracked in https://linear.app/getsentry/issue/CW-1500/monitoring-providers-settings-page. `POST /api/0/organizations/{org}/monitoring-providers/{provider}/` represents a request to connect a given monitoring provider for a given user. It initiates the OAuth flow and returns a redirect URL to the provider's authorize page, based on the identity pipeline for that provider. `DELETE /api/0/organizations/{org}/monitoring-providers/{provider}/` represents a request to disconnect/delete a given monitoring provider for a given user. It deletes the current user's linked identity for that provider, if one exists. **Note on support for a single user connecting multiple Datadog orgs:** - For v0, we're mainly considering the case where a user has a single Datadog org connected, but in the future we will support multiple - The GET endpoint currently collapses to one entry per provider type (shows `connected: true` if _any_ exist - The POST endpoint currently allows multiple connections to be created - The DELETE endpoint currently deletes all identities for the provider (`idp__type=provider_key`) --------- Co-authored-by: getsantry[bot] <66042841+getsantry[bot]@users.noreply.github.com>

…API endpoints (#117478) Resolves https://linear.app/getsentry/issue/CW-1499/monitoring-provider-connection-api-endpoints. Adds API endpoints for listing, connecting, and disconnecting monitoring providers (currently Datadog & GCP). These endpoints wrap the existing identity pipeline to let users initiate the per-user OAuth flow for connecting their monitoring provider accounts to Sentry. The identity providers for Datadog & GCP were previously implemented in #117035 & #117279, respectively. All endpoints are gated behind the `organizations:seer-infra-telemetry` feature flag, which is enabled only internally in the Sentry org for now. Note that monitoring provider connections are per-user (each user links their own account via OAuth), not per-organization. There is some provider-specific config baked into this implementation: Datadog requires a `site` parameter in the POST body (e.g. `datadoghq.com`) for site resolution, while GCP needs no extra config. For Datadog, the `IdentityProvider` is not created in the POST endpoint; it is auto-created by `IdentityPipeline.finish_pipeline()` using the Datadog org UUID from the MCP whoami response as the external ID (see #117491 & #117705). For GCP, the `IdentityProvider` is created upfront by the endpoint. `GET /api/0/organizations/{org}/monitoring-providers/` lists the available providers and the current user's connection status. This will be used to inform the monitoring provider settings UI tracked in https://linear.app/getsentry/issue/CW-1500/monitoring-providers-settings-page. `POST /api/0/organizations/{org}/monitoring-providers/{provider}/` represents a request to connect a given monitoring provider for a given user. It initiates the OAuth flow and returns a redirect URL to the provider's authorize page, based on the identity pipeline for that provider. `DELETE /api/0/organizations/{org}/monitoring-providers/{provider}/` represents a request to disconnect/delete a given monitoring provider for a given user. It deletes the current user's linked identity for that provider, if one exists. **Note on support for a single user connecting multiple Datadog orgs:** - For v0, we're mainly considering the case where a user has a single Datadog org connected, but in the future we will support multiple - The GET endpoint currently collapses to one entry per provider type (shows `connected: true` if _any_ exist - The POST endpoint currently allows multiple connections to be created - The DELETE endpoint currently deletes all identities for the provider (`idp__type=provider_key`) --------- Co-authored-by: getsantry[bot] <66042841+getsantry[bot]@users.noreply.github.com>

…API endpoints (#117854) Recreated after reverting #117478. Depends on #117851. Resolves https://linear.app/getsentry/issue/CW-1499/monitoring-provider-connection-api-endpoints. Adds API endpoints for listing, connecting, and disconnecting monitoring providers (currently Datadog & GCP). These endpoints wrap the existing identity pipeline to let users initiate the per-user OAuth flow for connecting their monitoring provider accounts to Sentry. The identity providers for Datadog & GCP were previously implemented in #117035 & #117279, respectively. All endpoints are gated behind the `organizations:seer-infra-telemetry` feature flag, which is enabled only internally in the Sentry org for now. Note that monitoring provider connections are per-user (each user links their own account via OAuth), not per-organization. There is some provider-specific config baked into this implementation: Datadog requires a `site` parameter in the POST body (e.g. `datadoghq.com`) for site resolution, while GCP needs no extra config. For Datadog, the `IdentityProvider` is not created in the POST endpoint; it is auto-created by `IdentityPipeline.finish_pipeline()` using the Datadog org UUID from the MCP whoami response as the external ID (see #117491 & #117705). For GCP, the `IdentityProvider` is created upfront by the endpoint. `GET /api/0/organizations/{org}/monitoring-providers/` lists the available providers and the current user's connection status. This will be used to inform the monitoring provider settings UI tracked in https://linear.app/getsentry/issue/CW-1500/monitoring-providers-settings-page. `POST /api/0/organizations/{org}/monitoring-providers/{provider}/` represents a request to connect a given monitoring provider for a given user. It initiates the OAuth flow and returns a redirect URL to the provider's authorize page, based on the identity pipeline for that provider. `DELETE /api/0/organizations/{org}/monitoring-providers/{provider}/` represents a request to disconnect/delete a given monitoring provider for a given user. It deletes the current user's linked identity for that provider, if one exists. **Note on support for a single user connecting multiple Datadog orgs:** - For v0, we're mainly considering the case where a user has a single Datadog org connected, but in the future we will support multiple - The GET endpoint currently collapses to one entry per provider type (shows `connected: true` if _any_ exist - The POST endpoint currently allows multiple connections to be created - The DELETE endpoint currently deletes all identities for the provider (`idp__type=provider_key`) --------- Co-authored-by: getsantry[bot] <66042841+getsantry[bot]@users.noreply.github.com>

srest2021 added 9 commits June 4, 2026 16:19

add PkceOAuth2ApiStep

65d77ad

Merge branch 'master' into srest2021/CW-1467

1f3dd80

move to login/callback view

7beaedc

assume oauth client registration

66f343f

minimize diff

2d6c49a

minimize diff

825dfca

fix tests and add keyerror error handling:

1fc270b

check if code verifier already bound to pipeline state

cc96fab

add datadog identity provider

a52df7b

github-actions Bot added the Scope: Backend Automatically applied to PRs that change backend components label Jun 5, 2026

srest2021 changed the title ~~add datadog identity provider~~ feat(identity): Add Datadog identity provider (OAuth2 + PKCE) Jun 5, 2026

srest2021 added 18 commits June 5, 2026 15:11

fix typing

e4a4785

cleaning up

e9a2c43

add dcr

964e811

move to provider.py

8eb6577

minimize diff

5d890ed

typing

6d675ff

initial merge (contains conflicts)

73244e9

wip

72eb4a2

put comment back in

d6e58b9

client id and secret; add dcr view

0ce5e5c

add comment back in

1c217b9

merge conflicts

2d3c7d9

fix error handling

52b0e36

update login view tests

fa497bd

integration test for all 3 views

34a679c

dcr view test

60c45b5

cleaning up

cab1c77

cleaning up

c2c4308

sentry Bot reviewed Jun 10, 2026

View reviewed changes

Comment thread src/sentry/identity/datadog/provider.py

srest2021 changed the title ~~feat(seer-infra-telemetry): Add Datadog identity provider for OAuth2~~ feat(seer-infra-telemetry): Add DatadogIdentityProvider for OAuth2 Jun 10, 2026

shashjar approved these changes Jun 10, 2026

View reviewed changes

Comment thread src/sentry/identity/datadog/provider.py Outdated

Comment thread tests/sentry/identity/datadog/test_provider.py Outdated

Comment thread tests/sentry/identity/datadog/test_provider.py Outdated

wedamija approved these changes Jun 10, 2026

View reviewed changes

sentry Bot reviewed Jun 10, 2026

View reviewed changes

Comment thread src/sentry/identity/datadog/provider.py Outdated

srest2021 mentioned this pull request Jun 10, 2026

feat(seer-infra-telemetry): Bypass DCR if user is already linked to an Identity with existing client id and secret #117358

Merged

cursor Bot reviewed Jun 10, 2026

View reviewed changes

Comment thread src/sentry/identity/datadog/provider.py Outdated

sentry Bot reviewed Jun 10, 2026

View reviewed changes

Comment thread src/sentry/identity/datadog/provider.py

srest2021 force-pushed the srest2021/CW-1469 branch from 6fe33f1 to b4d8533 Compare June 10, 2026 23:48

add some error handling for malformed responses; more test coverage

b909893

sentry Bot reviewed Jun 11, 2026

View reviewed changes

Comment thread src/sentry/identity/datadog/provider.py

resolve merge conflicts

41c89ad

vercel Bot deployed to Preview June 11, 2026 17:16 View deployment

sentry Bot reviewed Jun 11, 2026

View reviewed changes

Comment thread src/sentry/identity/datadog/provider.py Outdated

direct key access on client id and secret when building identity--mak…

1b9dd17

…e sure we fail loudly if not present

cursor Bot reviewed Jun 11, 2026

View reviewed changes

sentry Bot reviewed Jun 11, 2026

View reviewed changes

Comment thread tests/sentry/identity/datadog/test_provider.py

raise identitynotvalid if no dcr credentials; fix tests

4cdd631

srest2021 merged commit 092af44 into master Jun 11, 2026
85 checks passed

srest2021 deleted the srest2021/CW-1469 branch June 11, 2026 18:21

shashjar mentioned this pull request Jun 11, 2026

feat(seer-infra-telemetry): Implement monitoring provider connection API endpoints #117478

Merged

sentry-release-bot Bot mentioned this pull request Jun 15, 2026

publish: getsentry/sentry@26.6.0 getsentry/publish#8571

Closed

3 tasks

shashjar mentioned this pull request Jun 16, 2026

feat(seer-infra-telemetry): Implement monitoring provider connection API endpoints #117854

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat(seer-infra-telemetry): Add DatadogIdentityProvider for OAuth2#117035

feat(seer-infra-telemetry): Add DatadogIdentityProvider for OAuth2#117035
srest2021 merged 58 commits into
masterfrom
srest2021/CW-1469

srest2021 commented Jun 5, 2026 •

edited

Loading

Uh oh!

linear-code Bot commented Jun 5, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cursor Bot left a comment

Uh oh!

cursor Bot Jun 11, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

srest2021 commented Jun 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

linear-code Bot commented Jun 5, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

cursor Bot Jun 11, 2026

Choose a reason for hiding this comment

Missing MCP session header crash

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

srest2021 commented Jun 5, 2026 •

edited

Loading