delete-user-connector

Delete a user-defined connector with its skills and saved credentials. Irreversible. Needs the fabric:skill.write grant.

curl -sS -X POST https://fabric.wexa.ai/mcp/$FABRIC_PROJECT_ID \
  -H "authorization: Bearer $FABRIC_API_KEY" \
  -H "Mcp-Session-Id: $MCP_SESSION_ID" \
  -H "content-type: application/json" -H "accept: application/json" \
  -d '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"delete-user-connector","arguments":{"connector_id":"6b1a3d5e7f9c0b2a4d6e8f02"}}}'

{
  "content": [
    {
      "type": "text",
      "text": "{\"lifecycle_id\":\"qlc_000017\",\"result\":{\"status\":\"success\"}}"
    }
  ],
  "isError": false
}

curl -sS https://fabric.wexa.ai/v1/delete-user-connector \
  -H "authorization: Bearer $FABRIC_API_KEY" \
  -H "content-type: application/json" \
  -d '{"connector_id":"6b1a3d5e7f9c0b2a4d6e8f02"}'

{
  "lifecycle_id": "qlc_000017",
  "result": {
    "status": "success"
  }
}

import { Fabric } from '@wexa-fabric/sdk'

const fabric = new Fabric()
const result = await fabric.deleteUserConnector({
  connector_id: '6b1a3d5e7f9c0b2a4d6e8f02'
})

// result is the payload itself, with no `.result` to read
{
  status: 'success'
}

from wexa import Fabric

fabric = Fabric()
out = fabric.delete_user_connector(
    connector_id="6b1a3d5e7f9c0b2a4d6e8f02",
)

# out is the result, already unwrapped
{
    "status": "success"
}

Parameters

Parameter	Type	Required	Notes
`connector_id`	string	Required	The user-defined connector, from `list-user-connectors`. Must be a non-empty string. An unknown id is refused (404) with the platform's own reason. One you may not edit (another person's draft, or a published one when you are neither its author nor a project admin) is refused (502, `user connector not found`).

Errors

ValidationError (400): the platform refused the delete. The message is the platform's own reason.

Show full response

An example response.

{
  "content": [
    {
      "type": "text",
      "text": "{\"lifecycle_id\":\"qlc_000017\",\"result\":{\"status\":\"success\"}}"
    }
  ],
  "isError": false
}

{
  "lifecycle_id": "qlc_000017",
  "result": {
    "status": "success"
  }
}

// the object you get back IS the result — there is no `.result` to read
{
  "status": "success"
}

// The TS SDK names these camelCase — lifecycleId, traceId — where Python uses
// lifecycle_id and trace_id. Both are non-enumerable: readable, but omitted by
// Object.keys() and JSON.stringify(). `result.lifecycleId` here is undefined.
result.lifecycleId // 'qlc_000017'

# a dict subclass; `result` is already unwrapped
{
 "status": "success"
}

out.lifecycle_id  # 'qlc_000017' — an attribute, not a key

Keeping the lifecycle_id is what lets you ask later why a call was allowed, refused or held.

More details

Response fields

status: The platform's answer, success when the connector was deleted.

You may delete a connector you may edit: your own, or, for one published in this project, any of them if you are a project admin. Whether you may edit it is checked when the call is executed, after any approval, so a call by someone who may not edit it is refused then, even when a person approved it.

To keep the connector but stop others using it, take it back to a draft with publish-user-connector and scope individual instead.

The connector id in the example is illustrative. Swap it for one list-user-connectors returned to you.

Marked consequential: it is audited in full, and a policy rule may hold it for a person to approve. The project's write gate, when a project admin has turned it on (it is off by default), also holds it when an API key or SDK session calls it.

Every tool call works the same way: How every tool call works.