You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/event-grid/communication-services-email-events.md
+7-5Lines changed: 7 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,18 +1,20 @@
1
1
---
2
2
title: Azure Communication Services - Email events
3
-
description: This article describes how to use Azure Communication Services as an Event Grid event source for Email Events.
3
+
description: Azure Communication Services email events integrate with Event Grid for delivery and engagement tracking. Learn about supported event types, schemas, and responses.
4
+
#customer intent: As a developer, I want to know which email events Azure Communication Services supports through Event Grid so that I can determine which events to subscribe to in my application.
4
5
ms.topic: concept-article
5
-
ms.date: 01/21/2025
6
+
ms.date: 03/27/2026
6
7
author: anmolbohra97
7
8
ms.author: anmolbohra
9
+
ms.reviewer: spelluru
8
10
# Customer intent: I want to learn about what email events from Azure Communication Servics are supported through Azure Event Grid.
9
11
---
10
12
11
13
# Azure Communication Services - Email events
12
14
13
15
This article provides the properties and schema for communication services email events. For an introduction to event schemas, see [Azure Event Grid event schema](event-schema.md).
14
16
15
-
## Events types
17
+
## Event types
16
18
17
19
Azure Communication Services emits the following telephony and Short Message Service (SMS) event types:
18
20
@@ -25,7 +27,7 @@ Azure Communication Services emits the following telephony and Short Message Ser
25
27
26
28
When an event is triggered, the Event Grid service sends data about that event to subscribing endpoints.
27
29
28
-
This section contains an example of what that data would look like for each event.
30
+
This section contains an example of what that data looks like for each event.
@@ -54,7 +56,7 @@ This section contains an example of what that data would look like for each even
54
56
> [!NOTE]
55
57
> Possible values for `Status` are:
56
58
> -`Delivered`: The message was successfully handed over to the intended destination (recipient Mail Transfer Agent).
57
-
> -`Suppressed`: The recipient email had hard bounced previously, and all subsequent emails to this recipient are being temporarily suppressed as a result.
59
+
> -`Suppressed`: The recipient email previously hard bounced, so all subsequent emails to this recipient are temporarily suppressed.
58
60
> -`Bounced`: The email hard bounced, which might happen because the email address doesn't exist or the domain is invalid.
59
61
> -`Quarantined`: The message was quarantined (as spam, bulk mail, or phishing).
60
62
> -`FilteredSpam`: The message was identified as spam, and was rejected or blocked (not quarantined).
description: This article describes how to work around push delivery's limitation to deliver events using private link service.
2
+
title: Secure Event Delivery with Private Links
3
+
description: Private link event delivery in Azure Event Grid supports pull delivery but not push delivery. Learn how to configure private endpoints and explore secure alternatives.
4
+
#customer intent: As a solutions architect, I want to know if Azure Event Grid push delivery supports private link so that I can determine the right event delivery approach for my secure network environment.
4
5
ms.topic: how-to
5
-
ms.date: 12/16/2024
6
+
ms.date: 03/27/2026
7
+
author: spelluru
8
+
ms.author: spelluru
9
+
ms.reviewer: spelluru
6
10
# Customer intent: I would like to know if delivering events using private link service is supported in the Push model.
7
-
ms.custom:
8
-
- build-2025
9
11
---
10
12
11
13
# Deliver events securely over a private link
12
14
This article describes how Azure Event Grid supports delivering events over a private link.
13
15
14
16
## Pull delivery
15
-
**Pull** delivery supports consuming events using private links. Pull delivery is a feature of Event Grid namespaces. Once you add a private endpoint connection to a namespace, your consumer application can connect to Event Grid on a private endpoint to receive events. For more information, see [configure private endpoints for namespaces](configure-private-endpoints-pull.md) and [pull delivery overview](pull-delivery-overview.md).
17
+
**Pull** delivery supports consuming events by using private links. Pull delivery is a feature of Event Grid namespaces. When you add a private endpoint connection to a namespace, your consumer application can connect to Event Grid on a private endpoint to receive events. For more information, see [configure private endpoints for namespaces](configure-private-endpoints-pull.md) and [pull delivery overview](pull-delivery-overview.md).
16
18
17
19
## Push delivery
18
-
With **push** delivery isn't possible to deliver events using [private endpoints](../private-link/private-endpoint-overview.md). That is, with push delivery, either in Event Grid basic or Event Grid namespaces, your application can't receive events over private IP space. However, there's a secure alternative using managed identities with public endpoints. Use the link in the next section to navigate to the article that shows how to use managed identities to deliver events.
20
+
With **push** delivery, you can't deliver events by using [private endpoints](../private-link/private-endpoint-overview.md). That is, with push delivery, either in Event Grid basic or Event Grid namespaces, your application can't receive events over private IP space. However, there's a secure alternative that uses managed identities with public endpoints. Use the link in the next section to go to the article that shows how to use managed identities to deliver events.
19
21
20
22
## Related content
21
-
For more information about delivering events using a managed identity, see [Deliver events securely using managed identities](deliver-events-using-managed-identity.md).
23
+
For more information about delivering events by using a managed identity, see [Deliver events securely using managed identities](deliver-events-using-managed-identity.md).
Copy file name to clipboardExpand all lines: articles/event-grid/end-point-validation-event-grid-events-schema.md
+21-18Lines changed: 21 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,17 +1,20 @@
1
1
---
2
-
title: Endpoint validation with Event Grid event schema
2
+
title: Validate Webhook Endpoints with Event Grid Schema
3
3
description: This article describes WebHook event delivery and endpoint validation when using webhooks and the Event Grid event schema.
4
4
ms.topic: concept-article
5
-
ms.date: 09/25/2024
5
+
ms.date: 03/27/2026
6
+
author: spelluru
7
+
ms.author: spelluru
8
+
ms.reviewer: spelluru
6
9
ms.custom: FY25Q1-Linter
7
10
#customer intent: As a developer, I want to know how to validate a Webhook endpoint using the Event Grid event schema.
8
11
---
9
12
10
13
11
14
# Endpoint validation with Event Grid event schema
12
-
Webhooks are one of the many ways to receive events from Azure Event Grid. When a new event is ready, Event Grid service POSTs an HTTP request to the configured endpoint with the event information in the request body.
15
+
Webhooks are one of the many ways to receive events from Azure Event Grid. When a new event is ready, the Event Grid service POSTs an HTTP request to the configured endpoint with the event information in the request body.
13
16
14
-
Like many other services that support webhooks, Event Grid requires you to prove ownership of your Webhook endpoint before it starts delivering events to that endpoint. This requirement prevents a malicious user from flooding your endpoint with events.
17
+
Like many other services that support webhooks, Event Grid requires you to prove ownership of your webhook endpoint before it starts delivering events to that endpoint. This requirement prevents a malicious user from flooding your endpoint with events.
15
18
16
19
## Endpoint validation with Event Grid events
17
20
When you use any of the following three Azure services, the Azure infrastructure automatically handles this validation:
@@ -37,16 +40,16 @@ If you're using any other type of endpoint, such as an HTTP trigger based Azure
37
40
38
41
### Validation details
39
42
40
-
-At the time of event subscription creation/update, Event Grid posts a subscription validation event to the target endpoint.
41
-
- The event contains a header value `aeg-event-type: SubscriptionValidation`.
42
-
- The event body has the same schema as other Event Grid events.
43
+
-When you create or update an event subscription, Event Grid sends a subscription validation event to the target endpoint.
44
+
- The event includes a header with the value `aeg-event-type: SubscriptionValidation`.
45
+
- The event body follows the same schema as other Event Grid events.
43
46
- The `eventType` property of the event is `Microsoft.EventGrid.SubscriptionValidationEvent`.
44
-
- The `data` property of the event includes a `validationCode` property with a randomly generated string. For example, `validationCode: acb13…`.
47
+
- The `data` property of the event contains a `validationCode` property with a randomly generated string. For example, `validationCode: acb13…`.
45
48
- The event data also includes a `validationUrl` property with a URL for manually validating the subscription.
46
49
- The array contains only the validation event. Other events are sent in a separate request after you echo back the validation code.
47
-
- The Event Grid data plane SDKs have classes corresponding to the subscription validation event data and subscription validation response.
50
+
- The Event Grid data plane SDKs include classes that correspond to the subscription validation event data and subscription validation response.
48
51
49
-
An example SubscriptionValidationEvent is shown in the following example:
52
+
The following example shows a `SubscriptionValidationEvent`:
50
53
51
54
```json
52
55
[
@@ -74,21 +77,21 @@ To prove endpoint ownership, echo back the validation code in the `validationRes
74
77
}
75
78
```
76
79
77
-
And, follow one of these steps:
80
+
Follow one of these steps:
78
81
79
-
- You must return an **HTTP 200 OK** response status code. **HTTP 202 Accepted** isn't recognized as a valid Event Grid subscription validation response. The HTTP request must complete within 30 seconds. If the operation doesn't finish within 30 seconds, then the operation will be canceled and it's reattempted after 5 seconds. If all the attempts fail, then it's treated as validation handshake error.
82
+
- You must return an **HTTP 200 OK** response status code. **HTTP 202 Accepted** isn't recognized as a valid Event Grid subscription validation response. The HTTP request must complete within 30 seconds. If the operation doesn't finish within 30 seconds, the operation is canceled and reattempted after 5 seconds. If all the attempts fail, the operation is treated as a validation handshake error.
80
83
81
-
The fact that your application is prepared to handle and return the validation code indicates that you created the event subscription and expected to receive the event. Imagine the scenario that there's no handshake validation supported and a hacker gets to know your application URL. The hacker can create a topic and an event subscription with your application's URL, and start conducting a DoS attack to your application by sending a lot of events. The handshake validation prevents that to happen.
84
+
The fact that your application is prepared to handle and return the validation code indicates that you created the event subscription and expected to receive the event. Imagine the scenario where there's no handshake validation supported and a bad actor gets to know your application URL. The bad actor can create a topic and an event subscription with your application's URL, and start conducting a DoS attack on your application by sending many events. The handshake validation prevents that to happen.
82
85
83
-
Imagine that you already have the validation implemented in your app because you created your own event subscriptions. Even if a hacker creates an event subscription with your app URL, your correct implementation of the validation request event checks for the `aeg-subscription-name` header in the request to ascertain that it's an event subscription that you recognize.
86
+
Imagine that you already have the validation implemented in your app because you created your own event subscriptions. Even if a bad actor creates an event subscription with your app URL, your correct implementation of the validation request event checks for the `aeg-subscription-name` header in the request to ascertain that it's an event subscription that you recognize.
84
87
85
-
Even after that correct handshake implementation, a hacker can flood your app (it already validated the event subscription) by replicating a request that seems to be coming from Event Grid. To prevent that, you must secure your webhook with Microsoft Entra authentication. For more information, see [Deliver events to Microsoft Entra protected endpoints](secure-webhook-delivery.md).
86
-
- Or, you can manually validate the subscription by sending a GET request to the validation URL. The event subscription stays in a pending state until validated. The validation Url uses **port 553**. If your firewall rules block port 553, you need to update rules for a successful manual handshake.
88
+
Even after that correct handshake implementation, a bad actor can flood your app (it already validated the event subscription) by replicating a request that seems to be coming from Event Grid. To prevent that, you must secure your webhook with Microsoft Entra authentication. For more information, see [Deliver events to Microsoft Entra protected endpoints](secure-webhook-delivery.md).
89
+
- Or, you can manually validate the subscription by sending a GET request to the validation URL. The event subscription stays in a pending state until validated. The validation URL uses **port 553**. If your firewall rules block port 553, you need to update rules for a successful manual handshake.
87
90
88
-
In your validation of the subscription validation event, if you identify that it isn't an event subscription for which you're expecting events, you wouldn't return a 200 response or no response at all. Hence, the validation fails.
91
+
In your validation of the subscription validation event, if you identify that it isn't an event subscription for which you're expecting events, don't return a 200 response or return no response at all. Hence, the validation fails.
89
92
90
93
For an example of handling the subscription validation handshake, see a [C# sample](https://github.com/Azure-Samples/event-grid-dotnet-publish-consume-events/blob/master/EventGridConsumer/EventGridConsumer/Function1.cs).
91
94
92
95
93
96
## Related content
94
-
See the following article to learn how to troubleshoot event subscription validations:[Troubleshoot event subscription validations](troubleshoot-subscription-validation.md).
97
+
To learn how to troubleshoot event subscription validations, see[Troubleshoot event subscription validations](troubleshoot-subscription-validation.md).
0 commit comments