Delete a client's signal setup
Remove one of a client's signal setups.
Removes one of the named client's signal setups. Once deleted, it stops appearing in List a client's signal setups and no longer resolves by ID. The list it was watching is not changed, and other setups can keep using it. You can delete the list once no signal setup watches it.
Route
DELETE/api/v3/partner/workspaces/{partner_workspace_id}/signal-setups/{signal_setup_id}
Path parameters
| Parameter | Type | Description |
|---|---|---|
| partner_workspace_id | string | Your own ID for the client workspace, as you chose it at creation. URL-encode it in the path. |
| signal_setup_id | integer | ID of the signal setup. |
Example request
curl -X DELETE "https://api.getsillage.com/api/v3/partner/workspaces/ws_123/signal-setups/42" \
-H "Authorization: Bearer $SILLAGE_MASTER_KEY"Success response
Status: 200 OK
{
"data": {
"id": 42,
"deleted": true
}
}Response fields
| Field | Type | Description |
|---|---|---|
| data.id | integer | ID of the signal setup that was deleted. |
| data.deleted | boolean | Always true. |
Errors
| Status | Meaning |
|---|---|
| 401 | The master key is missing or invalid. |
| 404 | No workspace found for this partner_workspace_id, or no signal setup matches this ID. |
| 422 | signal_setup_id is not a valid ID, or a query parameter is sent: this route takes none, and errors names the parameter. Also returned when partner_workspace_id is invalid. |
| 429 | Rate limit exceeded. |
| 500 | An unexpected server error occurred. |
Error responses use RFC 9457 problem documents with Content-Type: application/problem+json. type is always about:blank; code tells one problem from another, detail says what went wrong this time, and errors names the field at fault.