API marketing is the work of getting a developer from "I have this problem" to a working integration, and then keeping them. It looks nothing like SaaS marketing, because the buyer is the builder, the evaluation is a build, and the product's interface is its documentation.
The nine plays below are ordered the way a developer moves: find you, understand you, try you, ship with you, pay you, stay.
TL;DR:
29 of 30 leading API companies already publish an llms.txt, and Google Search ignores the file entirely. It is a checkbox, not an advantage, so stop treating it as an AI-visibility strategy.
23 of 25 API companies publish a real price without a sales call. Transparent pricing no longer differentiates you; whether a developer can predict their bill from it still does.
On Resend's launch thread, 22 of 71 top-level comments named a competing product by name. A developer's first reaction to your launch is comparison, so publish the comparison yourself.
89% of developers use AI, but only 24% design APIs for AI agents. That 65-point gap is the clearest unclaimed positioning available in this category right now.
46% of developers distrust AI accuracy, compared with 33% who trust it. Getting recommended by an assistant is not the win; being the page that survives the verification click is.
Domain familiarity, not seniority, predicted how fast developers onboarded onto an unfamiliar API. Your quickstart should teach the domain concept, not the syntax.
Why does marketing an API not work like marketing software?
Three structural differences change the work. Everything in the nine plays traces back to one of them.
Buyer is the builder
In most B2B software, the person who evaluates is not the person who implements. With an API, they are the same person, and the evaluation is an implementation. A developer does not read your comparison page and form an opinion. They open a terminal, paste a request, and see what comes back.
Derek Gilling, who runs the API management group at WSO2 and previously founded Moesif, describes the shift in a 2025 talk on growing an API program: twenty years ago software was bought on perpetual licenses across a whole organization, then the SaaS era let small teams pick their own tools, and now a single developer picks an API and ships an application in an afternoon. Purchasing authority moved down to one person with a credit card.
Documentation is the interface
For a UI product, the docs are the fallback when the UI fails. For an API, there is no UI. The documentation is where the product is experienced, evaluated, and learned. That is why doc quality is a marketing metric and not a support metric.
Trust is granted slowly and revoked instantly
Harry Cooper of daily.dev puts the difficulty simply: "It's like you're trying to sell a car to a mechanic." His argument is that developers arrive at every interaction with their guard already up, that they will see through marketing language immediately, and that the standard "start with why" advice inverts for this audience. Start with what it does. Let them decide whether the why is interesting.
The cost of getting those wrong compounds. Cooper estimates a one to two-year lag between brand building and results in developer marketing, which means a trust failure this quarter shows up in the pipeline two years out, long after anyone connects the two events.
1. Target the problem term, not the category term
Rank for the sentence a developer types at 11 pm with a half-finished feature, not the noun that describes your market.
Why category terms underperform for APIs
Category terms attract people researching a space. Problem terms attract people mid-build. For an API, only the second group converts on the same visit, because only the second group has a reason to make a request today.
The SERP census above is one instance of a general failure. "API marketing" is contested by Meta's docs. "Email API" is contested by every incumbent's homepage. Neither is where the intent lives.
Four term shapes that actually work
Task terms: The literal job, in the language of a specific stack. "Send SMS from Python." "Verify a webhook signature in Go." These map one-to-one onto a quickstart page and a code sample.
Alternative and comparison terms: "[Incumbent] alternative." "[A] vs [B]." Developers search these constantly, and the pages are cheap to build and easy to keep honest. On the Hacker News thread for Resend's launch, 22 of the 71 top-level comments named a competing product by name. Comparison is a developer's default posture, so publishing the comparison yourself is the only way to control how it reads.
Error and failure terms: The exact string a developer pastes into a search box. These have low volume, near-zero competition, and the highest intent of anything on this list, because the person searching is blocked right now.
Integration terms: "[Your product] + [their stack]." Every framework, language, and adjacent tool your API is used with is a page.
How to build the list
Pull the questions from where developers ask them rather than from a keyword tool. GitHub issues in your own repository and on adjacent repositories. Stack Overflow tags for your category. Your support inbox. Your sales-engineering call notes. Each recurring question is a page, and the phrasing of the question is the H1.
If you want the channel-level version of this, we cover it in developer marketing channels and GitHub SEO.
2. Lead with what it does, not why it matters
Write the feature. Stop before the benefit sentence.
This is the single largest stylistic difference between developer marketing and everything else, and it is the one marketing leaders find hardest to accept, because the benefit sentence is what most marketers were trained to add.
Cooper's framing from the daily.dev talk: "In every other walk of life, in every other area, marketing material is all focused on the benefit and then the feature. In dev marketing, really the best examples, you have feature, full stop. You don't need to add anything to it. They will decide for themselves."
The mechanism is not stylistic preference. A developer reading your page is running a fast comparison against a mental model of how they would build it themselves. Benefit language carries no information for that comparison, so it reads as noise, and noise on a technical page is a signal that the writer does not know the technology.
What this looks like in practice
| Instead of | Write |
|---|---|
| "Effortless payments infrastructure for modern businesses" | "Charge a card with one POST. Settlement in two business days, 135 currencies." |
| "Industry-leading reliability you can count on" | "99.99% over the last 90 days. Status history at [link]." |
| "Simple integration that scales with your team" | "Three lines to first call. Rate limit is 100 req/s on the free tier, raised on request." |
Every replacement swaps an adjective for a number or a mechanism. That is the whole technique, applied everywhere: homepage, docs, ads, launch posts, conference booth copy.
AI complication
Cooper adds a newer, sharper warning. Almost everyone thinks they can spot AI-generated text; developers definitely can, and it turns them off a brand instantly. If your API landing pages, changelog entries, and tutorials read as generated, the technical audience is the one segment that will reliably notice and quietly discount you. Generated volume is a specific risk in this category rather than a general one.
3. Instrument the funnel: signup, first call, first working app
Stop reporting on API calls. Report on how many developers cross three thresholds.
Gilling's adoption funnel has exactly three stages, and most API programs measure none of them:
Signup: An account exists.
First, hello world: The developer has made one successful call, usually from curl or Postman. They have proven to themselves the thing responds.
First working app: They have built something they would show a colleague. This is the threshold that predicts revenue, and it usually happens before any money changes hands.
The gap between stage 2 and stage 3 is where API programs quietly die, and it is invisible to any dashboard that counts requests.
Why request volume is the wrong metric
Gilling makes a point that inverts most usage-based instincts: "It's actually better for a developer to have fewer requests on your API than more." A developer hammering your endpoint a thousand times for one business outcome is not engaged; they are doing it wrong, and the fix is a batch endpoint. Volume that comes from inefficiency looks like growth on a chart and churns within two quarters.
The replacement is an outcome metric specific to your category. A data API should count match rate. A transcription API should count usable output. An agent or workflow API should count completed business actions rather than calls attempted.
The retention curve nobody plots
Gilling showed week-one retention split by plan: enterprise developers held at roughly 75%, self-service at roughly 38%, and both flattened after the initial drop. A flat curve is a healthy product. A curve that keeps sliding toward zero means the answer is not more marketing.
That distinction is a budget decision disguised as a chart. If your self-service curve does not flatten, spending more on acquisition is buying developers who will leave, and the fix sits in onboarding or documentation instead.
Three thresholds worth measuring, and the curve that tells you whether to spend on acquisition or onboarding.
4. Cut time to first call by removing gates, not by rewriting the quickstart
The standard response to slow onboarding is to rewrite the getting-started page. The delay is almost always upstream of it.
Damian Thurnheer, who publishes the APIGuru channel on API portals, uses a 5/5/5 benchmark that is the most useful single target I have seen for this: a developer should understand what the API does within five seconds, send a test request within five minutes, and build a minimum viable product within five days.
Run your own product against it with a stopwatch and a colleague who has never used it. The result is almost always a gate, not a paragraph.
The gates that cost the most
Approval before a key: If a sandbox key requires a human to approve it, your five-minute target is dead before the copy is written. Thurnheer's rule is to auto-approve accounts for low-risk and sandbox APIs so developers are productive immediately.
A sales call before access: Gilling is blunt about the sequencing: sales engaging before a developer has touched the API is "the worst thing you can do." His flywheel puts self-service trial first, and sales engagement only after the developer has already built something and can articulate what they need.
Procurement before a credit card: A developer who has to route a trial through purchasing will not evaluate you this quarter. Click-through terms of service and card payment for a small starting tier sidestep the process entirely. Gilling frames the goal as a paint sample rather than a house: get them paying a token amount, perhaps one or two hundred dollars a month, and let expansion follow the work they build.
A separate token flow after the key: Thurnheer notes a specific pattern he sees repeatedly: portals where getting an API key is easy but obtaining an access token is unnecessarily complicated. Both paths need to be fast, and teams routinely fix only the first.
Thing that is not a gate
Page speed. Cooper's version: "You could have Steve Jobs writing your ad copy. If you send them to a landing page that doesn't load for 5 seconds, if it's full of irrelevant information, or you have a lead capture form that asks them their family history and credit card information, you're still not going to get signups." Thurnheer's target for developer portals is one to two seconds.
If your onboarding path has gates in it and nobody owns removing them, that is the work we do inside documentation infrastructure engagements: mapping the actual path from landing page to first successful call, then rebuilding the parts that add steps.
5. Make the docs teach the domain, not the syntax
The best evidence on this comes from an eye-tracking study, and its main finding is not the one most doc teams optimize for.
Michael Meng, Stephanie Steinhardt, and Andreas Schubert observed eleven professional developers solving tasks with an unfamiliar API, recording screen activity and eye movements. The paper, How Developers Use API Documentation: An Observation Study, was published in ACM SIGDOC's Communication Design Quarterly in 2019. Mean time per task was 695 seconds, with wide variation between participants.
The finding that changes what you write
Participants split cleanly into fast and slow groups, and general seniority did not predict which group a developer landed in. Two participants with more than ten years of experience finished quickly; three others with comparable experience took far longer.
What did predict speed was domain familiarity. The test API was built for e-commerce. Every developer in the fast group currently worked in e-commerce. Only one of the slow group did.
The implication for anyone commissioning documentation: a developer struggling with your API is usually not struggling with your syntax. They are struggling with your domain. If your API is for payments, the hard part is settlement, chargebacks, and idempotency, not the shape of your JSON. Docs that explain only the endpoint teach the easy half.
Two reading strategies, one page
The same study maps its participants onto Clarke's developer personas. Opportunistic developers start coding immediately and hunt for a code example that addresses the exact thing in front of them, jumping between pages without a visible search strategy. Systematic developers first explore, prepare their environment, send a test request to confirm the request-response cycle works, and only then start the task. Notably, the systematic developers still began every task by taking a clean code example from the documentation and modifying it.
Both groups start from a code example. Neither reads your conceptual overview first.
Gregory Koberger, who founded the documentation platform ReadMe, made the same observation in the Hacker News discussion of the study: "people like code examples! Most people will scan until they see one, and start there... Going to the reference guides to learn an API is like reading a dictionary to learn English. There's not a lot of context."
What to build from this
Put a runnable example above every explanation on every page. Write the conceptual material as annotations attached to examples rather than as a separate section that opportunistic developers will never open. Teach the domain concept at the point where the code touches it. And if you are deciding how to split conceptual guides from reference material, the practical differences are covered in user guide vs API documentation and product documentation best practices.
Both opportunistic and systematic developers start from a code example. The conceptual material has to live beside the code, not above it.
6. Price on the unit your customer already counts
Charge for the thing your customer measures in their own business review, not for the thing your infrastructure measures.
Gilling's slide on this had a dozen candidate billing metrics and, deliberately, not one of them was API calls. The alignment principle is simple: a telecommunications API charges per message because messages are what its customer counts. Stripe charges on payment volume, the familiar 2.9%, because its customers are trying to grow payment volume. Both sides want the same number to go up.
Charge per API call, and you have made your interests oppose your customer's. They now want to call you less. Every efficiency improvement they make reduces your revenue, and every conversation about optimization becomes adversarial.
Public pricing is table stakes, not a differentiator
I checked the pricing pages of 25 developer API companies for a published dollar figure a developer can read without contacting anyone. 23 of 25 publish one. Only two, Plaid and Agora, route entirely to sales.
So publishing a price does not distinguish you. What still distinguishes you is whether a developer can predict their bill from that price, and most cannot. Gilling names billing surprises as one of the biggest sources of churn under usage-based models, describing the developer who "suddenly gets a $10,000 bill and they don't know what to do with that."
The three controls that prevent that
Real-time usage visibility: the developer can check themselves at 2 am without opening a ticket. Cost and quota alerts they configure rather than ones you configure for them. Proactive contact when an account spikes, ideally to right-size the plan or recommend a cheaper call pattern, which sounds like leaving money on the table and is the reason the account renews.
What a pricing change costs when you get it wrong
Two public examples set the ceiling on this risk. Reddit's 2023 API pricing change produced a roughly $20 million annual bill for the developer of Apollo, a single third-party client, and the app shut down. Twitter's new API pricing started at $42,000 per month, which removed an entire generation of research and hobby projects from the platform.
Neither company lost only the developers who were repriced. Both lost the willingness of every other developer to build on a platform they do not control. That is the asset a pricing decision actually puts at risk.
7. Show up where the problem is being solved
Reach a developer in the minute they are looking for what you sell, and you need almost no budget. Interrupt them, and no budget is enough.
Cooper draws the distinction that makes this operational. Some channels are interruption channels, where a developer is mid-task, and you are in the way. Some are exploration channels, where a developer is deliberately looking around. His estimate: if a developer is online in a professional capacity, roughly 95% of the time they are actively trying to solve a problem and do not want to be disturbed. The remaining window is the one worth buying.
His conclusion is a budget argument, not an aesthetic one: "A smaller budget campaign that is on the right channels and well thought out will outperform a bigger budget campaign that is generic and sloppy."
The cheapest acquisition story in this category
Bill Doerrfeld, then editor-in-chief at Nordic APIs, told an audience in 2017 about IPinfo.io, an API that returns information about an IP address. In his telling, the founder found the right Stack Overflow question, answered it, and that single answer drove the service to 250 million daily requests on a zero-dollar marketing budget.
Treat the specific number as a claim from a 2017 conference talk rather than an audited figure. Treat the mechanism as entirely real, because it is repeatable: one accurate answer, permanently attached to the exact question your buyers ask, compounds for years in a way an ad flight never does.
Owning the conversation
Doerrfeld's talk closes with a line from Kin Lane, the API Evangelist, that has held up better than most 2017 marketing advice: "Either you own the conversation around your APIs or someone else will." His example was Tinder, which had no public API program, so a third party published one on GitHub and the conversation moved somewhere Tinder did not control.
In practice, owning the conversation now means being present and useful in the places developers compare tools before they visit any vendor site: Reddit threads, Hacker News comments, Stack Overflow answers, GitHub discussions. It is slow, it does not attribute cleanly, and it is the highest-trust surface available. We run this as a discipline rather than a campaign, and the mechanics are in Reddit marketing strategy and developer community engagement.
Attribution will not cooperate
Cooper's warning is worth passing to whoever owns your dashboard. Developers do not follow the click-and-convert path B2B attribution assumes. They open a new tab, sit on it for a week, and convert later through a channel that gets the credit. They are also privacy-conscious and block tracking at higher rates than any other audience. Judging developer marketing on last-touch attribution will systematically defund the channels that are working.
8. Get retrieved, and then survive the verification click
An AI assistant recommending your API is now a common first touch. It is not a decision. What happens in the thirty seconds after is the decision.
The retrieval half of this is nearly saturated. I checked 30 leading developer API companies for a machine-readable llms.txt file at their documentation root. 29 of 30 serve one, verified by content type and file contents rather than a status code. The exception is OpenAI, which serves the file at a path rather than the domain root. Deepgram's version even opens with a section headed "Instructions for AI Agents."
Two conclusions follow, and both save money.
First, the file is not an advantage. When 29 of 30 competitors ship it, it is a checkbox.
Second, Google states directly that its Search systems don't use these files: maintaining one "will neither harm nor help your site's visibility or rankings in Google Search, as Google Search ignores them." The same guidance tells you to ignore chunking content for AI and rewriting content specifically for AI systems. What Google says to do instead is provide a unique point of view and non-commodity content, explicitly warning against producing what a generative model could produce on its own.
The verification click is where the decision happens
Here is the part almost nobody builds for. Developers do not trust the recommendation they were given.
The 2025 Stack Overflow Developer Survey found that more developers actively distrust the accuracy of AI tools (46%) than trust it (33%), and only 3% report highly trusting the output. Experienced developers are the most sceptical: 2.6% highly trust, 20% highly distrust. The single biggest frustration, cited by 66%, is "AI solutions that are almost right, but not quite." And when asked when they would still want a human, 75.3% answered: "when I don't trust AI's answers."
So the sequence for a growing share of your pipeline is: an assistant names your API, the developer immediately doubts it, and they go looking for corroboration. Your job is to be what they find. That means a page that states the constraint the assistant glossed over, publishes the rate limit, shows the error case, and dates itself. Content written to be cited is a different artifact from content written to be summarised, and we cover the distinction in AEO for developer tools.
This is not theoretical work. On our AppSec program with OX Security, the same approach produced 333 Google AI Overview citations across 65 pages, alongside growth from 89 to 509 keywords in the top three positions.
Agent is becoming the consumer
The 2025 Postman State of the API report, based on more than 5,700 developers, architects, and executives, names the gap: 89% of developers use AI, but only 24% design APIs for AI agents. On the protocol that connects them, 70% of developers are aware of the Model Context Protocol, and 10% use it regularly.
Read those together, and the positioning opportunity is unusually clear. Being early to "our API is designed for agents to call, here is the MCP server, here is what an agent gets wrong and how we handle it" is a differentiated claim today, in a category where 76% of your competitors are not making it.
The retrieval checkbox is done. Designing for the agent that calls you is not.
9. Never break what they built
Retention in an API business is a promise about the future, and every deprecation tests it.
A developer who integrates your API has staked their own reliability on yours. When you break a contract, you do not inconvenience them, you page them. Gilling's version: "I don't want to get woken up at 3 in the morning. Developers don't want to get woken up at 3 in the morning."
The three things a deprecation needs
A long window: Gilling suggests six months to a year or more before an endpoint disappears, and the incumbents in this category run to the long end of that range with versioned endpoints so existing integrations keep working while the new one ships alongside.
A migration path: Not a notice, a path. Which endpoint replaces this one, what changes in the payload, and what the diff looks like in code. Gilling goes further and argues you should give them the path even if it leads to a competitor, on the grounds that a developer you exit gracefully is a developer who recommends you.
Overcommunication: Automated notices, changelog entries, and direct contact for the accounts actually calling the affected endpoint. His rule: better to overcommunicate than to undercommunicate.
What this buys you
Trust that outlives your current product. Cooper's stated end goal for developer marketing is that a developer trusts your brand enough to pick you "before they even have the problem that you fix." That state is only reachable by a company with a multi-year record of not breaking things, and it is the reason incumbents in this category are so hard to displace.
Where do API marketing programs usually stall?
Four failure patterns recur, and three of them are invisible on a marketing dashboard.
Marketing a product the docs cannot support. Demand generation works, developers arrive, and they cannot reach a first call. The signup number looks healthy for a quarter while the retention curve slides. The signal is a widening gap between stage 1 and stage 2 of the funnel in Play 3.
Treating developer-first as product-led growth. Gilling separates these deliberately. PLG assumes one persona; a developer audience is many, spanning experience levels, languages, frameworks, and use cases, some integrating for an internal tool and some building a revenue product on top of you. One onboarding path for all of them under-serves most of them.
Forgetting the other stakeholders. The developer picks, but security review, legal redlines, and procurement still decide. Gilling's point is that a developer champion has to survive a committee, which means your documentation needs a page written for the security reviewer as much as it needs a quickstart.
Optimizing the wrong half of AI visibility. Publishing the file, chunking the content, rewriting pages for machines, and then losing the developer at the verification click because the page has no specific constraint, number, or failure case on it.
What should you do in the first 90 days?
Sequenced so each step tells you whether the next one is worth doing.
Weeks 1 to 2. Time yourself: Run the 5/5/5 test with someone who has never used the product. Record where the clock stops and what caused it. This costs an afternoon and reorders everything after it.
Weeks 2 to 4. Instrument the three thresholds: Signup, first successful call, first working app. If you can only build one, build first-call, because it isolates onboarding from acquisition.
Weeks 3 to 6. Remove the top two gates: Almost always a key that needs approval and a form that asks for more than an email address.
Weeks 4 to 8. Build the problem-term pages: Start with error strings and integration pages, which are fastest to write and have the least competition. Comparison pages next.
Weeks 6 to 10. Rewrite the top five doc pages example-first: Runnable code above the fold, domain concepts annotated onto the code.
Weeks 8 to 12. Plot the retention curve: If it flattens, increase acquisition spend. If it does not, go back to weeks 3 to 6, because you are pouring developers into a leaking product.
Nothing on that list requires a rebrand or a campaign. Most of it is engineering and writing work that marketing owns the outcome of, which is the awkward organizational fact at the center of this discipline. If that split is unclear in your org, what developer marketing actually covers maps the boundaries.
A 90-day sequence where each step tells you whether the next one is worth funding.
Conclusion
You now have three things you didn't have before: a benchmark to test your onboarding against, a funnel with the two thresholds that predict revenue, and a way to tell whether your next dollar belongs in acquisition or in onboarding.
Start with the 5/5/5 test. It takes an afternoon, needs no budget, and tells you within one sitting whether the rest of this list applies to you or whether you have a gate problem to fix first.
If the answer comes back badly and the fix is documentation and technical content rather than campaigns, that is the work Infrasity does: engineers who write, building the quickstarts, API guides, and comparison pages that developers actually reach a first call from.
Frequently Asked Questions
What is API marketing?
API marketing is the practice of getting developers to discover, evaluate, integrate, and keep using an API product. It differs from software marketing because the evaluator and the implementer are the same person, the evaluation happens in a code editor rather than a demo, and the documentation functions as the product interface rather than a support resource.
How is API marketing different from developer marketing?
API marketing is a subset of developer marketing with a narrower and more measurable job. Developer marketing covers any technical audience and product, including CLIs, frameworks, and platforms. API marketing adds a specific adoption path (signup, first call, first working app) and a specific pricing problem, because usage-based billing links your revenue to a metric your customer is usually trying to reduce.
How do developers actually find APIs?
Mostly through problem-shaped search, peer recommendation, and now AI assistants. The 2025 Stack Overflow survey reports 84% of developers using or planning to use AI tools, with 51% of professional developers using them daily, which puts assistants firmly in the discovery path. Directories and marketplaces still generate some volume, but they rarely produce the deep integrations that retain.
What metrics should we report on an API program?
Report adoption, engagement, and retention separately. Adoption is the three funnel thresholds. Engagement should be an outcome metric specific to your category rather than request volume, because inefficient integrations inflate request counts without creating value. Retention is a cohort curve, and the question is whether it flattens.
Should we publish an llms.txt file for our API docs?
Publish one, expect nothing from it. In my check of 30 leading API companies, 29 already do, so it no longer differentiates. Google states that its Search systems ignore these files entirely, and they will neither help nor harm rankings. Other retrieval systems do use them, which is why it stays on the list, just near the bottom.
How long does API marketing take to show results?
Onboarding fixes show up within weeks because they move a measurable conversion rate. Content and community compound over quarters. Brand trust is the slowest, with Harry Cooper of daily.dev estimating a one to two year lag between brand investment in this audience and visible results.
What is the fastest way to improve API adoption?
Remove the approval step between signup and an API key, then remove every form field that is not an email address. In most programmes this moves time-to-first-call more than any documentation rewrite, because the delay is procedural rather than editorial.
