How to Best Support Your API Ecosystem

Jason Harmon CTO
by Jason Harmon CTO on January 19, 2023 5 min read

“Removing communication silos and essentially making sure that everyone can see or at least have access to that support structure is key to scaling your API strategy.”

—Andrei Soroker, CEO of Fogbender

This week on the API Intersection podcast, we spoke with Andrei Soroker, CEO at Fogbender, a B2b customer support tool for API-first companies. We often discuss how to secure the right development tools and scale your API program from there, but we often don’t talk enough about supporting the thing when it’s out in the wild. Supporting APIs is innately complex, and Andrei shared his perspective on the matter.

When looking at how these developer-focused companies handled support, Andrei noticed many were stuck between a rock and a hard place, using some combination of a Community Discord channel or Slack environments.

“Supporting many teams of developers growing greater teams of developers in a sensible, scalable way seemed to be an issue that not many were able to solve,” shares Andrei. “Teams of developers know that plenty of their products are used by developers individually. But, when talking about a complex product like an API that is integrated into another complex product, and it’s inevitably driving business, you’re going to be dealing with an ever-changing team of very technical people across multiple organizations who are touching it.”

That’s what makes the support part tricky. Now that team with their own product and API that they need to maintain continuously applies to a large group of multiple different stakeholders, not just individual developers. These large, third-party teams requiring support are comprised of end users, other vendors, and other departments on a customer’s team–and they all require the same exceptional support experience.

“Maintaining continuity between these teams is difficult. How do you make sure that these two developers who work on different continents and happen to be relatively new quickly find each other and understand that they’re both actually working on the same product using the same API? That’s a complicated problem to solve,” shares Andrei.

Team-to-Team Support

One could say the issue is solved by team-to-team support, where one can maintain and keep building those relationships over time. Think of something with a shared channel, such as Slack, where everybody knows that this channel exists, and this is where a particular team congregates.

However, to Andrei’s point, a solution like Slack doesn’t scale well, and it’s not a default option that provides the path of least resistance when providing support to an entire ecosystem of different customers, vendors, and end users all needing to touch that API.

“It’s not in the path of least resistance because that shared channel will not be on the vendors’ Dashboard. You’re not going to be signing in looking for the support section and then discovering that messaging experience there,” shares Andrei. “You’re going to be probably filling out a contact form or using a support email address or something, but then you would have to stumble across that Slack or Discord by happenstance. We’re trying to solve the problem of how do we make that experience on the path of least resistance makes sense and seems seamless for all.”

From Conversation to Action

The other issue with using a messaging platform like Slack or Discord for support scaling in an API-first environment is that while the chat functionality is superior, the actionable part of handling the support ticket/issue needs to be improved.

“When the conversation becomes something actionable, that’s where something like Slack sort of stops scaling. So then you have to create that issue in Jira, so there’s a ticket attached to it. Instead, we’re trying to understand the easiest way for us to create that transition from triage to tie it into systems like Jira or Asana or ticketing system,” shares Andrei. “It’s especially challenging when the customer wants to live in Slack or Microsoft Teams, and it’s on the support vendor to ensure that the ball doesn’t get dropped.”

Fogbender’s goal is to take platforms like Slack and integrate those conversations wherever else the other third-party end users are so that everyone can experience the same end-to-end support experience on an API they are interacting with all in one place. The Fogbender support widget looks similar to other live chat solutions, but all users belonging to the same customer account can collaborate on support issues. Using their tool, you create an equivalent of a shared channel per issue, while in Slack, you’d usually have a single channel with many unnamed threads.

Supporting B2B API-First Companies

The other issue Andrei’s team seeks to solve is providing a support tool specifically for B2B companies dealing with APIs. Looking at a lineup of modern customer support solutions, the majority of established support tools have either been conceived as consumer-focused or evolved to be that due to market pressure.

B2B products tend to be more complex, requiring some degree of integration (more APIs!) to work on the customer’s end. This complicates support because the vendor needs to be aware of all the details pertaining to a specific implementation, which is why specific support solutions for B2B API-first companies are necessary.

I enjoyed learning more about Andrei and Fogbender’s journey, and I’m a strong advocate for getting the support part of your API strategy right. With the continued proliferation of APIs across all industries this year, I believe we will only see growth in the demand for a robust support solution that integrates just as seamlessly as your actual API does. For more insights from industry leaders, check out the API Intersection podcast.

Share this post

Stoplight to Join SmartBear!

As a part of SmartBear, we are excited to offer a world-class API solution for all developers' needs.

Learn More
The blog CTA goes here! If you don't need a CTA, make sure you turn the "Show CTA Module" option off.