Anything other than webhook subscriptionId?

[awilso30]

Hey all,

Using the developer webhooks, hubspot will respond with a payload that looks like this:

[
  {
    "eventId": "1",
    "subscriptionId": "22022",
    "portalId": "4466460",
    "occurredAt": "1527007125234",
    "subscriptionType": "contact.propertyChange",
    "attemptNumber": "0",
    "objectId": "123",
    "changeSource": "CRM",
    "propertyName": "hs_email_optout_4799042",
    "propertyValue": "sample-value",
    "appId": "145851"
  }
]

In our app we want hubspot to post the above data to us, then take different actions depending on which webhook posted to us.

Currently, the only way I see to differentiate which webhook has posted to us is from the subscriptionId. This isn't optimal as we need to hardcode the id's throughout our app. It would be much more convenient if hubspot sent across a webhook or subscription name instead. Is the subscriptionId the only way to differentiate between webhooks or is there another way?

Sidenote: Does hubspot always post a payload wrapped in an array, regardless if its a single event or not? This has implications as to how we need to unwrap the data after receiving it so it would be good to have a definitive answer.

Thanks!
Alex

[RafalCzabaj]

Hi @awilso30

By the different webhook, are you refering to a type of action (deletion / update / creation)
or you do have multiple applications installed in different HubSpot portals?

If this is the first case, then we can depend of the subscriptionType, as they have always
3 available values for each object (deal/company/contact) which are propertyChange / creation / deletion.

If this is the second case, then it is indeed as you said. The payload is static and not extendable in anyway (at least to my knowledge). As we had an issue related to that, and asked HubSpot to introduce kind of template token or anything similar. However the status of this is unknown.

About sidenote; we have observed, that even for single calls, he is still sending data as an array.

In which technology you are developing your software?

Kind Regards,
Rafal

[awilso30]

Hey Rafal,

Thank you for your response - its good to know we can rely on a consistent shaping of the payload from Hubspot.

In regard to the meat of your response and my original post - we have one external app, that we will be setting up multiple types of different webhooks for. Since Hubspot only allows for a single endpoint, I was hoping we could rely on something else instead of the subscriptionId. I know of the subscriptionType, but what if we have multiple different webhooks for the same subscriptionType (this is the exact case I'm dealing with now) that we need to differentiate between?

[RafalCzabaj]

Hey @awilso30

We have decided to not use subscription Id, as we didn't check if it will be changing or not, when we install our "webhook" application to multiple portals. Instead of that, we have made a gateway which redirects further using the portal Id. After the gateway, we have our cloud up which listen on various endpoints, but the key information is a pair of Portal + subscriptionType. Thanks to that, we know what is the origin source of our message.

Hope this information will help you. Have a good weekend!