API Call & Webhook Monitoring

HubSpot’s Developer-facing tools include API Call Logging and Webhook Logging. 3rd party developers use these tools to check on their app performance and to debug issues. 

Problem

We have seen a number of postings to our developer forums asking for integration feedback such as success and failure messaging for API calls and Webhooks. This need was backed up by a consistent number of cases in Support with developer users looking for debugging assistance.

Goals

  • Reduce Support cases related to developer portals: We would have a direct impact on the reduction of support costs if we reduced the number of developer-tool related support tickets. These tend to be more technical in nature, taking up more time and are more expensive than the average case. 

  • Reduce time spent creating new 3rd party integrations and troubleshooting: One of HubSpot’s goals is to create a thriving 3rd party integration market. In order to reach these goals, we need to make app creation easier for developers by surfacing API call and Webhook activity for more efficient troubleshooting.

Discovery

User Testing Main Takeaways

  • Correctly expected UTC link would switch time zone; suggested UTC to be default

  • Expected ‘Fancy’ JSON view to be default with collapsible tree structure 

  • Enough data was surfaced on errored calls to troubleshoot

  • Preferred cURL format with Copy to clipboard functionality 

  • ‘Show details’ tab was biggest point of confusion, did not expect to see overview graphs; liked the information and display but wasn't in intuitive location 

Solution

Based on the data from the forums and our Support department, we knew the best place to surface integration status details would be in-app in the form of a skimmable call logging UI. After doing research on API call logging interfaces and several white boarding sessions with my product manager and engineering team lead, we came up with a list of features to focus on for the MVP.  

I wireframed various layouts to take to my team for an initial round of feedback, keeping in mind the following main design decisions: 

  • how to structure the UX/UI so that the list of API calls was skimmable yet still offered enough detail for debugging

  • how to quickly indicate errored vs successful API calls

  • how to allow for advanced search capabilities and filtering

Additionally, we’d be able to piggy back on this new API Call UI to add a home for the new Webhook Logging.

Designs

I wireframed various layouts to take to my team for an initial round of feedback, keeping in mind the following main design decisions: 

  • how to structure the UX/UI so that the list of API calls was skimmable yet still offered enough detail for debugging

  • how to quickly indicate errored vs successful API calls

  • how to allow for advanced search capabilities and filtering

Meanwhile, the brunt of the Webhook work involved figuring out how to surface the most useful information while staying within the confines of the existing UI structure. To not overload the app nav bar and maintain a clear hierarchy, we merged the two tools into one app level nav item with secondary navigation.

Designs

API Call Monitoring UI

Webhook Logging UI

Filter options