For python, here's what I use with sphinx-doc: https://libtmux.git-pull.com/en/latest/api.html https://libtmux.git-pull.com/en/latest/api.html https://libvcs.

For python, here's what I use with sphinx-doc: https://libtmux.git-pull.com/en/latest/api.html https://libtmux.git-pull.com/en/latest/api.html https://libvcs.git-pull.com/en/latest/api.html https://libvcs.git-pull.com/en/latest/api.html That is, global + expanded local ToC Section Navigation on the left, and laying out the API docs like python code (parenthesis wrapping parameters). The tool that powers it is sphinx.ext.autodoc (http://www.sphinx-doc.org/en/stable/ext/autodoc.html http://www.sphinx-doc.org/en/stable/ext/autodoc.html). While it's opinionated toward Python, there are tools like Breathe (https://breathe.readthedocs.io/en/latest/ https://breathe.readthedocs.io/en/latest/) that can use doxygen's XML output to generate docs, too. For REST-based API's that can be widdled down to language-library abstractions, I concur with stripe API documentation: https://stripe.com/docs/api https://stripe.com/docs/api In addition, Heroku's platform API documentation is nice: https://devcenter.heroku.com/articles/platform-api-reference https://devcenter.heroku.com/articles/platform-api-reference. Downside is the ToC makes the docs top-heavy. Other points: - I think it's OK to infer readers are going to be using Command/Ctrl-F searches liberally when viewing docs. - For javascript (to augment what's already there), I like annotated source if the library is small enough, e.g. http://backbonejs.org/docs/backbone.html http://backbonejs.org/docs/backbone.html