Customers

The customer question is the one that the API industry has consistently fumbled, and it matters more than most technical people realize. When I started writing about the business of APIs in 2010 and 2011, the ecosystem was dominated by a particular confusion: providers were treating developers as their customers, but developers weren’t the ones cutting the checks. The developer was the integration point. The customer was the business that employed the developer, or the end user of the application the developer built, or the enterprise procurement office that had to sign off on the API contract. Getting that distinction right — knowing who your actual customer is and building your business model around serving them — turns out to be foundational to whether an API program succeeds or fails as a business.

Biz Dev 2.0 was my early framing for what APIs unlocked in the customer relationship. Traditional business development required formal partner processes, legal agreements, sales cycles — the overhead of doing business through contracts. What APIs introduced was the ability to create a partnership dynamically, through self-service, without a formal conversation. A developer could discover your API, sign up for a key, build an integration, and become a meaningful business partner — all without talking to anyone at your company. That was genuinely new in 2010, and it changed the economics of customer acquisition in ways the industry is still working out. The question it left open was: is the developer who signed up your customer, or is the developer a conduit to a different customer you haven’t met yet?

The answer depends on your business model, and the business model question was one I was pressing hard in 2011. The four levels of an API business ecosystem I mapped out then — internal APIs, partner APIs, open developer APIs, and fully public APIs — each implied a different customer relationship. Internal APIs have internal teams as customers; the economics are cost and efficiency, not revenue. Partner APIs have known business partners as customers; the economics are revenue share and integration depth. Open developer APIs have an uncertain customer mix — some developers are building commercial products, some are hobbyists, some are exploring before committing. Fully public APIs have the broadest and least defined customer base of all. The business model has to match the customer tier you’re actually serving, because the economics of supporting a hobbyist developer with a free key are completely different from the economics of supporting an enterprise integration that generates meaningful revenue.

Salesforce is the company I’ve pointed to most often as the template for doing this right. When I wrote the history of Salesforce’s API in 2011, what stood out was how deliberately they built their API program around their actual customers — the enterprises who were already paying for Salesforce CRM, and the ISVs who were building products on top of Salesforce for those same enterprises. Salesforce didn’t open their API to the world and hope someone would figure out how to make money; they built an API ecosystem that served the customers they already understood, with a partner program, an AppExchange marketplace, and a clear business model for everyone in the chain. The developer wasn’t the customer; the developer was the means by which Salesforce extended value to its customers. That clarity of customer definition is what made it work.

Self-service versus sales-oriented API programs is a real tension, and I wrote about it in 2012 because I was seeing providers struggle with the choice. Self-service — sign up, get a key, start integrating — is the right model for the long tail of developers and for early-stage exploration. Sales-oriented — talk to us, get a demo, negotiate a contract — is the right model for enterprise customers whose integrations represent significant revenue and whose needs require customization and support. The mistake most API programs made was picking one and trying to apply it universally. They’d go full self-service and then find that enterprise customers were falling out of the funnel because there was nobody to talk to when the technical evaluation hit an organizational question. Or they’d go full sales-oriented and find that developers refused to engage because the friction was too high for exploration. By 2014 I was writing about sales, onboarding, and support in a self-service API world as three distinct disciplines that needed to work together — the self-service layer handles discovery and initial adoption, the sales layer handles the conversion of serious users into paying customers, and the support layer handles the ongoing relationship that keeps customers.

The freemium model is where the customer ambiguity gets most acute, and I’ve had complicated feelings about it for years. Freemium is a customer acquisition strategy, not a business model — the free tier exists to get developers through the door, to let them build and experiment, to create the adoption that eventually converts to paying customers. I wrote in 2011 about self-service and freemium being important to API success, but I was also asking by 2013 how much providers were actually spending to attract and support freemium developers relative to what those developers converted into. The honest answer for many programs was: a lot, for not much. The freemium developer who uses your API to build a hobby project, tweets about it, and never pays anything is a cost center, not a customer. The freemium developer who uses your API to prototype something their company ends up adopting at enterprise scale is a customer acquisition success story. The trick is telling them apart early enough to invest appropriately in each.

Beyond partners and developers was a framing I used in 2011 to push providers to think about who else was in the room. The API ecosystem includes the end users of applications built on the API — people who never interact with the API directly but whose experience depends entirely on how it’s designed, how it performs, and what data it exposes. It includes regulators, who have an interest in what the API enables and constrains. It includes competitors, who will use your API access as a competitive intelligence window if you’re not careful. It includes the broader market of potential integrators who haven’t discovered you yet. The customer in the narrow commercial sense is whoever is paying for access. The customer in the broader strategic sense is everyone whose interests the API serves or affects, and a smart API business thinks about all of them. API evangelism as I practiced it was always equal parts internal alignment, partner development, and public outreach — because the customer relationship lives in all three directions at once.

Enterprise customers are where the business of APIs gets most expensive and most consequential, and I’ve spent a lot of time on the enterprise conversation. I wrote in 2011 about the challenges API service providers face in the enterprise space — and they are real challenges: long procurement cycles, security and compliance requirements, the need for SLAs and guaranteed uptime, preference for negotiated contracts over self-service terms, organizational politics that mean the developer who evaluates your API is different from the decision-maker who approves the purchase. The enterprise customer needs to be sold to differently than the developer community. They need case studies from recognizable peers, security documentation, legal review processes, support tiers with defined response times, and sometimes dedicated integration support. One characteristic of many enterprise API people I met by 2014 was that they were exhausted from trying to fit enterprise procurement processes into API programs designed for individual developers — the mismatch was organizational, not technical.

The sales funnel question I raised in 2018 — where am I in the sales funnel for your API? — was a direct expression of frustration with how many API programs had no legible progression from “discovered your API” to “paying customer.” The developer experience and the customer experience were designed independently, and the gap between them was where revenue was falling through. A developer who builds a successful integration on a free tier and then can’t find the path to a commercial relationship isn’t a failed customer — they’re a customer the provider failed to convert. Working with partners to iterate on your API, as I wrote about in 2014, is how you learn what that path should look like, because your partners are your most engaged early customers and they’ll tell you exactly where the friction is if you ask. The partner program — the tier between self-service developer and enterprise customer — is the most under-invested layer in most API businesses, and it’s often where the most valuable customer relationships live.

The deeper point, which I developed through years of watching API programs succeed and fail, is that an API is research and development for your business model. The usage patterns in your API tell you what customers value, what they’re trying to do, what they’d pay more for, and what they’re building around you that you haven’t anticipated. The API is a real-time signal from your customer base — if you’re reading it. The providers that treated their API as a revenue-generating product they needed to understand from a customer perspective were the ones that built durable businesses around it. The ones that treated the API as a technical artifact and the developer program as a marketing function discovered, eventually, that they had an audience but not a customer base. Knowing who your customer is, what they’re trying to accomplish, and how your API fits into their business — that’s the business of APIs, and it doesn’t matter how good the technology is if that question stays unanswered.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

Customers

References

Guidance Details

Explore more

Discover APIs