There is no "documentation". Instead, there are
Reference: This includes both the public REST API and the library API.
Examples: These are short, heavily annotated, working programs that show how to use aspects of the APIs. They are easier to create than tutorials.
Tutorials: These are stepwise guides to the APIs. These are aimed at developers and testers new to the APIs, or APIs that are difficult to understand.
Operation: These detail the deployment of the product and its supporting tools (monitors, logging, alerts, etc).
Question and Answer Knowledge base: This is an ongoing collection of questions and answers from staff.
What is missing from this list are the aspirational and functional design documents. Both are important at the early stages of development (and, sometimes, for bringing on senior staff) but they represent the plan and not the outcome. Maintaining them, even with "as built" annotations, is rarely done and so they cause confusion instead of aid understanding. Consider them ephemeral.
Few organizations can afford to create and maintain all these kinds of documents. Pick the ones that have vitality in your daily work. For example, if you are hiring or have a less experienced staff then focus on tutorials, examples, and Q&A; if you have a growing customer base then focus on operations and Q&A.
Update: See The Grand Unified Theory of Documentation.