Retrieving and storing meeting/call types against Engagements


#1

How do we get a list of these, and assign them to an Engagement?


#2

Hi @jimig,

It's not currently possible to pull a portal's call/meeting types. If you know the values, you can include them when creating an engagement, however. Using the example JSON from the Developer Docs & adding an {{activityType}} field:

{
    "engagement": {
        "active": true,
        "ownerId": 1,
        "type": "CALL",
        "timestamp": 1409172644778,
        "activityType": "Example Activity Type"
    },
    "associations": {
        "contactIds": [2],
        "companyIds": [ ],
        "dealIds": [ ],
        "ownerIds": [ ]
    },
    "metadata": {
        "body": "Example engagement with a custom type",
        "disposition":"b2cf5968-551e-4856-9783-52b3da59a7d0"
    }
} 

#3

Thanks @Derek_Gervais!

Are there any plans to expose those? Otherwise we need to maintain a copy of that list which can easily go out of sync.


#4

Hi Derek, is there any update on this?

I know we can add them but it is key to be able to discover them!

If we pass an invalid value, does the API respond with failure?


#5

Hi @jimig,

There's a new endpoint for pulling call dispositions:

But it's still not possible to pull meeting types at this time.


#6

Thanks, is there any chance this will ever be available?


#7

I finally tracked down the API endpoint for this data by watching the browser console from the HubSpot admin pages:

/engagements/v1/activity-types

This isn't documented though so YMMV.


#8

Hi @jimig,

It's certainly possible; I'm not aware of any plans to implement this in the near term, but that doesn't mean it's never going to happen. If you have the inclination, I would encourage you to check out the Ideas Forum on the HubSpot Community. That's the best place for product feedback/ideas, as it's monitored closely by the product team.

Regarding the endpoint @pherris discovered; as he said, since that's not documented it's not officially supported, and is subject to be changed/deprecated at any time. I'd avoid building anything that heavily depends on that endpoint, in case there are any unannounced breaking changes.