---
title: "Upcoming presentation in downtown San Francisco: Publishing strategies for API documentation"
date: 2014-09-02
description: "$( document ).ready(function() { // Handler for .ready() called. $('#toc').toc({ minimumHeaders: 3, listType: 'ul', showSpeed: 0, headers: '#content h2, #content h3, #content h4, #content h5, #content h6' }); /*..."
canonical_url: https://idratherbewriting.com/2014/09/02/upcoming-presentation-publishing-strategies-api-documentation/index.html
---

> For AI agents: a documentation index is available at https://idratherbewriting.com/llms.txt. Markdown versions of all pages are available by appending .md to any page URL.

# Upcoming presentation in downtown San Francisco: Publishing strategies for API documentation

*10/15/2014 update: For the slides and recording, see [this post](https://idratherbewriting.com/2014/10/16/api-doc-presentation-slides-and-recording/).
*
I'm giving the following presentation to the San Francisco STC Chapter on October 15:

## Publishing strategies for API documentation

Most of the common tools for publishing help material fall short when it comes to API documentation. Much API documentation (such as for Java, C++, or .NET APIs) is generated from comments in the source code. Their outputs don't usually integrate with other help material, such as programming tutorials or scenario-based code samples.

REST APIs are a breed of their own, with almost no standard tools for generating documentation from the source. The variety of outputs for REST APIs are as diverse as the APIs themselves, as you can see by browsing the 11,000+ web APIs on [programmableweb.com](http://www.programmableweb.com/apis/directory).

As a technical writer, what publishing strategies do you use for API documentation? Do you leave the reference material separate from the tutorials and code samples? Do you convert everything to DITA and merge it into a single output? Do you build your own help system from scratch that imports your REST API information?

There's not a one-size-fits-all approach. In this presentation, you'll learn a variety of publishing strategies for different kinds of APIs, with examples of what works well for developer audiences. No matter what kind of API you're working with, you'll benefit from this survey of the API doc publishing scene.

## Presentation Details

**Group:** [San Francisco STC Chapter](http://www.stc-sf.org/)
**Location:** Hub SoMa at 901 Mission St, Ste 105, between 5th and 6th Streets
**Date:** Wednesday, October 15
**Time:** 6-7pm (networking); 7-8pm (presentation)
**Cost:** Members, $15; Non-members, $20; Students/first timers*, $10. Tickets are available at the door.

![missionstreet](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/missionstreet.png)

## About Tom Johnson

![tom_johnson_picture2](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/tom_johnson_picture2.png)Tom Johnson is a senior technical writer for the 41st Parameter, a company in the fraud detection and advertising technology space. Tom's blog, I'd Rather Be Writing ([idratherbewriting.com](https://idratherbewriting.com/)), is a hub for innovation and exploration in the tech comm field.

Tom recently guest edited an issue of the STC Intercom (September 2014 issue) that focused entirely on API documentation. In his current role, he provides documentation for Java, C++, and .NET APIs, in addition to other developer documentation. In a previous company, he worked on documentation for a REST API and JavaScript SDK.

Tom lives in San Jose, bikes to work, and has four girls. You can contact him at (email address hidden).

Note: This presentation will be recorded and posted here for those who can't make it to San Francisco.