Archive a resource
/resources/{ref}Archives (soft-deletes) a resource: it is moved to the deletion archive state, disappears from search and normal views, and remains recoverable by an administrator in-app. This mirrors the internal delete behaviour. Permanent (hard) deletion is not available on the external API.
Requires the write scope and edit access to the resource under the
linked user. Archiving an already-archived resource succeeds and
reports already_in_deletion_state in details.
Authorization
apiKey Issued to you when your integration is provisioned. Determines which catalogue resources are visible and which AI tools are available.
In: header
Path Parameters
Response Body
application/json
application/json
application/json
application/json
curl -X DELETE "https://example.com/resources/0"{ "data": { "deleted": true, "type": "soft", "details": { "previous_state": 0, "new_state": 3 } }}{ "success": false, "status": "fail", "message": "API key is required", "error": { "code": "NO_API_KEY", "message": "API key is required" }}{ "success": false, "status": "fail", "message": "string", "error": { "message": "API key is required", "code": "NO_API_KEY" }}{ "success": false, "status": "fail", "message": "string", "error": { "message": "API key is required", "code": "NO_API_KEY" }}MCP streamable-HTTP endpoint (JSON-RPC 2.0) POST
Model Context Protocol (MCP) gateway. This is a single **opaque JSON-RPC 2.0** endpoint over MCP streamable-HTTP — the request and response bodies are JSON-RPC envelopes, not a REST resource. Drive it with an MCP client (Claude Code, the MCP Inspector, the official SDKs) rather than by hand; the shapes below are documented for completeness. Responses are always `application/json` (this server never upgrades a POST to Server-Sent Events, which the streamable-HTTP spec permits). **Handshake & sessions.** Call `initialize` first; the response carries an `Mcp-Session-Id` header that every subsequent request must echo back in an `Mcp-Session-Id` request header. The session is bound to the api key that created it (a session from one key cannot be resumed by another) and has a rolling TTL. A missing/expired/foreign session returns **404** with JSON-RPC error `-32001` so clients transparently re-initialize. **Methods.** `initialize`, `notifications/initialized` (→ 202, no body), `ping`, `tools/list`, `tools/call`. **Per-tool scopes.** The curated tools require the `read`, `write` or `ai` scope. `tools/list` returns only the tools your key's scopes allow; `tools/call` re-checks and returns JSON-RPC error `-32002` if the key lacks the tool's scope. The linked user's own permission walls apply underneath. Tool execution failures (not-found, validation) come back as in-band results with `isError: true`, not JSON-RPC errors.
Update field values on a resource PATCH
Applies field values to an existing resource. Requires the `write` scope, view access to the resource, and edit access under the linked user's edit filter / archive-state permissions — the same authorisation as editing in the app. Field keys are field names (see `POST /resources` for naming and value conventions — the same rules apply). All names are validated against the resource's type before anything is written; an unknown name fails the whole request with 400. Value-level failures on list-type fields (e.g. a nonexistent option name) are reported per-field in `fieldErrors` while the other fields still save. Updates are audit-logged and reindexed exactly like internal edits, and the title field's denormalised copy is kept in sync.