An API that connects multiple Microsoft services, enabling data access and automation across platforms
alerts and alerts_v2 are two different alert stacks with different back-end providers and object lifecycles. The documentation explicitly calls the original alert resource “legacy” and notes that it is a separate alert type from the newer security alerts/incidents.
Key points based on the documentation:
- Legacy alerts vs new alerts
- The legacy alert resource (
/security/alerts) is the “first generation” of Microsoft Graph security alerts. - It federates alerts from specific legacy providers (for example, Azure Sentinel, Defender products) and exposes them via
/security/alerts. - The new alerts/alerts_v2 stack (documented under “alerts and incidents”) is a different resource type and is not just a path alias. Not every legacy alert has a corresponding alerts_v2 object, and vice versa.
- The legacy alerts API is deprecated and will be removed by April 2026; migration to the new alerts/incidents API is recommended.
- The legacy alert resource (
- Why the same ID does not work across
/alertsand/alerts_v2- The ID space is not guaranteed to be shared between the legacy alert resource and the new alerts_v2 resource.
- An alert returned from
/security/alerts/{id}can legitimately returnResourceNotFoundwhen queried as/security/alerts_v2/{id}because:- That alert may only exist in the legacy pipeline.
- The provider may not emit it into the new alerts_v2 schema.
- The new API may normalize or remap identifiers.
- Similarly, alerts returned from
/security/alerts_v2may or may not be available via/security/alerts.
- Expected behavior for mixed results
- The behavior described—some alerts visible only in
/alerts, some only in/alerts_v2, and some in both—is expected during the coexistence period of the two APIs. - There is no guarantee that every alert ID from one endpoint is resolvable on the other endpoint.
- The behavior described—some alerts visible only in
- Practical guidance
- For any new development or migration work, use the new alerts/incidents API (alerts_v2) as the primary source and treat
/security/alertsas legacy/compatibility only. - Do not rely on cross-resolving IDs between
/security/alertsand/security/alerts_v2. - Plan for the removal of the legacy
/security/alertsendpoint by April 2026 by updating integrations to the new security alert resource.
- For any new development or migration work, use the new alerts/incidents API (alerts_v2) as the primary source and treat
References: