Email events
Every email sent via HubSpot generates a number of events detailing its lifecycle and how the recipient interacts with its content. An event is uniquely identified by itsEventId, which is comprised of the following properties:
These properties can be used to look up a specific event via this endpoint.
Further, all but one event type (
UNBOUNCE) have the following properties:
Events can be looked up in bulk via this endpoint using
'recipient', both 'appId' and 'campaignId', or any combination of the above properties.
The following additional properties are also available for all event types (including UNBOUNCE):
These event reference properties are covered in more detail in the section at the bottom of this article.
Event types
There are 12 event types that can be generated by HubSpot’s Email API during the lifecycle of an email message. They are broadly grouped into categories: Submission, Delivery, User Engagement, and User Status. Event types, event categories, and their relationships are diagrammed below.Submission events
When an email message is created and sent by HubSpot on behalf of a customer, HubSpot first verifies whether the recipient is eligible to receive it. If not, HubSpot rejects the message, triggering the creation of aDROPPED event. Otherwise, it’s submitted to HubSpot’s delivery provider for further handling, triggering a SENT event. An email message will almost always have exactly one submission event associated with it; for example, there will never be multiple SENT events for a message.
HubSpot makes every effort to reject messages before passing them along to the delivery provider. However, sometimes HubSpot’s delivery provider will decide to reject a message even after its eligibility has been verified. This follow-on rejection results in a DROPPED event being created, in addition to the previously-created SENT event.
Submission events all share the following properties:
Additionally,
DROPPED events have the following properties:
Drop reasons
Delivery events
Once HubSpot’s delivery provider has accepted an email message, HubSpot creates aPROCESSED event. At this point, the delivery provider has queued the message for delivery. If everything goes smoothly, the delivery provider will dequeue the message and deliver it to the recipient’s email server, generating a DELIVERED event.
Occasionally, things don’t go smoothly, and one of two things happens: delivery is deferred because of a temporary rejection, or delivery fails and won’t be retried.
In the first case, the message could not be delivered to the recipient’s email server for some non-fatal (usually transient reason, such as a spurious time-out. The delivery provider will re-queue the message for later delivery, and HubSpot creates a DEFERRED event. A message can be deferred multiple times before it completes the delivery phase, with a new event created on each attempt.
If delivery fails, no further attempts will be made to deliver the message, and HubSpot creates a BOUNCE event. This can occur for a variety of reasons, such as the recipient being unknown by the email server.
The specific delivery event types have the following properties:
Delivered
Deferred
Bounce
Bounce categories
User engagement events
Once an email message reaches its recipient, there are four different event types that can occur:OPEN, CLICK, PRINT, and FORWARD. These represent the recipient’s interaction with the message and its content, and each can occur multiple times. For example, each time any URL is clicked, a new CLICK event is created, even if that URL has previously been clicked and generated such an event.
User engagement events all share the following properties:
Additionally,
CLICK events have the following properties:
And
OPEN events may have the following property:
User status events
A recipient can also update their communication preferences via the email message. By clicking on the subscription preferences link in the message, they can change their subscriptions, either subscribing or unsubscribing from various lists, triggering aSTATUSCHANGE event. Note that a status change can be for any list(s), not just the one which is associated with the current email message.
An email message may also be flagged as spam by the recipient, resulting in a SPAMREPORT event. Note that this is independent of subscription status — flagging a message as spam does not simply unsubscribe the recipient from the list in question. Rather, the subscription status is left unchanged, and a flag is set indicating that recipient should never receive another email message from HubSpot. Once this happens, you’ll need manual intervention by HubSpot to remove the flag.
A STATUSCHANGE event has the following additional properties:
Subscription change sources
Unbounce events
There is a 13th event type, which is unrelated to a specific email message.UNBOUNCE events occur when a particular email address is either automatically or manually unbounced by HubSpot. This resets the bounce status of the recipient, potentially allowing them to receive emails sent from the account.
Event references
Many events are related to other events that occurred either before or after it. As described in the first section above, HubSpot uses EventIds to build this reference chain.sentBy
As discussed previously, each email message has either aSENT or DROPPED event (or one of each) associated with it. This will be the first event generated for any given message. If a message generates a SENT event, all subsequently generated events will reference that event via the property 'sentBy'.
This backward-reference can be useful to get more information on the parent SENT event, or to manually find all events associated with a given message.
obsoletedBy
Sometimes, a follow-on event occurs for a given message, signifying that an earlier event should be ignored. This relationship is captured in a forward-reference in the property'obsoletedBy'.
For instance, in the case where HubSpot generates both a SENT event and a subsequent DROPPED event, the SENT event is ultimately irrelevant, and is obsoleted by the DROPPED event. Accordingly, the SENT event will reference the DROPPED event via 'obsoletedBy'.
causedBy
Certain events occur precisely because of some previous event, often for a different message. This relationship is captured in a backward-reference in the property'causedBy'. It can be used to get additional details on why a particular event caused the following event.
For example, a DROPPED event will occur when there was a previous BOUNCE event for the same recipient. In this case, the DROPPED event will have its 'dropReason' set to PREVIOUSLY\_BOUNCED, and it’s 'causedBy' will reference that previous BOUNCE event.