Introduction

Document360 Customer API 2.0.0

Document360 RESTful APIs let you integrate your documentation with your software — onboard readers, manage articles, automate publishing, and more.

Authentication

Every request must include your API token in the api_token header. Generate tokens in the Document360 portal under Settings > Knowledge base portal > API tokens. Tokens are project-scoped and can be revoked at any time.

If your client cannot set custom headers, you can pass the same token in the api_token query string instead — but the header form is strongly preferred.

Project context

Many endpoints implicitly resolve the project from the API token. When an endpoint requires explicit project context, pass the project identifier in the ProjectId header.

Identifiers — how to fetch them

Most endpoints accept one or more identifiers as path, query, or body parameters. Instead of hard-coding values, use the discovery endpoints below to look them up programmatically:

Tip: In the Document360 portal, article and category IDs are visible in the URL when an item is open in the editor — for example, …/docs/<articleId>/edit/<langCode>. You can find the projectId under Settings → API tokens and the projectVersionId under Documentation → Workspaces.

Query parameter casing

V1 and V2 query parameters use snake_case on the wire — for example, search_email, exclude_readers, and version_number. The server transparently maps snake_case query keys to the camelCase parameter names shown in this specification, so either casing is accepted. However, snake_case is the documented convention for V1/V2.

Response envelope

All responses are wrapped in a consistent envelope:

• success (boolean) — true when the operation succeeded, false otherwise. Always check this before reading the payload.
• errors (array) — populated when success is false. Each entry includes a human-readable description.
• warnings / information (arrays) — non-fatal advisories returned alongside a successful response.
• result or data — the operation's payload (the property name depends on the endpoint).

HTTP status codes follow standard semantics: 200 success, 400 validation or business error, 401 missing or invalid token, 403 plan or permission restriction, 404 not found, 429 rate-limited, and 5xx server error. The envelope applies to non-200 responses as well — inspect errors[].description for details.

Rate limits

Endpoints are rate-limited per API token, per project. When a request is throttled, the server returns 429 Too Many Requests along with the Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers. Honor the Retry-After value, and retry using exponential backoff with jitter.

Versioning

All routes are prefixed with the API version: /v1/... and /v2/.... V1 and V2 are stable; V3 is in Beta. In V1 and V2, new endpoints and fields may be added without notice, but existing ones will never be removed or renamed in a backwards-incompatible way.

Servers

Server variables