Version
WEBHOOK

support.settings.updated

A project's support inbox settings change.

When this fires

A creator saves the project's support settings and at least one of the five visible settings is different afterwards:

  • Dashboard: Support Settings → Save from the support inbox.
  • REST: PATCH /v1/projects/{project}/support/settings. Fields you omit keep their stored value.
  • MCP: the update_support_settings tool.

It does not fire when:

  • Nothing changed. Saving the form untouched, or a PATCH that re-sends the stored values, writes nothing and emits nothing. Blank strings normalise to null before the comparison, so clearing an already-empty agent_name is not a change.
  • The bot links or unlinks the relay chat. That handshake changes the relay chat id, which is not one of the five settings this event covers.
  • A member's message is auto-acknowledged. Sending the auto_reply text is a message, not a settings change, and raises nothing in this family.

The relay chat id (the chat or forum group the bot forwards member messages to) is never in this payload. It is an identifier the bot's linking handshake writes, not a setting a creator types, and no surface can change it through this path.

Caveats

  • Subscribing needs support-conversation:view, but making the change needs the project update permission (project:update on a token), because the settings are columns on the project rather than on the inbox. A token that can read support threads can hear about settings changes it could not have made.
  • settings is always the full post-save state, even when only one key changed. You can overwrite a cached copy wholesale and use changes purely for "what to announce".
  • auto_reply is creator-authored template text and does appear in both settings and changes; it is the message members receive, not a message a member sent, so the family's rule about member text is intact.
  • Switching relay_mode to forum_group does not by itself link a group. The project bot links a group when the creator adds it to a supergroup with Topics enabled as an administrator, and confirms by DM; until that happens, notifications have nowhere to go and member messages reach only the dashboard inbox.

Related events

  • support.conversation.opened: the traffic these settings govern.
  • project.updated: other project-level edits, which never include the support columns.

Ability to subscribe

A token needs this to subscribe an endpoint to the event.

Header Parameters

SB-Signature*string

t=<unix seconds>,v1=<hex>: the HMAC-SHA256 of "<t>.<raw body>" under the endpoint's secret. Verify it before acting, and refuse a t more than 300 seconds from now. During a secret rotation a v0= signature under the previous secret may precede v1=.

SB-Event-Id*string

The event's ULID, bare. The envelope's id is the same ULID prefixed evt_, so strip the prefix before comparing. Deduplicate on it: a retry carries the same id.

SB-Event-Name*string

The event name, the same as the envelope's type.

Content-Type*string

Always application/json.

User-Agent*string

Always Subscriby-Webhooks/1.0.

Payload

JSONWhat Subscriby posts to your endpoint

The signed JSON envelope posted to your endpoint.

The envelope every event is delivered in.

Responses

2XXAny success status

Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.

defaultAny other status

Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or POST /v1/webhook-deliveries/{delivery}/retry. After 20 consecutive failures the endpoint is paused until it is resumed.

How is this guide?

Last updated on