Email Events API has stopped returning hmid as of Aug 9


#1

On or around August 9, the behavior of the Email Events API seems to have changed so that the API no longer behaves as documented.

The API is no longer returning the hmid field (which is described in the Email Events API Documentation and included in the Example JSON Output).

This change breaks our API integration to Hubspot because we rely on the hmid to identify email events that we’ve already synchronized. All of our Hubspot customers are impacted by this change.

Hubspot team, can you please confirm:

  1. whether the change in API behavior was intentional;
  2. if so, what is the recommended upgrade procedure for clients who were relying on the previous behavior;
  3. if not, what is the estimated time for the hmid parameter to be restored to the data returned by the API

#2

Here is an example of an API request that exhibits the change in behavior:
https://api.hubapi.com/email/public/v1/events?limit=1000&campaignId=XXXXXXXXXXX&eventType=OPEN&appId=YYYY&startTimestamp=1502269206815


#3

Hello, I am also experiencing this same issue, starting on the same day. I am using the KingswaySoft SSIS Integration Toolkit for HubSpot to retrieve the data and it stopped returning values for this field. This is a required key as it ties all Email Events for a specific email together.

Is this a bug with the API or is there something that needs to be reconfigured? Thanks.


#4

Hey @ApiUser,

I’m curious why you used the hmid field to deduplicate events on your end. They are not unique between events, and they were largely used for internal purposes. We removed the public field since we couldn’t think of a use for it. Why not use the id/created fields, which are documented to uniquely define an event?


#5

Hi @Mike_Axiak,

As @CBZ wrote, the hmid allows us to associate together multiple email events that pertain to the same email.

In our case, we want to track how many emails were opened, without double-counting emails that are opened multiple times. Using the hmid allows us to do that, whereas the id/created fields on the EmailEvent do not give us any way of determining that two open events are both for the same email message.


#6

As @CBZ wrote, the hmid allows us to associate together multiple email events that pertain to the same email.

Unfortunately, no it doesn’t. The docs pretty clearly identify sentBy as the correct way of doing that sort of association, and further, make zero mention of any capability of using hmid for that purpose:

The hmid has never been reliable for correlating events for the same email message:

  • OPEN, CLICK, PRINT, and FORWARD events never had the same hmid as the corresponding SENT event before early 2016.
  • STATUSCHANGE events never had the same hmid as the corresponding SENT event before ~April 2017.
  • OPEN, CLICK, PRINT, FORWARD, and STATUSCHANGE events are still to this day not guaranteed to have the same hmid as the corresponding SENT event, nor has any such guarantee ever existed for these types.
  • We recently discovered an unintended change had resulted in SENT events after March 2017 never having the same hmid as any events we receive from our MTAs – notably DROPPED events with isMtaDrop=true, as well as PROCESSED, DEFERRED, BOUNCE, DELIVERED, and SPAMREPORT events.

Because of the above, we determined there was zero value in having hmid, whether internally or externally, on the events. If you’ve been relying on it, your event correlations are unfortunately incorrect.


#7

Thanks for the information. Sounds like we’ll need to modify our code to use sentBy in lieu of hmid.