---
title: "Run a WP-CLI command against a space"
method: POST
path: "/v1/spaces/{spaceId}/wp-cli"
tags: ["Spaces"]
---

# Run a WP-CLI command against a space

`POST /v1/spaces/{spaceId}/wp-cli`

## Request

- Base URL: `https://api.spacefast.com`
- URL: `https://api.spacefast.com/v1/spaces/{spaceId}/wp-cli`
- Auth: one of:
  - HTTP bearer
  - HTTP bearer

Runs one `wp` command against the space's own WordPress and waits for it to finish. This is the escape hatch beneath the named surfaces: anything WP-CLI can do that Spacefast has not given its own route. `args` is an already-split argument vector (`["option", "get", "blogname"]`), relayed verbatim — no shell parses it, so nothing re-splits or re-globs what you send. Requires write access to the space, because a `wp` command has unrestricted authority over the site's data, and every run is written to the space's activity trail. Note that the provider runs this as a job and reports only whether WP-CLI exited zero: `output` is null because the runtime exposes no channel carrying the command's own stdout.

## Path parameters

- `spaceId` string, required

## Request body

- object
  - `args` string[], required
  - `mode` 'full' | 'limited'

## Response `200`

Response for status 200

- object
  - `$schema` string, uri: Canonical JSON Schema URL for this response body. The server also sends it in the `Link: rel="describedby"` response header.
  - `data` object, required
    - `taskId` integer, required
    - `status` 'succeeded' | 'failed', required
    - `args` string[], required
    - `mode` 'full' | 'limited', required
    - `tookMs` integer, nullable, required
    - `output` string, nullable, required

## Other responses

- `default`: Problem details (RFC 9457). Any 4xx/5xx response is one `application/problem+json` document.

---

[API](https://skmtc.dev/spacefast/apis/spacefast-api.md) · [All operations](https://skmtc.dev/spacefast/apis/spacefast-api/llms.txt) · [OpenAPI document](https://skmtc.dev/spacefast/apis/spacefast-api/revisions/bd165bc7c983?raw)