Update a client's signal setup

Updates one of the named client's signal setups. Send only the properties you want to change: at least one of name, status, parameters, schedule or persona_id is required.

Route

Path parameters

Body parameters

Merging parameters

parameters, when sent, is merged into the stored parameters: a key you include overwrites its stored value, null removes that key when the parameter has no default, and every key you leave out is kept. A parameter that has a default cannot be removed: sending null for it is refused with 422, with errors naming it as parameters.<field> ("cannot be removed or set to null: send the new value instead, or leave it out to keep the current one"). An empty job_titles ([]) is refused with 422 too: send at least one. The merged result is validated against the setup.fields of the signal template the same way as on creation, and a parameter that is not valid is refused with 422, with errors naming it as parameters.<field>. The response shows the parameters as applied. You only ever need to send your changes.

Status

status is enabled or disabled: the same two values the setup returns. A paused setup is kept as it is and runs again when you send enabled. A setup that has a weekly schedule does not run at once when you resume it: it waits for its next weekly slot. The boolean enabled is not a property of this route: sending it is refused with 422.

Schedule

Send "weekly" to run the setup every week and null to remove its schedule. Switching to weekly does not run the setup right away. A schedule you leave out is kept as it is. schedule is never one of the parameters: sending it inside parameters is refused with 422, and errors names parameters.schedule.

Persona and list

A setup keeps the persona it was created for. Sending the same persona_id back changes nothing; naming a different one is refused with 422, errors names persona_id ("cannot be changed"), and nothing changes. Set the signal up again for the other persona instead. A setup created without a persona (see Persona required) can be given one once: send its persona_id, and the same checks as on creation apply.

A setup's list can be changed: send another list_id in parameters. The same checks as on creation apply: the list must be one of your lists of the type the signal watches, and a list attached only to personas other than the setup's persona is refused with 409. Leave list_id out to keep the current list.

A signal template that has since been archived can still be updated. Only setting up a new signal from an archived signal template is refused.

Example request

The first call pauses the setup. The second runs it every week. The third replaces its keywords and leaves every other parameter as it was.

curl -X PATCH "https://api.getsillage.com/api/v3/partner/workspaces/ws_123/signal-setups/42" \
  -H "Authorization: Bearer $SILLAGE_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "status": "disabled"
}'

curl -X PATCH "https://api.getsillage.com/api/v3/partner/workspaces/ws_123/signal-setups/42" \
  -H "Authorization: Bearer $SILLAGE_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "schedule": "weekly"
}'

curl -X PATCH "https://api.getsillage.com/api/v3/partner/workspaces/ws_123/signal-setups/42" \
  -H "Authorization: Bearer $SILLAGE_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "parameters": {
    "keywords": [
      "acme.com",
      "Acme Inc"
    ]
  }
}'

Success response

Status: 200 OK

{
  "data": {
    "id": 42,
    "signal_template": {
      "id": 2,
      "key": "mentioned-my-brand",
      "name": "Mentioned my brand",
      "description": "Detect when prospects mention your brand on LinkedIn.",
      "row_summary": "Posts naming your product anywhere on LinkedIn.",
      "category": "my_network",
      "status": "live",
      "subjects": ["person"],
      "scopes": ["discovery", "account_monitoring"],
      "tags": [],
      "pricing": {
        "account_monitoring": {
          "signal_bucket": "essential",
          "credits": 50,
          "unit": "per_key_account_per_month"
        },
        "discovery": {
          "credits": 20,
          "unit": "signal_found"
        }
      },
      "archived_at": null
    },
    "name": "Acme brand mentions",
    "status": "disabled",
    "parameters": {
      "scopes": ["discovery"],
      "keywords": ["acme.com", "Acme Inc"]
    },
    "schedule": "weekly",
    "persona_id": 7,
    "created_at": "2026-09-18T12:00:00.000Z",
    "last_detected_at": null
  }
}

Response fields

Same shape as Get a client's signal setup.

Errors

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. An invalid merge is rejected atomically: nothing is written, and a follow-up GET shows the setup exactly as it was before the request.