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_settingstool.
It does not fire when:
- Nothing changed. Saving the form untouched, or a
PATCHthat re-sends the stored values, writes nothing and emits nothing. Blank strings normalise tonullbefore the comparison, so clearing an already-emptyagent_nameis 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_replytext 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:updateon 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. settingsis always the full post-save state, even when only one key changed. You can overwrite a cached copy wholesale and usechangespurely for "what to announce".auto_replyis creator-authored template text and does appear in bothsettingsandchanges; it is the message members receive, not a message a member sent, so the family's rule about member text is intact.- Switching
relay_modetoforum_groupdoes 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
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=.
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.
The event name, the same as the envelope's type.
Always application/json.
Always Subscriby-Webhooks/1.0.
Payload
JSONWhat Subscriby posts to your endpointapplication/json
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