Skip to content

Receive delivery feedback webhooks

This guide will explain the basics of receiving delivery & bounce status updates via webhooks from Marigold Engage Delivery Cloud.

How to set up webhooks:

  1. Subscribe to delivery events
  2. Receive delivery events

Webhook concept

A webhook is a way to receive update events being pushed instead of polling continuously for updates.

webhook

A webhook (also called a web callback or HTTP push API) is a method to provide external applications with real-time information about data changes in a platform. A webhook delivers data to the external applications at the moment that there is a change, resulting in data being pushed immediately. Unlike REST APIs where the external application would need to poll the API at a regular interval in order to get the changed data. This makes webhooks much more efficient for both provider and consumer.

The webhook engine will do an HTTP POST request to an endpoint at the customer system, respecting retry and exponential backoff policies. The webhooks will try to resend the webhook data if the request towards the customer system fails, using a retry schedule and retry policy.

Duplicates

The webhook engine will attempt to remove events from the retry queue on a best effort basis but duplicates may still be received, so it is advised that you check the webhooks for duplicates.

Retry policy

  • Maximum number of attempts – The Webhook engine will try to deliver the event maximum 5 times, respecting exponential increased delayed intervals.
  • Event time-to-live (TTL) – The webhook engine will try to deliver the message within a time-range of 24h, messages older than 24h are considered outdated and will be removed

Retry schedule

When the Webhook engine was unable to deliver the event, the Webhook engine decides whether it should retry the delivery or drop the event based on the type of the error. When one of the errors occurs, the Webhook engine will retry at a delayed interval.

  • Error codes that trigger a retry: 429 Too Many Requests, 5xx responses
  • Error codes that skip a retry: 400 Bad Request, 413 Request Entity Too Large, 403 Forbidden, 404 Not Found, 401 Unauthorized

CloudEvents format

All Marigold Engage Webhook events are delivered using the CloudEvents format.

CloudEvents

CloudEvents
CloudEvents is an open-source specification that describes event data in a common way.

1. Subscribe to delivery events

The concept of webhook allows subscribing to a range of events of various types, instead of polling for updates. A webhook will push the event data to an external application using an HTTP request.

So to subscribe to delivery events, the following information is needed:

  1. A webhook URL to receive events from EDC. This is an application on your end that is capable of receiving the pushed events.
  2. Choose the type of events you want the application to notify you about.

See documentation on managing webhook subscriptions in the webhook subscriptions developer documentation.

It is possible to subscribe to multiple event types or specific event types.

The most notable event types are:

  • com.sdc.deliveries.email.sent: An event that is triggered when the email message is sent towards the ISP and EDC has gotten an success ISP response back.
  • com.sdc.deliveries.email.failed: An event that is triggered when the email message is sent towards the ISP and EDC has gotten an undeliverable ISP response back.

2. Receive delivery events

In the above steps, we explained how to manage webhook subscriptions. Now, we will show how to receive the delivery events.

We want to receive the delivery events, each time an email messages was sent to the ISP.

By using the Marigold Engage Delivery Cloud API or via Marigold Engage to send messages, we can trigger the delivery events. In the "send email messages" guide, we explain more in detail how to use to send messages via the API.

Each time the "/messages/send" API is called, Marigold Engage will send an HTTP POST request to the webhook endpoint.

POST /email/v1/messages/send

will result in a delivery event being pushed to the webhook endpoint:

POST https://yourcompany.abc/endpoint

with a JSON request body that contains the following fields:

{
  "id": "1516952e520547049b8897b24e44553e",
  "tenant": "EU.YOURCOMPANY",
  "source": "/sdc/mailer",
  "type": "com.sdc.deliveries.email.sent",
  "time": "2022-03-16T12:56:04.8111884Z",
  "specversion": "1.0",
  "dataschema": "#/v1",
  "datacontenttype": "application/json",
  "subject": "674d25d7319b4549a88cefdda049989e_92233793802426",
  "data": {
    "result": "success",
    "context": {
      "profile": "crm-id-123456789",
      "tags": ["resto-order-now-campaign-spring"],
      "metadata": "{\"name\":\"jane.doe\",\"ref\":123456789}"
    },
    "outcome": "250 Ok",
    "recipient": "jane.doe@example.com",
    "external_reference": "674d25d7319b4549a88cefdda049989e_92233793802426",
    "timestamp": "2022-03-16T12:56:00.1260605"
  }
}

Webhook documentation

All the webhook properties are documented in detail in the webhook documentation.

The breakdown of the delivery event fields is as follows:

  • event wrapper: the event metadata fields, that wrap the event data and provide some context about the event.
  • event data: the actual event payload related to the delivery status of a message.

Event metadata wrapper

{
  "id": "1516952e520547049b8897b24e44553e",
  "tenant": "EU.YOURCOMPANY",
  "source": "/sdc/mailer",
  "type": "com.sdc.deliveries.email.sent",
  "time": "2022-03-16T12:56:04.8111884Z",
  "specversion": "1.0",
  "dataschema": "#/v1",
  "datacontenttype": "application/json",
  "subject": "674d25d7319b4549a88cefdda049989e_92233793802426"
}

These fields represent the metadata of the event, with an ID, the source, the type, the time, the specification version, the data schema and the data content type. Review the webhook API reference for more details about the event metadata fields.

Event data

{
  "data": {
    "result": "success",
    "context": {
      "profile": "crm-id-123456789",
      "tags": ["resto-order-now-campaign-spring"],
      "metadata": "{\"name\":\"jane.doe\",\"ref\":123456789}"
    },
    "outcome": "250 Ok",
    "recipient": "jane.doe@example.com",
    "external_reference": "674d25d7319b4549a88cefdda049989e_92233793802426",
    "timestamp": "2022-03-16T12:56:00.1260605"
  }
}

The event data contains the actual event payload with a number of related deliverability fields and several message-related metadata.

The fields: context, recipient and external_reference refer to the recipient and passed & message metadata tags. The fields: result, outcome and timestamp are technical deliverability fields.

Review the webhook API reference for more details about the event data fields.

Each time a message is sent, Marigold Engage will send a similar webhook request to the webhook endpoint. This would allow you to track the delivery status of each stage.

Event data from Marigold Engage

Messages being sent via Engageor Campaign will use Marigold Engage Delivery Cloud as delivery engine. All the message context information will automatically be provided by SMC/Campaign and passed along EDC.

Message Sending flow via SMC/Campaign

The delivery events triggered by an Engage campaign, will have some specific data in the context part of the event.

{
  "id": "1516952e520547049b8897b24e44553e",
  "tenant": "EU.YOURCOMPANY",
  "source": "/sdc/mailer",
  "type": "com.sdc.deliveries.email.sent",
  "time": "2022-03-16T12:56:04.8111884Z",
  "specversion": "1.0",
  "dataschema": "#/v1",
  "datacontenttype": "application/json",
  "subject": "674d25d7319b4549a88cefdda049989e_92233793802426",
  "data": {
    "result": "success",
    "context": {
      "metadata": "{\"mid\":\"6025\",\"cid\":\"0\",\"lid\":\"9981\",\"aiq\":\"92233829321154\",\"uid\":\"123\",\"aid\":\"0\"}",
      "profile": "9981.123",
      "tags": ["CPG_1_1357", "CPG_EU.ACME_6025"]
    },
    "outcome": "250 Ok",
    "recipient": "jane.doe@example.com",
    "external_reference": "674d25d7319b4549a88cefdda049989e_92233793802426",
    "timestamp": "2022-03-16T12:56:00.1260605"
  }
}

metadata

The metadata field may contain information that is passed along to EDC. This information is purely metadata, and it won't be interpreted by EDC. There is no specific format required for this field.

For messages sent via SMC/Campaign, this metadata will contain a number of SMC/Campaign related fields, serialized in a JSON format:

  • mid: the Marigold Engage MESSAGE ID of the mail object
  • cid: the Marigold Engage CAMPAIGN ID of the campaign object
  • lid: the Marigold Engage LIST ID of the userlist object
  • aiq: the Marigold Engage ACTION IN QUEUE ID of the unique e-mail towards a customer from the ACTIONINQUEUE table (also used in ACTIONQUEUE and FLAGS) - unique for a user (list+userid), campaign, action, iteration (same email sent has a different AIQ ID)
  • uid: the Marigold Engage USER ID of the user object in the userlist
  • aid: the Marigold Engage ACTION ID of the component node of an outbound communication in a journey (Campaign database)

external_reference reference

The message external_reference is generated by SMC/Campaign, will be a combination of the Marigold Engage SLOT ID + ACTION IN QUEUE ID with an "_" as the separator. It is a unique reference for each send message.

Example: ABCD39B2-6031-4427-A5E8-172D6E20B61B_98765 where "ABCD..." is the SLOT ID and "98765" is the ACTION IN QUEUE ID.

context tags

The tags generated by SMC/Campaign, will contain a campaign reference which is a combination of "CPG" prefix, with the "tenant name" and CAMPAIGN ID with an "_" as the separator.

Example: CPG_EU.ACME_45678 where "CPG" is the prefix, "EU.ACME" represents the tenant name and "45678" is the campaign reference.

profile

The profile reference generated by SMC/Campaign, will be a combination of the Marigold Engage LIST ID + USER ID with an "." as the separator.

Example: 9981.123 where "9981" is the LIST ID and "123" is the USER ID.

Back to top