Request for Engagement Type Filter in API




We have a request for a new parameter to be added on the Engagements API resource that allows us to choose the ‘TYPE’ of engagement that we want to pull from the API, e.g. Task, Meeting, Email etc.


We currently are paginating all data, which is costly on the HubSpot server, and in the client’s time. In one particular case the JSON file exceeds 3MB and the wait time is around 1 minute, because the user has hundreds of emails (type: EMAIL), and we are just trying to grab the tasks. We have to download all engagements and then filter our end which is very costly and slow.


You can view our integration by first creating a free account here, then clicking on the Integrations page from the menu. You'll see that because of the limitations on the API we can only pull the latest 100 engagements, and some tasks could be buried under 100 emails.


A simple solution would be to add a parameter to specify what type of engagement, and that would make our integration with HubSpot killer.


Thank you for your help on this!



5 Replies

Just nudging this to see if HubSpot developers can implement this? We are losing customers as a result of this filter not existing.


We are wanting to extract Tasks and Calls, but as we have a large number of Note engagements (5 million +), it takes forever to extract this.    


As we generate more than 10k engagements over 30 days it's unfeasible to use the 'recently modified' option.


Adding engagement type to the API would enable us to filter server-side.


At the moment, we'll continue hammering your API until you get this in place!





My use case


If my company has 600 engagements with only 3 notes. And I'm using the API to get the notes... the quickest I can do this is 1 min with the API rate limiting.


Was pointed to this issue from the community forum post I made


In our case, we just want the most recent note from a company record, and not having a filter on this API would require hundreds of API calls per company. I'm afraid to roll that out as it might cause our API limits to be exceeded.


Any update on this idea at all? It seems simple enough to implement.