Destructive Actions

A destructive action mutates guild state in ways that are hard or impossible to undo. Banning a user, removing a strike, mass-purging a channel, running an arbitrary RCON command — these all leave a footprint that cannot be reversed by a follow-up call.

The public token surface guards these calls with two safeguards working in series. First, the token must have an open re-auth window for the destructive operation, which the dashboard owner approves explicitly and which expires after 15 minutes. Second, the request body must include a _confirmation field whose value matches the operation's sentinel template verbatim, with the placeholders substituted from the rest of the request body.

The following eight operations are destructive on the v1 surface. The trigger column notes when the destructive path applies; operations marked Always are destructive on every call, while POST /mutes is tier-gated by duration.

The runtime-tier carve-out for POST /mutes is the only conditional on the list. Mutes of 24 hours or fewer are reversible and need no sentinel; mutes longer than 24 hours are destructive and require both the re-auth window and the sentinel. Every other operation on the table is destructive on every call.

The server validates the sentinel verbatim after a small normalization pass. The rules:

• All tokens are UPPERCASE. The server uppercases the input before comparing, so lowercase tokens are tolerated, but the documented form is uppercase.
• Single-space separators. The server collapses runs of whitespace to a single space before comparing.
• Placeholders inside { } are substituted from the request body. {guildId} comes from the URL path; {user_id}, {strikeId}, {count}, and similar come from the JSON body.
• Choice placeholders like {MINOR|MAJOR} mean exactly one of the listed literals. Substitute the one that matches the request.
• The _confirmation field is required on the request body for destructive calls. Send it as a top-level string.

On mismatch the server returns 400 INVALID_CONFIRMATION with both the expected template format and the expected concrete string for the current request. That makes the error self-correcting — the client can compare what it sent against details.expected_concrete and retry.

{
  "error": {
    "code": "INVALID_CONFIRMATION",
    "message": "_confirmation does not match the expected sentinel.",
    "details": {
      "expected_format": "ADD STRIKE TO USER {user_id} IN GUILD {guildId} SEVERITY {MINOR|MAJOR}",
      "expected_concrete": "ADD STRIKE TO USER 123456789012345678 IN GUILD 987654321098765432 SEVERITY MINOR"
    }
  }
}

A re-auth window is a 15-minute grant that authorizes destructive calls from a specific token. The window is tied to the token and the guild, and it expires automatically. There are two ways to open one.

From the dashboard. Open the Settings Panel from your sidebar, find the Developer Mode card and toggle it on (owner-only, per-browser, one-time). API & MCP now appears in your sidebar — open it and switch to the Re-auth tab. Next to the active-tokens list you will see an Approve next destructive action button. Click it to open a 15-minute window for that token. The Re-auth tab also shows any currently open window with a countdown so you can see at a glance whether the next destructive call will succeed.

From the API. Fully scripted workflows can open the window without a dashboard round-trip. POST /api/api-tokens/{id}/reauth-window with the user's session cookie returns the new window. This is useful when the same operator is driving both the dashboard session and the script.

POST /api/api-tokens/01HZTOK01TOKEN01TOKEN01TOK/reauth-window
Cookie: arkanis_session=...

200 OK
{
  "open": true,
  "window": {
    "window_id": "01HZRA01WIN01WIN01WIN01WIN",
    "expires_at": "2026-05-12T22:15:00.000Z"
  }
}

Most clients will encounter the destructive guard the first time they try to issue a strike or ban from a fresh token. The recovery flow has three steps.

1. The destructive call returns 403. The token is valid and has the required capability, but no re-auth window is open. The response includes a reauth_url that points at the dashboard tab.

POST /api/public/v1/guilds/987654321098765432/strikes
Authorization: Bearer arkpat_...
Content-Type: application/json

{
  "user_id": "123456789012345678",
  "severity": "MINOR",
  "reason": "Spam in #general",
  "_confirmation": "ADD STRIKE TO USER 123456789012345678 IN GUILD 987654321098765432 SEVERITY MINOR"
}

403 Forbidden
{
  "error": {
    "code": "RE_AUTH_REQUIRED",
    "message": "Destructive action requires an open re-auth window.",
    "details": {
      "reauth_url": "https://arkanis.gg/dashboard/987654321098765432/panels/settings/api-mcp?tab=reauth"
    }
  }
}

2. Open the window. Either click the dashboard CTA or POST to the re-auth endpoint as shown above. Both result in a 15-minute window scoped to this token.

3. Retry the destructive call. The same request body, sentinel and all, will now succeed.

POST /api/public/v1/guilds/987654321098765432/strikes
Authorization: Bearer arkpat_...
Content-Type: application/json

{
  "user_id": "123456789012345678",
  "severity": "MINOR",
  "reason": "Spam in #general",
  "_confirmation": "ADD STRIKE TO USER 123456789012345678 IN GUILD 987654321098765432 SEVERITY MINOR"
}

201 Created
{
  "strike": {
    "id": "01HZSTRIKE01STRIKE01STRIKE0",
    "user_id": "123456789012345678",
    "severity": "MINOR",
    "issued_at": "2026-05-12T22:01:30.000Z"
  }
}

The window remains open for the remainder of its 15-minute life, so a script that needs to issue several destructive operations in sequence only needs to open one window. After it expires the next destructive call returns RE_AUTH_REQUIRED again.

When destructive operations are invoked through the MCP server, the local arkanis-mcp process constructs the sentinel from the validated tool arguments before sending the REST call. The natural-language client — Claude Desktop, Claude Code, or another MCP client — never has to author the sentinel from prose.

This is the prompt-injection defense. A user could ask the model to issue a ban, but the model has no path to forge a sentinel; the deterministic local code path holds that responsibility. The model can only invoke the tool with structured arguments, and the local construction guarantees the sentinel matches the arguments exactly.

• Rate Limits and Errors covers the full error envelope and every code a destructive caller should handle.
• Authentication covers token rotation and revocation, which are relevant when a destructive-capable token is compromised.
• REST Quickstart walks through the full recovery flow with copy-pasteable curl commands.