Do you need to know how to code to write API documentation?

Documenting an API is complex and it's easy to get distracted by small details. Let's think about a smaller example first.

Imagine you work at a veterinary office and your boss asks you to write a comprehensive owner's manual for cat ownership. You've never owned a cat. Can you do it?

Think about it. Maybe you'd gather some requirements by interviewing cat owners and learning what they need to know. For the hard data, you consult with cat experts and read the existing cat books. You might even spend some time with an actual cat and figure things out firsthand. Someone with cat experience might do the research faster. But the job is absolutely doable, and well, by someone who isn't a cat person.

Writing API documentation works the same way. You don't need to be a software engineer. But the more technical context you bring, the better your documentation will be, and there's a meaningful difference between the technical context that actually helps and the kind that interview prep culture would have you believe matters.

What you actually need

So what does useful technical context actually look like for an API documentation writer? Let me give you a concrete example from my career.

When a computer makes a request to an API, the request includes one of four special verbs: GET, POST, PUT/PATCH, DELETE. The API uses that verb to decide what code to run. Usually, POST creates new things and PUT updates them.

Part of my job was to review documentation submitted by a subcontractor. Most of the time it needed to be updated to follow our company's style guide. While I was updating, I liked to skim the technical details. On one occasion, I noticed they had implemented a few endpoints that created records using PUT. I thought that was peculiar. I knew that sometimes product workflows use PUT, so I double checked comparable modules and saw they all used POST.

If the contractor used PUT, one module would behave inconsistently with the rest of the API. I flagged this in my review and reached out to the engineering manager.

"Hey, the contractor is using a PUT endpoint for creating new records. Since that's non-standard, we should call it out in docs. Is there a reason why?"

The manager got back to me a few hours later:

"Hm. I'll reach out to the contractor. Go ahead and put the ticket on hold for now."

When the engineering manager said "Hm." in his Slack communications, that was usually a sign he ...wasn't happy. I later found out there were quality issues at the contractor that went beyond just this. By catching the problem early and raising it up the chain, I stopped it from ever getting close to production.

The HTTP verb story is a small example of a much broader principle. API documentation touches on a lot of technical territory, and in each of those areas, conceptual fluency pays dividends.

Authentication is where most API integrations break down. Documentation that fails to explain authentication well causes a lot of frustration for developers. Asking good questions is critical: what headers are required? What happens when a token expires? What should a developer do when they get a 401 error code? A writer who doesn't know to ask those questions will be relying on a developer to remember to explain those cases.

The same logic applies across error handling, security, and data formats. These aren't areas where you need deep implementation knowledge. They're areas where knowing enough to ask the right questions, and to recognize when an answer doesn't quite make sense, makes you valuable. Developers will trust your documentation.

That's what conceptual fluency actually means in practice. It's not coding ability. It's the ability to ask better questions, and the awareness to know when something smells wrong.

Build something anyway

Before I became a technical writer, I was a software engineer for seven years. That gives me a perspective on conceptual fluency that a lot of technical writers don't have. In particular, I think it's very valuable to go through the process of implementing a webserver and endpoint.

This is a meaningful undertaking. To do it successfully, you would have to learn a little bit about:

• The command line
• Package management
• The client-server model
• JavaScript Object Notation (JSON)
• The HTTP request/response lifecycle
• Environment variables
• How to write a function in a modern language

In my view, this could be learned in a few months of casual study. The key is that you are not learning to code in order to solve arbitrary problems as an engineer might. You are trying to understand one particular technology in depth and achieve a practical result. There can be real structure to the learning that is hard to find in a typical computer science course or developer-focused YouTube video.

If you put in the work, the rewards are great. Not only will you understand how APIs work, but along the way you'll have to consult experts, debug unfamiliar errors, search through documentation, and get comfortable with your computer. These are important technical skills for writers, but the process also gives you a glimpse into the world developers work in. Knowing what it feels like to be stuck on something that "should be simple" will help you produce more valuable documentation.

That level of audience empathy is far more useful than knowing the HTTP error codes by heart or being able to reverse a binary tree.

You need just enough to be dangerous

Being a technical writer doesn't require anywhere near the level of technical sophistication it takes to be a software engineer. You don't need to pass a technical interview. You don't need to know algorithms or data structures. You don't need to have shipped production code or contributed to an open source project.

What you do need is curiosity, persistence, and the willingness to build the conceptual fluency that helps you understand the world of software. The technical knowledge that matters for API documentation is learnable and a lot more approachable than most people fear.

If you're a writer who's been putting off breaking into technical writing because you're worried you're not technical enough, this is your sign to stop waiting. Start by building something small. The rest follows.

If the ideas in this post resonated with you, I'm launching a course that teaches exactly this — the technical skills and professional instincts that working technical writers actually use. Check it out here — founding member pricing is available to early subscribers.