Blogs

The blog is the beating heart of API evangelism, and I say that as someone whose entire career is a blog. API Evangelist is fundamentally a blog — fifteen years of near-daily writing about the API space — and everything else I do radiates out from that writing practice. So when I talk about blogs as an evangelism channel, I’m not speaking theoretically. I’m describing the single most important thing I’ve done professionally, the discipline that built my career, supported my family, and let me make sense of an entire industry. The blog is not a marketing afterthought. It is the engine.

For an API provider, the blog is the number one signal I use to evaluate the health of an API. I’ve said this many times and meant it literally: when I land on an API and want to know whether anyone is home, I look at the blog. A fresh, active, frequently updated blog tells me there are people behind the platform who care, who are building, who are communicating. A blog that hasn’t been touched in six months or a year tells me the opposite, and I step away. I wrote as far back as 2012 that the most damaging thing you can do is stop posting to your blog, because blog silence speaks volumes about what’s happening behind the curtain. The blog’s freshness is a canary in the coal mine for the whole operation. An out-of-date blog is often the clearest early sign that an API is heading toward deprecation — the communication goes quiet before the lights go out.

This is why the blog belongs in the minimum viable footprint of any serious API. It’s not a nice-to-have layered on top of the documentation and the portal; it’s a core building block. The blog is where you build awareness of your API, keep your developers informed, and give a personality and a human voice to the team behind the platform. Documentation tells developers how the API works. The blog tells them the API is alive, that it’s evolving, that there are people thinking about it and improving it. Those are different jobs, and you need both.

The deeper truth about blogging, though — the thing I understand from the inside — is that the blog is a thinking tool before it’s a publishing tool. Most people assume my blog is for them, the reader, and it is, but first and foremost it’s for me, working through my own ideas and projects. I’ve described about 75% of what I publish as workbench blogging: telling the story of whatever I’m working on that day, scribbling on my workbench in public. The short-form posts are just exhaust from the machine operating each day. I’m not writing them for page views or attention — I’m publishing to my workbench, which is why some of them are rough and not fully fleshed out. Writing is how I process. A thought, for me, isn’t fully formed until it’s published. The act of writing it down, organizing it into sentences, and putting it where someone might read it is what turns a vague notion into something coherent. Writing makes me more coherent. It helps me find the signal in the noise. Without it, I stop being curious, I stop being thoughtful, and I get lost in the chaos of the technology cycle.

That personal practice has a scale to it that matters. I’ve published three to five posts every weekday for years — thousands of posts across the life of the project. And the volume isn’t vanity; it’s a metric I watch like a vital sign. There was a period in 2013, during a fellowship in DC, when I felt myself losing my storytelling voice, and I could see it in the numbers: sixty-one posts in July, forty-one in August, twenty-one in September. The decline of my writing was the decline of my thinking and my perspective on the space. I learned to treat my own blogging voice as a canary — if a project or a job is diminishing my voice, I need to stop and look hard at what it’s costing me. The recovery showed up in the numbers too, climbing back to twenty-eight and twenty-seven posts in the following months. The writing and the wellbeing are linked for me in a way I can measure.

Blogging out in the open also creates a feedback loop you can’t get any other way. When you think through a problem publicly on your blog — an API design question, a roadmap decision, an architectural choice — you invite the community into your reasoning, and they reason back. I pointed to Dropbox’s Steve Marx blogging through a question as basic as how many HTTP status codes an API should use, working it out in public. Talking things through on your blog teaches you to think outside your own head and lets the sunlight in on your thoughts. Over time that produces momentum, and momentum produces what I call exhaust — a trail of valuable, searchable, linkable thinking that attracts the right people to your platform. That’s the actual mechanism of blog-driven evangelism: interesting projects, told as stories, syndicated widely, generating exhaust that pulls developers in.

Storytelling is the heart of all of it, and storytelling is what the blog is for. After studying hundreds of the most successful APIs, the one pattern that consistently emerged wasn’t technical — it was storytelling. Amazon, Twitter, Twilio, Netflix: what they shared was that stories were told about how their APIs were being used. It does not matter how solid your technology is; without stories, your platform won’t matter now or in the future. Daniel Jacobson at Netflix described their storytelling not as a PR stunt but as a genuine desire to share how their operations worked, successes and failures alike — and noted that anticipating you’ll share something publicly forces you to see it in a different, clearer light. The blog is where those stories live. An API without a storytelling practice is an API nobody will ever hear about.

I’m also adamant that the blog has to be owned media, on your own domain, not rented space on someone else’s platform. I’ve watched people pour their energy into tweeting and posting on social platforms while neglecting a blog they actually control, and it pains me, because they’re handing all that value and audience to Twitter, Medium, LinkedIn — companies that monetize your activity and hard work. Every platform wants you generating content inside its walls because that’s how it makes money off you. RSS from your blog, at your domain, strengthens your brand and keeps you in control of your own syndication and distribution. I’ve argued plainly that your blog and its RSS feed should be your primary content channel, and that Twitter, Facebook, and the rest should come after — POSSE, publish on your own site, syndicate elsewhere. When API providers moved their blogs onto Medium, I pushed back: no domain mapping, no real RSS, your valuable exhaust trapped in someone else’s neatly tended, gated garden. Use WordPress, Jekyll, Blogger, anything you can map to your own subdomain, and keep the value where it belongs. If you expect to make a living from your brand, you need to maximize control over the licensing and distribution of your content, and the blog on your own domain is how you do that.

Fifteen years in, I still believe in this more than almost anything else in the evangelism toolkit, even as blogging and RSS have fallen out of fashion and the open web has been hollowed out by the platforms. Looking back at my first post on the API economy in 2010, a lot has changed — money and power have corrupted much of what made the early API space humane — but the value of writing has not. The blog remains the most honest, most durable, most fully-owned channel an API program can have. It’s where you think, where you tell your stories, where you signal that you’re alive, and where you build the searchable record of your work that compounds over years. Everything else in evangelism — the social posts, the talks, the newsletters, the videos — is downstream of the writing. Get the blog right, keep it alive, write in your own voice on your own domain, and the rest of the evangelism engine has something real to run on.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

Blogs

References

Guidance Details

Explore more

Discover APIs