API Limitations for an Extension Integrator

[digows]

I'll list here several limitations we are facing with our new integration with Hubspot:

1. The webhook's payload doesn't contain any information about the user/owner who made the action. One thing is the object owner; another thing is who made the change.
2. We track actions to gamify. So we need to track any update that can occur involving Deal, Contact, Company objects. Is there a way to avoid creating one webhook for each field? Even if not, your API is limited to track some changes (there a few fields only);
3. The webhooks are managed globally independent of instance installation, right? So how to avoid unwanted webhook requests considering that some customers could be facing payment problems or the app will be disabled for some time? It's basic we be able to avoid Hubspot to generate unwanted requests by instance, not only globally.
4. To avoid unnecessary calls against the Hubspot API, it would be very smart if the webhook's payload could contain the object metadata involved. I always need to make one or three requests to build the object metadata. This is the kind of bad design that affects performance and all co$t involved for us and probably for Hubspot too;
5. It’s basic, but important, the User API (called “owners”) doesn’t return the profile picture.

The question here is if these points could one day be solved. It's crucial for me as an integration partner to know if yes or not. I hope someone could give us an answer.

[Derek_Gervais]

Hey @digows ,

Congrats on launching your new integration to the HubSpot Marketplace! I appreciate the feedback & clear description of your use case for the Webhooks API. Let me try to give some context around your specific points first:

1. You're spot on, webhook notificaitons don't include any information on who made a particular change. The majority of property change notificaitons are actually the result of automated/external processes (e.g. workflows, form submissions, etc.), so there isn't always a clear answer to "Which user made this change."
2. This is feedback we've heard before; there isn't currently any "Subscribe to all" webhook subscription type, though it's something that the team has considered. One particular challenge with that functionality is maintaining a good signal-to-noise ratio; some changes (e.g. last updated, certain score properties, etc.) happen so often they may drown out other meaningful notificaitons.
3. Right now, all webhooks are global (in the sense that they're set at the application level, not the install level). While it's not currently possible to deactivate subscriptions for specific installs, each notificaiton includes the account's Hub ID in the body, which can allow you to identify requests coming from disabled/delinquent accounts.
4. You're spot on that webhook payloads include very little object metadata. This is actually intentional; webhook notificaitons are kept intentionally lightweight in order to reduce the amount of redundant data being sent (among other things). What specific metadata do you need to pull after receiving a webhook notificaiton?
5. You're exactly correct; currently, no HubSpot API returns a user's profie picture.

Broadly speaking, many of your points mirror feedback that the team has heard in the past. While we don't have any specific announcements related to the Webhooks API at this time, I'm happy to pass this feedback along internally. The team is continuously working to improve the reliability, stability, and functionality of webhooks.