Hoping to pick some brains on a potential solution I'm working with. I'm aware that the Tickets API is still a part of the developer preview program.
Unlike Deal stage, there isn't a "time spent" property equivalent for ticket status (aka ticket pipeline stage). Because of this there's no way to report on that data. Being able to track how long a ticket spends during each status is an incredibly valuable metric for us.
As far as I can tell there's no way to do this within HubSpot itself.
My idea is to create an application that sends a request through API, records the ticket status and its timestamp, and then records new timestamps when the ticket status has been changed. The problem with this is that the API doesn't seem to store any data on previous statuses/stages, so if this application only checks every 30 minutes, and there's multiple status changes within that timeframe, that data will be lost. Neither is the entire application an ideal way to track this sort of metric, but that's what comes to mind immediately.
Any thoughts or suggestions would be greatly appreciated. Thank you!
You're correct; there isn't an ideal solution for your use case in-app or via the Tickets API at this time. I played around a bit with custom ticket properties and a ticket-based workflow in my own account, but was unable to get anywhere close to what you're looking for.
While I expect our product teams plan to expand in-app ticket reporting and feature parity between the Tickets API and other APIs (like Deals) over time, I haven't heard of any concrete plans recently. I'll share your feedback internally, though!
At some point, we also plan to add a webhook subscription type for ticket property updates. This would be significant in your use case, since it would remove the need to poll this endpoint. If and when any of these changes come down the pipeline, we'll update the API changelog. I'll try to post here as well.
That said, your proposal is the most viable solution I can currently conceive. As you realize, though, there would be some limitations. Since the Tickets API currently doesn't return property version histories, and this endpoint doesn't say exactly how the property was changed, you're correct that your polling would miss some changes made in quick succession.
You're correct; there isn't an ideal solution for your use case in-app or via the Tickets API at this time. I played around a bit with custom ticket properties and a ticket-based workflow in my own account, but was unable to get anywhere close to what you're looking for.
While I expect our product teams plan to expand in-app ticket reporting and feature parity between the Tickets API and other APIs (like Deals) over time, I haven't heard of any concrete plans recently. I'll share your feedback internally, though!
At some point, we also plan to add a webhook subscription type for ticket property updates. This would be significant in your use case, since it would remove the need to poll this endpoint. If and when any of these changes come down the pipeline, we'll update the API changelog. I'll try to post here as well.
That said, your proposal is the most viable solution I can currently conceive. As you realize, though, there would be some limitations. Since the Tickets API currently doesn't return property version histories, and this endpoint doesn't say exactly how the property was changed, you're correct that your polling would miss some changes made in quick succession.
.png "HubSpot Employee"){kind=icon}
