Create Subscriptions for Security Alerts via GraphAPI

FlowdeSnow 0 Reputation points
2026-05-09T02:39:11.31+00:00

Hey all,

I’m trying to build near-real-time ingestion for Microsoft security data through Microsoft Graph, and I’m running into what looks like a pretty confusing gap in the docs.

What I found so far:

The Graph change notification docs still list security/alerts as a supported subscription resource.

The subscription docs still show examples for security/alerts filters.

But the Security API docs also say the legacy alerts API is deprecated and point people toward the newer alerts/incidents model.

I can’t find any documented webhook/change notification support for:

security/alerts_v2

security/incidents

So right now it looks like:

legacy security/alerts = still documented for subscriptions

security/alerts_v2 = no webhook support that I can find

security/incidents = no webhook support that I can find

I also hit inconsistent filter examples in the docs:

one place shows security/alerts?$filter=status eq 'New'

another shows security/alerts?$filter=status eq 'NewAlert'

When I tested, I got an enum/filter error, so even the example values seem inconsistent.

What I’m trying to figure out:

Has anyone successfully built production subscriptions on security/alerts recently?

Has anyone gotten webhook/change notifications working for security/incidents?

Same question for security/alerts_v2?

If not, are people just polling security/incidents and/or security/alerts_v2 as the real solution?

Has Microsoft given anyone a roadmap/ETA for incident or alerts_v2 subscriptions?

At this point I’m leaning toward:

poll security/incidents for the real incident workflow

optionally poll security/alerts_v2 for alert-level freshness

treat legacy security/alerts subscriptions as risky unless Microsoft explicitly confirms they’re still the supported path

If anyone has implemented this recently, I’d really like to know what architecture you ended up using.

Microsoft Security | Microsoft Graph
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-05-09T02:39:31.7066667+00:00

    Security change notifications via Microsoft Graph are currently documented only for the legacy security/alerts resource, not for security/alerts_v2 or security/incidents.

    From the change notifications documentation:

    • Supported security alert subscription resource paths are:
      • /security/alerts/{id} (specific alert)
      • /security/alerts/?$filter={parameters} (filtered alerts)
    • These are explicitly tied to the legacy alert resource. The same table points back to the Security API alerts section, which clearly labels this as Legacy alerts and states that the legacy alerts API is deprecated and will be removed by April 2026, recommending migration to the new alerts/incidents API.

    From the Security API overview:

    • The legacy alert resource (surfaced at security/alerts) is deprecated and will be removed by April 2026.
    • New work should target the newer alerts and incidents model (alerts_v2 and incidents), but the documentation in the provided context only shows these for GET and PATCH operations, not for change notifications.
    • The “Common use cases” section lists:
      • GET /security/alerts_v2 (List alerts)
      • PATCH /security/alerts/{id} (Update alert) but does not list any subscription or webhook support for alerts_v2 or incidents.

    On filters and examples:

    • The change notifications docs show the pattern /security/alerts/?$filter={parameters} and refer back to the Security API alerts docs for details. In the provided context, there is no authoritative list of valid enum values for status or other properties, and no clarification of New vs NewAlert. Only the general capability to filter is documented, not the exact values.

    On what is currently supported (based on the provided documentation):

    1. Legacy security/alerts
      • Still documented as a supported resource for change notifications.
      • Supports subscriptions on a specific alert or filtered alerts.
      • Marked as legacy and deprecated, with removal planned by April 2026.
    2. security/alerts_v2
      • Documented for listing and updating alerts.
      • No documented webhook/change notification support in the provided context.
    3. security/incidents
      • Mentioned as part of the new alerts/incidents model.
      • No documented webhook/change notification support in the provided context.

    Given only the provided documentation, the supported and documented patterns are:

    • For near-real-time notifications today: use change notifications on legacy security/alerts (/security/alerts/{id} or /security/alerts/?$filter=...).
    • For working with the newer model (alerts_v2 and incidents): use polling (GET) plus PATCH for updates, because no subscription support is documented.
    • Treat security/alerts subscriptions as a time-limited solution, since the API is deprecated and scheduled for removal by April 2026.

    No roadmap or ETA for subscriptions on security/alerts_v2 or security/incidents is provided in the context. The only forward-looking guidance is the deprecation notice and the recommendation to migrate to the new alerts/incidents API.

    A reasonable architecture strictly based on the documentation in the context would be:

    • Short term (while legacy is still available):
      • Use change notifications on security/alerts for near-real-time signals.
      • Correlate those legacy alerts with alerts_v2/incidents via polling if needed.
    • Long term / future-proofing:
      • Design core workflows around polling security/incidents and optionally security/alerts_v2.
      • Treat the legacy security/alerts subscription as an optimization that will need to be removed or replaced before April 2026.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.