Update a signal setup

Updates one of your signal setups. Send only the fields you want to change — at least one of name, enabled, parameters or schedule is required.

parameters, when sent, is merged into the stored setup: a key you include overwrites its stored value, null removes that key, and every key you leave out is kept as is. The merged result is validated against the signal's setup.fields the same way as on creation — send a full replacement if you want to, but you only ever need to send your changes.

A signal that has since been archived can still be updated, its parameters, schedule and enabled state all keep working. Only creating a new setup from an archived signal is refused with a 409.

A setup keeps the list it was created on. Sending the same list_id back always works and changes nothing; naming a different one is refused with a 409, and nothing changes. Signals refer to the list they were set up on, and so does what they cost, so a setup is never moved: set the signal up again on the other list instead.

Route

PATCH/api/v3/signal-setups/{id}

Access modes

Use a workspace API key. The workspace is inferred from the key.

Authorization: Bearer sk_live_...

Path parameters

Parameter	Type	Description
id	integer	ID of the signal setup. Specific to your environment.

Body parameters

Parameter	Type	Description
name	string	New display name.
enabled	boolean	Turn this setup on or off.
parameters	object	Merged into the stored setup: an included key overwrites its stored value, `null` removes it, and every key left out is kept. The merged result is validated against the signal's `setup.fields`.
schedule	object or null	`{ "cadence": "weekly" }` to run this setup on a weekly cadence, `null` to turn scheduling off.

Example request

The first call below only changes the schedule — every other stored answer is kept. The second removes max_signals_per_week by sending it as null, leaving everything else untouched.

curl -X PATCH "https://api.getsillage.com/api/v3/signal-setups/42" \
  -H "Authorization: Bearer $SILLAGE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "parameters": { "schedule": "manual" } }'

curl -X PATCH "https://api.getsillage.com/api/v3/signal-setups/42" \
  -H "Authorization: Bearer $SILLAGE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "parameters": { "max_signals_per_week": null } }'

Success response

Status: 200 OK

The setup below was created with { "keywords": ["acme", "acme corp"], "scopes": ["discovery"], "max_signals_per_week": 50 }. After the second PATCH above, max_signals_per_week is gone and everything else is unchanged:

{
  "data": {
    "id": 42,
    "signal_template_id": 3,
    "name": "Acme keywords",
    "status": "enabled",
    "parameters": { "keywords": ["acme", "acme corp"], "scopes": ["discovery"] },
    "schedule": null,
    "created_at": "2026-09-18T12:00:00.000Z"
  }
}

Response fields

Same shape as Get a signal setup.

Errors

Status	Meaning
400	`id` is not a valid ID.
401	The API key is missing or invalid.
404	No signal setup matches this ID.
409	`parameters` names a different `list_id` than the one this setup was created on.
422	The body has no updatable field, or the merged `parameters` fails validation against the signal's `setup.fields`.
429	Rate limit exceeded.
500	An unexpected server error occurred.

PUT is not accepted on this route — it answers 404 or 405.

Error responses use RFC 9457 problem documents with Content-Type: application/problem+json. type is always about:blank on v3 — title is what tells one problem from another. A 422 from invalid parameters names the offending property under errors, the same way Set up a signal does. An invalid merge is rejected atomically: nothing is written, and a follow-up GET shows the setup exactly as it was before the request.

Update a signal setup

On this page