- developer marketing newslepear
- Posts
- đ#107 Marketing API products to devs
đ#107 Marketing API products to devs
Markepear is going full ".dev"
Hey,
So I changed my website domain from markepear.com to markepear.dev. â.comâ never felt right but somehow I missed the obvious solution. Anyhow. I am still very much a dev markepear đ. Maybe even more so. Also shout out to all the awesome dev avocados đ„ reading!
This week on the agenda:
How to market API products to devs
⊠and there is a lot in there, trying out a new format this week
+ a few bonus links at the end
Total pearusing time: 15min
Before we start a word from this weekâs sponsor:
Learn how Postman, Vercel, Sauce Labs, & Clay run product-activity based emails with Inflection.io
Did you know Inflection.io is the email platform behind modern DevTools companies like Postman, Vercel, Sauce Labs, Clay, and Nylas?
Inflection.io is the only marketing automation platform that enables developer marketing teams to activate CDP and data warehouse to drive more pipeline, product adoption, revenue expansion, and more.
Learn more about Inflection.io.
Developer marketing insights
How to market API products to devs
Originally posted on my blog markepear.dev
I recently advised a startup building a fintech API. As I prepared for our discussion, I drafted notes on how to market APIs to developers which ended up being this article. The tips below focus on APIs specifically, though general dev marketing rules still apply. If you want an overall view of marketing to developers, check out my main developer marketing guide.
Here is my TLDR for API marketing:
Youâre marketing a âboringâ product that solves a real pain, so focus on demand capture (show up where devs are actively searchingâGoogle, YouTube, Reddit, Slack, ChatGPT, etc.).
Offer a developer-first experience on your site, from obvious dev portals to friction-free sign-up.
Provide top-notch docs, SDKs, and a quick path to that first working API call (review this path regularly to find and fix friction).
Maintain transparent, usage-based pricing (plus a free tier if you can).
Consider Launch Weeks to bundle minor releases into a bigger, more visible launch.
Dev âinfluencersâ can be powerful if you integrate your API naturally into real-world coding projects.
Youâre Marketing a âBoringâ Product That Solves a Real Pain
APIs products are boring, and they should be. You want to connect them, use them, py for them, and most importantly never look at them again. Itâs like marketing a utility (think electricity bill): itâs not supposed to be flashy; it should just work, be easy to pay, and scale as needed. Same with an API product: itâs âboringâ by design, but that also means you have to approach marketing differently.
Folks from Lago said it perfectly in this Reddit post:
I also loved this episode that where the founder of OpenCage shared that perspective/experience with their Geocoding API.
OK, so how do you get them noticed? Focus on demand capture: be where devs search for solutions in the moment they need them.
If a developer is actively typing âhow to integrate payment gateway in Python?â or âspeech-to-text API for real-time calls,â theyâre in a buying mindset. Thatâs your golden ticketâshow up in their results. They only look when they need it, they have high purchase intent, and if youâre visible, you could be chosen on the spot.
Google & YouTube (Organic + Ads)
Devs might type âhow to accept payments via Nodeâ into Google and scan the top links. They may also watch YouTube tutorials on âhow to set up webhooks.â You want to appear in both places, organic or paid.
Organic search: Blog posts or doc pages that specifically address âhow to do X with [Your API].â Optimize headlines, meta descriptions, and content. If you solve a common dev use case, your page can rank naturally over timeâthis also helps AI engines find relevant context to surface.
Paid search: Twilio, Stripe, Deepgram do it for âSMS API,â âpayment gateway,â âspeech recognition.â The ad links to a targeted landing page or direct docs.
YouTube: If devs watch a âHow to set up webhooksâ tutorial, your brand can surface either via an organic mention (if you produce your own tutorial) or a short ad showing your quick integration.
Explain real use cases: Donât just say âWeâre fast.â Show them itâs not fluffâtwo lines of code to do X.
AI chat engines: ChatGPT and other AI chats increasingly reference popular, well-documented APIs. If your docs and blog posts rank well and get shared, AI models are more likely to âknowâ about your product and mention it. Also a bigger article on this coming up ;)
GitHub search
A surprising number of devs literally type âX sample codeâ into GitHub or rummage through topics. Provide:
SDK repos: obviously you want your SDK repos findable in there.
Sample repos: For your core use cases. A minimal âHello Paymentâ or âHello Shippingâ example in JavaScript, Python, etc.
Open source integrations: If possible, open-source a small library or plugin that extends your API in popular frameworks.
Starred & tagged: Tag your repos with relevant keywords. If a dev stumbles on your code snippet, they might star it, share it, or clone it.
Also, it is surprisingly easy to optimize your repo for GitHub search. You just need to tweak the repo name (if you can), about section, and topics. Wrote about it here.
Social Listening on Reddit, Hacker News, and Slack
Dev communities love to talk about problems and solutions. If someone says âWhat do you use for email verificationâ, or âAlternatives to {BIG INCUMBENT}â thatâs your chance.
Here is a good example of how that could look like.
Developer-First Experience: From Landing to Value
So youâve captured devs attention, maybe through Google, GitHub, or a Reddit thread. Now they land on your site. The question is: how fast can they see you solve their problem (aka the âvalueâ)?
A truly developer-first approach means:
Obvious dev focus: Make it clear this is an API product. If your homepage also speaks to business folks, add a prominent âDevelopersâ link.
Dev portal / docs: Provide quickstarts, reference docs, code samples in a dev-friendly area.
Self-serve: Let them sign up and test with minimal friction.
Transparent Pricing: If you have usage-based or free tiers, show them.
The goal is to get that time to the first API call or âtime to Hello Worldâ in minutes. Twilioâs dev-centric vibe (docs, usage-based pricing, free credits) made them the go-to for SMS. Reduce friction, devs adopt your API.
You want to measure both the conversion rate and velocity of that event. If it is longer than a reasonable-lenght single playing session on a Sunday evenining it is not good enough.
If you are thinking about those core activation/setup events you may want to read this âclassicâ on activation/engagement from PLGeek.
Friction Log
A great way to improve that conversion rate and review that your first dev journey is great is running friction logs.
I wrote an article (and added a doc/framework) in this âHow to create and audit your core developer journeyâ.
But this is not my idea, heard/read about this independently from Ben Williams (ex Snyk) on PLGeek and David Nunez (ex Stripe) in this podcast:
The idea is to literally record yourself (or others) going from Google (or homepage) to the first API call, narrating each step. This will show you what works and doesn't. You'll be surprised how many things are "crazy bad" and "obviously wront" btw ;).
Docs and holistic developer experience
A big chunk of that (hopefully) amazing developer journey happens in the docs and around. Devs want to solve their problem fast. You canât just capture demand; you must keep them engaged so they integrate your API. Think âtime to first API call.â
Documentation
Clear structure: Group endpoints logically, use sidebars/search. Cover 4 types of docs How-to/Tutorials/Reference/Concepts
Language toggles and quickstarts: Provide minimal code for Node, Python, Go, etc. The best docs (Stripe, Twilio) let devs copy-paste a lot including injecting credentials for logged-in users.
Doc Generation: Tools like Scalar or Mintify can produce docs from your OpenAPI spec, letting you add human-friendly guides.
Short âHow-toâ guides focused on specific problems are key. You want to help people get to why they came here in the first place (âSend your first SMS,â âProcess your first payment,â or âConfigure your first shipping label.â)
Conversion Tip: Insert sign-up or âGet API Keyâ CTAs in docs. Devs reading docs are warm leads.
The last one is a cool story coming from the GOAT of all docs. They added a âCreate accountâ button to their docs
SDKs
It is one of those problems that seem simple but are hard to solve. You want idiomatic SDKs instead of devs consuming APIs to write their own to speed up adoption, but you cannot create and maintain them without a team, but if you donât put those resources then those SDKs will be bad, so you donât do SDKs. Now it seems that tools for that got so much better.
Auto-generated SDKs: Tools like Stainless or APIMatic convert specs into typed libraries. Then a dev-rel can refine them.
Idiomatic: A Node dev expects certain patterns, a Python dev expects other stuff. Making it feel ânativeâ makes a big difference.
Stay in sync: Keep your library versions aligned with docs.
Interactive Sandboxes / Playgrounds
You want devs to play with it, even before they install anything or instead of that. You can jump over the setup problems and help people see how it feels.
Deepgram playground is a fantastic example. I talk about it in this video but jus check it out for yourself. In 2min you can get a sense of how powerful this product is. No signup needed.
Flexible, Transparent Pricing
Devs need to gauge cost quicklyâespecially for early proof-of-concept.
Free Tier: you want devs to see for themselves with low commitment. The goal of this tier is deliver promised value to a single dev.
Usage-Based: â$x per thousand requests.â If devs can scale gradually, theyâll likely stay. Often that middle tier will have some collaboration sprinkle as the focus is on providing value to a single team.
Enterprise: Big orgs want custom SLAs, advanced security, or dedicated support. And may need high-volume, and custom deals on that. So they âTalk to salesâ.
If you hide pricing, devs assume itâs expensive. If you donât give them a free tier it kills self-served adoption (or at least awareness).
I like how Resend does/did their pricing it:
Launch Weeks: More Bang for Your Release Buck
You may ship small updates constantly (bug fixes, minor features). But if you quietly release them, you get minimal marketing impact. But you donât need to couple Release and Launch which letâs you decide what and how you show to the world. Launch Weeks (popularized by Supabase) fix that.

How it works:
Batch Minor Updates: Group them into a single âlaunchâ window, like a week.
Daily Reveals: Announce a new feature or improvement each day.
Build Hype: On social media, dev forums, or your newsletter, highlight each dayâs launch.
Why it works:
Visibility: Multiple mini-launches keep devs talking.
Momentum: People see rapid evolution, even if itâs just aggregated from weeks of work.
Supabase Example: They post âLaunch Weekâ articles, daily streams, tweetsâfostering community discussion.
Releasing vs. Launching: You can release features any time, but launching them all at once amplifies the effect.
Launch Weeks became a go-to model for dev tools wanting to energize their user base.
Developer Influencers
Influencer marketing for devs might seem odd, but itâs increasingly common. The idea is simple, you pay people with a following in he dev niche you are going after to âpitchâ your product. The key is authenticity.
Integrate, donât pitch: If you sponsor a tutorial channel, they shouldnât just recite a sales script. Your API ideally should show up as a part of a bigger example. Then it feels useful not promotional.
Sponsored segments: Another route is to place a sponsor portion mid-video or at the end, with a unique link/code to track signups.
Long-term partnerships: Some channels do ongoing series, so your API can show up repeatedly.
Bottom line: If dev watchers trust the influencer, they trust your API can solve a real problem. Keep it organicâdevs smell forced marketing from a mile away.
Clerk & Hypergrowth Partners wrote a detailed post on dev influencer marketing:
They talk about picking the right creators, structuring deals, and staying useful, not pushy. This post is a goldmine really, so read that (I shared a few of my takeaways here).
Also, there are products like plug.dev that help scale those motions by dealing with sourcing dev influencers, logistics of contracts etc. It is especially helpful when you go for many microinflueners.
Summary
If your API solves a real pain, focus on capturing that existing demand. Show up in dev searches, maintain a GitHub presence, and do social listening. Then adopt a developer-first approach:
A straightforward homepage & dev portal.
Minimal friction to the first API call.
Usage-based pricing so devs can experiment.
Launch Weeks & influencer tutorials for extra awareness.
Devs donât mind boring as long as it useful. Dev tools that differentiate by âIt just worksâ and âthat donât suckâ seem to be surprisingly common.
Need more developer marketing insights?
1. Work with me đ
"You helped us land messaging that clearly states the problem and solution in the words our champions actually use. The homepage is super crisp now."
If you want my help I do Workshops (60-minute session on whatever you want), Teardowns (audit+suggestions for your homepage, messaging, ads etc), and longer-term Advising.
2. Bonus links to check out
3. Join our Slack community
"Been here 20 min and already folks are sharing great advice."
2200+ dev tool CMOs, heads of growth, product marketers, and other practitioners talking shop.
What did you think of this issue? |
Reply