d360

The official Document360 command-line interface.

Use d360 to manage Document360 from your terminal, automation scripts, and CI/CD pipelines. Create and publish content, work with projects and workspaces, manage users and access, retrieve analytics, organize Drive assets, maintain API references, and more—without leaving your command line.

Why use d360?

• Automate repetitive work: Turn recurring portal tasks into repeatable commands and scripts.
• Manage content at scale: Create, update, publish, and bulk-manage articles and categories.
• Build reliable workflows: Use the CLI in deployment pipelines, scheduled jobs, and internal tools.
• Work across projects: Save project-specific defaults and switch between named profiles when managing multiple Document360 projects.
• Get script-friendly results: Control output, filtering, timeouts, and diagnostic detail with global options.

d360 v3 includes 191 commands across 42 command groups, in addition to setup, configuration, diagnostics, and backward-compatible V2 API documentation commands.

Common use cases

Automate content operations

Create articles and categories, apply labels, manage versions, update workflow status, and publish content from a script or pipeline. Bulk commands help teams handle larger content operations consistently.

Publish documentation with a release

Add d360 commands to a release workflow so approved articles, categories, or API references go live alongside the product changes they describe.

Build documentation reports

Retrieve article, search, feedback, and AI search analytics for dashboards or scheduled reports. Find top content, no-result searches, trending topics, and other signals that help improve your knowledge base.

Manage users and protected content

Automate user and reader onboarding, maintain groups and roles, and manage content-access rules across projects and workspaces.

Organize reusable content and assets

Manage snippets, variables, glossary entries, labels, tags, Drive folders, and files from repeatable scripts.

Work across multiple projects

Create a named profile for each Document360 project. Switch profiles instead of repeatedly supplying the same project, workspace, and language details.

Manage API references

Use the V3 api-references commands to import, resync, publish, delete, and inspect logs for API references. The earlier apidocs commands remain available for backward compatibility with V2 workflows.

Requirements

• Node.js 18 or later
• A Document360 account and API key with permission to perform the required operations

Install

Install d360 globally from npm:

npm install -g d360

Confirm that the CLI is available:

d360 --help

Quick start

Run the guided setup:

d360 init

d360 init helps you select a region, save your API key, choose default project, workspace, and language values, and verify the connection.

After setup, try a few read-only commands:

d360 projects list
d360 workspaces list
d360 articles get --article-id=<ARTICLE_ID>
d360 analytics articles top

If something is not configured correctly, run:

d360 doctor

This checks the Node.js installation, executable path, active profile, API key, API host, command manifest, and connectivity.

Authentication

V3 commands and the backward-compatible V2 API documentation commands use different credentials. They are not interchangeable.

V3 commands

Commands such as d360 articles, d360 projects, d360 users, and d360 analytics use a Document360 public API key, normally beginning with d360_sk_.

Configure it interactively:

d360 init

Or save it directly:

d360 config set-key <API_KEY>

For CI/CD, you can supply the key at runtime with the global --api-key option:

d360 projects list --api-key="$DOCUMENT360_API_KEY"

V2 API documentation commands

The following commands are retained for backward compatibility with V2 API documentation workflows. They use the project API token included in the prefilled CLI command in the Document360 portal:

• d360 apidocs
• d360 apidocs:resync
• d360 apidocs:validate

Get the prefilled command from API documentation > Create > New API > CI/CD Flow. These commands use --apiKey and do not use a d360_sk_ key. New V3 integrations should use the api-references command group.

Important: Store both credential types securely. Do not commit API keys or prefilled portal commands containing credentials to source control.

How commands are organized

Most commands follow this structure:

d360 <group> [subgroup] <action> [options]

Examples:

d360 articles get --article-id=<ARTICLE_ID>
d360 articles versions list --article-id=<ARTICLE_ID>
d360 articles publishing-workflow publish \
  --article-id=<ARTICLE_ID> \
  --workspace-id=<WORKSPACE_ID> \
  --version-number=<VERSION_NUMBER>
d360 drive folders list
d360 users groups list

Explore the available commands at any level:

d360 --help
d360 articles --help
d360 articles versions --help
d360 articles versions list --help

The complete command reference also ships with the package as docs/COMMANDS.md (for a global install: $(npm root -g)/d360/docs/COMMANDS.md).

Major command areas

| Area | What you can do | Example | | --- | --- | --- | | Projects and workspaces | List projects, inspect workspaces, search content, and manage imports or exports. | d360 projects list | | Articles | Create, retrieve, update, delete, bulk-manage, publish, and manage versions or attachments. | d360 articles get --article-id=<ID> | | Categories | Create and organize categories, update page content, manage versions, and publish. | d360 categories get --category-id=<ID> | | API references | Import, resync, publish, delete, and inspect API reference logs. | d360 api-references logs list --api-reference-id=<ID> | | Analytics | Retrieve article, feedback, search, and AI search analytics. | d360 analytics search no-results | | AI search | Run workspace AI queries, submit feedback, and inspect AI search trends. | d360 workspaces ai query --query="..." --workspace-id=<ID> | | Users and groups | Create and manage users, groups, roles, and permissions. | d360 users list | | Readers and reader groups | Manage readers and access groups for protected content. | d360 readers list | | Content access | Grant, deny, remove, or inspect content permissions and site protection. | d360 content-access permissions | | Reusable content | Manage snippets, variables, and glossary entries. | d360 content-reuse snippets list | | Drive | Search Drive and manage files, folders, tags, and article assets. | d360 drive folders list | | Templates and metadata | Work with article templates, labels, tags, custom fields, languages, and translations. | d360 article-templates list | | Redirects | Create and maintain redirection rules. | d360 redirect-rules list | | Operations | Track asynchronous Document360 operations. | d360 operations list | | AI writer style guides | List or retrieve configured AI writer style guides. | d360 ai-writer-style-guides list |

Practical examples

Create and publish an article

Create an article:

d360 articles create \
  --title="Getting started" \
  --category-id=<CATEGORY_ID> \
  --workspace-id=<WORKSPACE_ID>

Publish a specific version after it is ready:

d360 articles publishing-workflow publish \
  --article-id=<ARTICLE_ID> \
  --workspace-id=<WORKSPACE_ID> \
  --version-number=<VERSION_NUMBER>

Find opportunities to improve search

d360 analytics search keywords
d360 analytics search no-results
d360 analytics ai-search trending-topics

Manage readers

d360 readers list
d360 readers groups list

Work with Drive

d360 drive folders list
d360 drive search
d360 drive files get --folder-id=<FOLDER_ID> --file-id=<FILE_ID>

Manage redirects

d360 redirect-rules create \
  --source="/old-page" \
  --target="/new-page"

Projects, profiles, and defaults

Profiles let you keep separate settings for different Document360 projects.

d360 config add-profile project-a
d360 config use project-a
d360 config set-project-id <PROJECT_ID>
d360 config set-workspace-id <WORKSPACE_ID>
d360 config set-language en
d360 config show

Create and switch to another profile when needed:

d360 config add-profile project-b
d360 config use project-b

You can also save defaults for parameters used across multiple commands:

d360 config set-default workspace-id <WORKSPACE_ID>
d360 config list-defaults
d360 config unset-default workspace-id

To see the active configuration and resolved values:

d360 config show

Global options

Every V3 command accepts these global options:

| Option | Purpose | | --- | --- | | --api-key | Supply the public API key for the current command. | | --project-id | Override the configured default project. | | --output | Select the output format. | | --filter | Filter the returned output. | | --full | Request the complete output. | | --timeout | Set the request timeout. | | --verbose | Show additional execution detail. | | --debug | Show diagnostic detail for troubleshooting. |

The --project-id option is usually unnecessary after setting a default with:

d360 config set-project-id <PROJECT_ID>

API reference workflows

V3 API reference commands

V3 uses the api-references command group:

d360 api-references import \
  --workspace-id=<WORKSPACE_ID>

d360 api-references resync \
  --api-reference-id=<API_REFERENCE_ID> \
  --url=https://example.com/openapi.yaml

d360 api-references publish \
  --api-reference-id=<API_REFERENCE_ID> \
  --workspace-id=<WORKSPACE_ID>

You can also delete an API reference or inspect its import and resync logs:

d360 api-references logs list \
  --api-reference-id=<API_REFERENCE_ID>

Import or resync on the background worker

A large specification expands to several gigabytes while it is parsed, so the import and resync can run on a background worker instead of inside the request. d360 apiref submit starts one and reports the operation to poll:

# Import a new API reference into a workspace
d360 apiref submit --workspace-id=<WORKSPACE_ID> --file=./openapi.json

# Resync an existing one from a URL, and block until it finishes
d360 apiref submit --api-reference-id=<API_REFERENCE_ID> \
  --url=https://api.example.com/openapi.json \
  --wait

Supply exactly one of --file (uploaded as multipart/form-data) or --url, and exactly one of --workspace-id (import) or --api-reference-id (resync).

| Option | Meaning | | --- | --- | | --workspace-id | Import a new API reference into this workspace | | --api-reference-id | Resync this existing API reference | | --file / --url | The specification, uploaded or fetched | | --publish-articles | Publish the generated articles after import | | --user-id | The team member to publish as — required with --publish-articles | | --force-import | Import even if the spec produced warnings, or removes endpoints | | --wait | Block until the operation finishes, and exit on its outcome |

Without --wait it prints the operation record and returns immediately; poll it yourself with d360 operations wait <operation-id>.

--user-id is required with --publish-articles because publishing runs as a specific team member. Without one the articles are imported but never published, and the operation still reports success.

A project may have only one import or resync open at a time. A second, different request while one is running is refused with 409; re-submitting an identical one returns the operation already running rather than starting a second.

apiref submit is written by hand against routes that are not yet in the published API specification, so that they can be exercised before they ship. The in-request apiref import and apiref resync commands are unchanged and still work.

Waiting for a background operation

Some V3 endpoints accept the work and return 202 Accepted with an operation id rather than doing it inline. d360 operations wait polls one of those until it finishes and exits on its outcome, so a pipeline can block on it:

d360 operations wait <OPERATION_ID>

It exits 0 when the operation succeeded and 1 when it failed, was cancelled, or only partially succeeded. Running out of the wait budget also exits 1 — and says so explicitly, because the operation keeps running on the server; waiting stopped, the work did not.

Compose it with any command that returns an operation id:

id=$(d360 apiref submit --workspace-id=<WORKSPACE_ID> --file ./openapi.json \
       --filter operation_id -o tsv)
d360 operations wait "$id"

d360 operations get --operation-id=<OPERATION_ID> reads the same record once, without waiting.

Coming change to api-references import and api-references resync. Both currently run inside the request. Server-side they are being replaced by background routes that return an operation id, and the two in-request routes are deprecated but still published in the API specification. An earlier plan hid them; that was reversed precisely because this CLI generates its V3 commands from that specification, so hiding them would have deleted apiref import and apiref resync from the next release rather than deprecating them. They stay, marked deprecated, and d360 apiref submit above is the replacement. Existing scripts keep working; no removal date has been announced.

V2 backward compatibility

The apidocs command family remains available for customers with existing V2 API documentation workflows. It supports API definition import, validation, resync, optional publishing, and — through apidocs:submit and apidocs:status — submitting an import or resync to the background worker.

apidocs and apidocs:resync are deprecated. They hold one HTTP request open for the whole import, which is what fails on a large specification. Use apidocs:submit to start the work and apidocs:status to read the result; both reach the same V2 routes through the background worker. The deprecated pair still works, and no removal date has been announced — the marking is there so new automation is not written against them. apidocs:validate is not deprecated.

Validate an API definition

d360 apidocs:validate \
  --apiKey="$DOCUMENT360_APIDOCS_KEY" \
  --path=./openapi.yaml

Create an API reference

d360 apidocs \
  --apiKey="$DOCUMENT360_APIDOCS_KEY" \
  --userId="$DOCUMENT360_USER_ID" \
  --versionId="$DOCUMENT360_VERSION_ID" \
  --path=./openapi.yaml \
  --publish

Resync an API reference

d360 apidocs:resync \
  --apiKey="$DOCUMENT360_APIDOCS_KEY" \
  --userId="$DOCUMENT360_USER_ID" \
  --apiReferenceId="$DOCUMENT360_API_REFERENCE_ID" \
  --path=./openapi.yaml \
  --publish

--path accepts one local file or hosted URL at a time. For multiple API definitions, run one command per API reference.

Run an import or resync in the background

A large specification is parsed by a background worker rather than inside the request, so the command does not have to hold a connection open for it. Two commands opt into that. d360 apidocs and d360 apidocs:resync are unchanged and still run the operation synchronously — nothing above this section behaves differently.

d360 apidocs:submit \
  --apiKey="$DOCUMENT360_APIDOCS_KEY" \
  --userId="$DOCUMENT360_USER_ID" \
  --versionId="$DOCUMENT360_VERSION_ID" \
  --path=./openapi.yaml \
  --publish

apidocs:submit prints the background task id and exits at once. Pass --apiReferenceId instead of --versionId to submit a resync rather than an import. Every other flag is the one d360 apidocs uses.

d360 apidocs:status <task-id>
d360 apidocs:status <task-id> --wait

A job that is still running exits 0. A finished one prints the alerts, errors and deleted endpoints its operation produced, and exits non-zero if it failed — so --wait, which polls until the job finishes, is what a pipeline should gate on.

The deleted-endpoints table is labelled with which of the two cases it is: Deleted endpoints when the operation ran and removed them, Would delete (not applied) when it was refused and removed nothing. It is capped at 25 rows, followed by a ... +N more line, and — unlike the table d360 apidocs:resync prints — it goes to stderr. --wait gives up after 20 minutes and prints the task id; the job itself is not cancelled, and apidocs:status can be run again at any time.

A project runs one import or resync at a time. If another one is already running, apidocs:submit stops and tells you the id of the job to wait for.

If the Document360 instance is older than these endpoints, both commands say so and do nothing. Use d360 apidocs and d360 apidocs:resync there.

Troubleshooting

Start with the built-in diagnostic command:

d360 doctor

For additional detail, add --verbose or --debug to the command you are troubleshooting.

If the CLI is installed but d360 is not found, ensure the global npm binary directory is included in your PATH.

Security recommendations

• Store API keys in a secret manager or your CI/CD platform's encrypted secret store.
• Do not commit keys, configuration files containing keys, or prefilled portal commands to source control.
• Use a key with only the permissions required by the automation.
• Use named profiles to avoid accidentally running a command against the wrong project.
• Review destructive operations such as delete, bulk delete, unpublish, and access changes before running them.

Support

If you need help installing or using d360, contact Document360 Support at [email protected].

License

MIT