Jutsu API
Jutsu no longer has organization API keys. The Organization → API keys page and the japi_… keys it created were retired in November 2026, and any key created there has stopped working.
To work with Jutsu from an AI agent, such as Claude, Cursor or VS Code, connect it to the Jutsu MCP server. Each person approves their own agent, it acts with their role, and there's no key to store or rotate.
To add hosts and integrations, use Integrations → Data sources in the console.
What remains is narrow: a host or webhook can still manage its own asset with its own key. An uninstall script can archive the host it runs on, and a health check can read the host's status, without opening the console.
The asset's own key
The key is the asset's jcol_… collector token. Every host (Linux, macOS, Windows, Docker) and every webhook you add under Data sources gets one. Jutsu shows it once, inside the install command (JUTSU_TOKEN=jcol_…) or as the webhook's bearer token, and the agent or sender also uses it to ship events. Jutsu stores only a hash, so a lost key is rotated, never recovered.
Send it as a bearer token:
Authorization: Bearer jcol_your_key_here
The key decides the organization and the asset. It reaches only its own asset, at /api/v1/assets/<its own id>. It can't create or list assets or touch another one; those requests answer 403 asset_scope_mismatch. That's what makes it safe to leave on the host it belongs to.
| The key can | Endpoint |
|---|---|
| Read its own asset, in any status | GET /api/v1/assets/:id |
| Archive its own asset, or revoke its own credential | PATCH /api/v1/assets/:id/status |
It can't restore its asset after an archive: archiving revokes the key, so it could never sign in to ask.
Read the asset
curl https://api.jutsu.ai/api/v1/assets/$ASSET_ID \
-H "Authorization: Bearer $ASSET_KEY"
The response has the asset under asset. Its kind-specific fields, including status, name and token_prefix (the display handle, safe to log), sit under asset.collector. asset.host_platform is linux, macos, windows, docker, webhook, or null.
Archive or revoke the asset
curl -X PATCH https://api.jutsu.ai/api/v1/assets/$ASSET_ID/status \
-H "Authorization: Bearer $ASSET_KEY" \
-H 'Content-Type: application/json' \
-d '{"status":"archived"}'
status | On an active asset |
|---|---|
archived | Archives it. The asset stops collecting, frees its plan slot and keeps its history. Its key is revoked |
revoked | Revokes the credential. The asset stays listed as revoked. This is final: add a new host to collect again |
active | Changes nothing and answers 200 |
Both changes end the key, so the next request with it answers 401 invalid_api_key. A script that lost the response and retries gets that 401, not a second 200. Check the result in the console instead of retrying.
Archiving or revoking an asset with its own key also raises a high-severity alert, "Host deregistered itself with its own key", because a monitored host going dark by its own hand looks the same as an attacker switching monitoring off. Close the alert if the decommission was planned. The audit log names the key, as asset_key:jcol_A1b2C3d, not a person.
Errors and limits
| Status | error | Meaning |
|---|---|---|
| 401 | invalid_api_key | The key is unknown, revoked, or rotated out past its grace window |
| 403 | asset_scope_mismatch | The request aimed somewhere other than the key's own asset |
| 403 | forbidden | The key can't do this, for example restore its asset |
| 409 | invalid_transition | The asset can't move to that status from where it is |
| 429 | rate_limited | Over about 300 requests a minute for the key. Retry-After says when to retry |
| 503 | control_plane_unavailable | A problem on Jutsu's side. Retry with the same key |
A 401 means the key is wrong and retrying won't help. A 503 means Jutsu is unavailable and retrying will.