Publish and Consume Azure Event Grid Events

This skill publishes and consumes events with Azure.Messaging.EventGrid (.NET, current stable 4.28.0), covering both push delivery to topics/domains and pull delivery via namespaces. Push delivery uses EventGridPublisherClient (SendEventAsync/SendEventsAsync for either the native EventGridEvent schema or the CNCF-standard CloudEvent schema), authenticated via API key (AzureKeyCredential), Microsoft Entra ID (DefaultAzureCredential, recommended), or a time-limited SAS token built with EventGridPublisherClient.BuildSharedAccessSignature. Publishing to an Event Grid domain requires setting each event's Topic property for routing to the right domain topic. Custom serialization is supported via a JsonObjectSerializer with configurable naming policy (e.g. camelCase). Pull delivery (namespaces) uses a separate Azure.Messaging.EventGrid.Namespaces package: an EventGridSenderClient sends CloudEvents to a namespace topic, and an EventGridReceiverClient receives a batch (ReceiveAsync(maxEvents)), processes each ReceiveDetails's lock token, and explicitly acknowledges successfully processed events, releases failed ones for retry, or rejects unprocessable events to dead-letter - a three-way outcome model distinct from push delivery's fire-and-forget. Azure Functions integration is shown for both schemas via [EventGridTrigger] on an EventGridEvent or CloudEvent parameter. Parsing raw webhook payloads uses EventGridEvent.ParseMany/CloudEvent.ParseMany, with TryGetSystemEventData distinguishing built-in system events (e.g. StorageBlobCreatedEventData, ResourceWriteSuccessEventData, WebAppUpdatedEventData, ContainerRegistryImagePushedEventData, IotHubDeviceCreatedEventData) from custom event data deserialized via ToObjectFromJson<T>(). A comparison table contrasts EventGridEvent (Azure-specific, requires subject/eventType/dataVersion/data, limited extensibility) against CloudEvent (CNCF standard, requires only source/type, cross-platform interoperable, extension attributes). Error handling distinguishes RequestFailedException status codes - 401 (bad credentials), 403 (RBAC/authorization), 413 (payload over the 1MB per-event/1MB-total-batch limit) - and a failover pattern catches a publish failure against a primary client and retries against a secondary-region client.

Use this skill when building an event-driven .NET application that publishes to or consumes from Azure Event Grid - reacting to Azure resource events, publishing custom application events, or building a pull-based consumer with explicit ack/release/reject control. It is not for message-queue semantics requiring strict ordering or long-term message retention (Event Grid is a pub/sub event router, not a queue) - Azure Service Bus or Event Hubs fit those needs better - and CloudEvents is the recommended schema for new work over the Azure-specific EventGridEvent schema. Since Event Grid may redeliver events, handlers should be idempotent, and namespace events support a configurable time-to-live. CloudEvents interop with other CNCF tooling is available via the separate Microsoft.Azure.Messaging.EventGrid.CloudNativeCloudEvents package.

Input is event data (subject, type, and payload) to publish, or raw webhook/pull-delivery payloads to parse and process. Output is published event confirmations (single or batched), parsed and typed system or custom event objects, and for pull delivery, per-event acknowledge/release/reject outcomes.

Built on Azure.Messaging.EventGrid (topics/domains, push) and Azure.Messaging.EventGrid.Namespaces (pull delivery), authenticated via Azure.Identity's DefaultAzureCredential, with Azure Functions trigger bindings via Microsoft.Azure.WebJobs.Extensions.EventGrid.

dotnet add package Azure.Messaging.EventGrid

.NET developers building event-driven systems on Azure Event Grid - publishing application events, reacting to Azure resource events, or building pull-based consumers with explicit delivery-outcome control - across both push and pull delivery models.