API support is the ongoing human commitment that keeps consumers unblocked, and it’s one of the most consistently underfunded and undervalued parts of running an API — which is strange, because it’s also one of the most directly tied to whether consumers stay or leave. Support is where a developer who hits a wall finds out whether anyone on the other side actually cares. It’s the forum post that gets answered, the GitHub issue that gets triaged, the email that gets a real reply instead of a canned deflection. I’ve argued for years that support deserves to be treated as its own discipline within API operations, with its own building blocks and its own strategy, because the quality of your support is the quality of your consumers’ lived experience with your platform. You can have beautiful documentation and a clean API design, but if a developer gets stuck and nobody helps, all of that polish evaporates into frustration.
The building-blocks approach to support is how I made it a deliberate practice rather than an afterthought, and it’s the same lens I applied to the rest of API operations. I wrote in 2014 about which building blocks to use as part of an API support strategy, because support is not a single thing — it’s a collection of channels, tools, and commitments that you assemble deliberately. Forums, ticketing, email, social media, office hours, self-service FAQs, direct developer support — each is a building block, and the right mix depends on your consumers, your scale, and your resources. I later broke support out into its own separate research area precisely because it had grown into a discipline substantial enough to study on its own terms. Treating support as a deliberate, building-block-driven strategy is how you stop reacting to fires and start providing the consistent, reliable help that consumers can count on.
The relationship between support and developer relations is one of the places organizations get confused, and I’ve worked to untangle it. I wrote in 2017 about the relationship between developer relations and support, because the two are adjacent and frequently conflated, but they’re not the same. Developer relations is about outreach, advocacy, and growing the community; support is about unblocking the people who are already there. They reinforce each other — good support generates the goodwill that makes evangelism credible, and good evangelism brings in the consumers who then need support — but they have different goals, different skills, and different success metrics. Organizations that collapse them into one underfunded role tend to shortchange both. The healthiest API operations recognize support as its own function with its own staffing and its own commitment, connected to but distinct from the outreach side. Support also connects directly to the SLA: I’ve written about the support elements of a service level agreement, because for serious consumers, the support commitment is part of the contractual reliability they’re paying for.
The economics of support are where the business reality bites, and I’ve been honest about the tension. I wrote in 2013 about how much you spend attracting and supporting freemium developers, because support is a real cost, and the freemium model in particular forces a hard question: how much do you invest in supporting users who may never pay? The answer isn’t to abandon support, but to be deliberate about it — to use self-service and community channels to scale the support of free users, while reserving direct, high-touch support for the relationships that justify it. I wrote about sales, onboarding, and support in a self-service API world, because in a self-service model, support has to scale through documentation, forums, and community rather than one-on-one hand-holding for everyone. And support can even become a revenue source — I wrote about generating revenue from the support of public data using APIs, where the support and reliability commitment itself is the thing of value. Support is a cost, but it’s a cost that directly produces retention, trust, and in some models, revenue.
The channels and tooling of support have evolved, but the underlying commitment hasn’t, and I’ve tracked the evolution closely. Forums were the early backbone — I wrote about using existing online forums versus developing your own, weighing the tradeoffs of meeting developers where they already are versus owning the channel. GitHub became a central support venue as issues turned into the de facto support queue for developer-facing products; I wrote about how organizations like InfluxDB separate their bugs, experience, features, and security into distinct GitHub support issues, bringing structure to what can otherwise become an undifferentiated pile. Stack Overflow, social media, chat, and email all became part of the support surface. The tooling keeps changing, and AI-assisted support is the latest shift, but the fundamental commitment underneath all of it is constant: a human being, or at least a genuinely helpful system, is on the other side ready to unblock the developer who’s stuck.
Where I land on support is that it’s the unglamorous, ongoing, human commitment that makes the difference between an API consumers trust and one they abandon — and that underfunding it is one of the most common and most costly mistakes in the business of APIs. Support doesn’t generate the excitement that a launch or a new feature does, but it’s where consumers form their lasting judgment about whether you’re a dependable partner or a platform that left them stranded. The building blocks, the distinction from developer relations, the connection to the SLA, the economics of scaling it, the evolving channels — they all add up to a single truth: support is where you prove, day after day, that you actually care about the people building on your API. The organizations that treat support as a strategic discipline worth real investment are the ones that earn durable consumer loyalty, and the ones that treat it as an afterthought pay for it in churn they never quite understand. Support is the ongoing keeping of the promise that your API is something consumers can genuinely build on, and that promise is kept, or broken, one answered question at a time.
References
- How Much Do You Spend Attracting And Supporting Freemium API Developers
- Which Building Blocks Should I Use As Part Of My API Support Strategy
- Sales, Onboarding, And Support In A Self-Service API World
- Using Existing Online Forums Vs Developing Your Own To Support API Operations
- Breaking Out API Support Into A Separate Research Area
- The Relationship Between Dev Relations And Support
- The Support Elements Of Your API Service Level Agreement
- Generating Revenue From The Support Of Public Data Using APIs
- Separating Your API Bugs, Experience, Features, And Security In GitHub Support Issues Like InfluxDB Does
