HTTP Request vs. Azure Event Grid Notification Type: Publishing to Event Grid Topics in WOODY.IO

Overview

WOODY.IO can notify an Azure Event Grid Custom Topic in two ways:

•     HTTP Request notification type: a generic notification that sends a raw HTTP call to any URL you configure.
•     Azure Event Grid notification type: a dedicated notification built on Microsoft's official @azure/eventgrid SDK, purpose-built for publishing to Event Grid Topics and Domains.

Both can technically get an event onto an Event Grid Topic. The difference that matters in practice is authentication: specifically, what happens when your organisation wants to authenticate with a Managed Identity instead of a long-lived key.

How each type authenticates

HTTP Request notification type

The HTTP Request notification has four configuration fields: Url, Method, Headers, and Body. There is no built-in authentication logic: if the target endpoint requires a credential, you supply it yourself as a static header value (e.g. aeg-sas-key: <key> or Authorization: Bearer <token>).

This works fine for Event Grid's Access Key or SAS Token auth, because those are long-lived static secrets: you paste the value in once and it keeps working until you rotate it.

It does not work well for Azure AD / Entra ID authentication (which is what Managed Identity uses), for one core reason:

Azure AD access tokens are short-lived: typically valid for around 60-90 minutes. A Bearer token pasted into a static header will expire, and every publish attempt after that will fail with a 401 Unauthorized until someone manually regenerates and re-pastes a fresh token.

The HTTP Request notification type has no mechanism to request a token on your behalf, and no mechanism to refresh one before it expires. To authenticate with a Managed Identity through this notification type, you would need to run a separate process to fetch a token from Azure AD and keep the notification's header field updated, which isn't practical for an unattended, scheduled system like WOODY.IO.

Net effect: teams using the HTTP Request notification type are effectively pushed toward Access Key or SAS Token auth, even when their organisation's security policy prefers (or mandates) Managed Identity / Entra ID authentication over static keys.

Azure Event Grid notification type

The Azure Event Grid notification type sends events through Microsoft's own SDK rather than a hand-built HTTP call. Under the hood it still communicates over HTTPS, but token handling is delegated entirely to the SDK's credential objects. 

It offers four auth modes:

Choosing Service Principal is what lets you authenticate with a Managed Identity: no Bearer token to fetch, store, or refresh, and no secret sitting in a header field at all. The SDK requests a fresh token immediately before each publish.

Why this Matters?

Microsoft's own guidance for Event Grid recommends Entra ID (Managed Identity / Service Principal) authentication over Access Key or SAS Token where possible, since it avoids storing static secrets and benefits from features like Conditional Access. The HTTP Request notification type structurally cannot deliver on that recommendation for unattended publishing: it can only really support the key-based auth methods reliably. The Azure Event Grid notification type removes that constraint entirely.

Recommendation

If your team is being asked to configure a Notification that uses Managed Identity as Auth type, that's a sign the notification should be switched from HTTP Request to Azure Event Grid with the Service Principal auth option: the token handling problem goes away entirely.

If you have any further questions, please feel free to Contact Us.