Notification system
Project rules send events in-app, by email, to a Telegram group and to a webhook. Each operator turns push on for themselves.
Notifications work on two levels: the owner and admins set the project rules, and each operator sets up personal notifications (push and in-app) in their profile.
Project rules
“Settings → Team & routing → Notifications”, the “Events and channels” table. Turn on the channels you want for each event and save — nothing is sent for an event until a channel is on. Events: Ticket Created, Ticket Assigned, Ticket Closed, Ticket Reopened, New Message, SLA Response, SLA Resolution, Ticket Rated.
| Channel | Who gets it |
|---|---|
| In-app | Every active operator of the project (respecting the ticket's department and personal schedules) — in the dashboard bell. Ticket Assigned goes only to the assignee. Whoever did it (took the ticket themselves, say) isn't notified of their own action. |
| The addresses you add to the event (type an address and press Enter). Emails are sent through the platform's mail server. | |
| Also post to Telegram group | The group set on the project's Telegram channel (the Group ID field in “Settings → Channels”) — a separate message for each event with an “Open the conversation” button, in the language of the project owner's account (Russian or English). The channel's bot sends it. Off by default: ticket cards reach the group without it. Without a group nothing is sent. |
| Webhook | Your server at the URL from the Delivery block — one URL for every event. |
Webhook
The Delivery → Webhook block holds the URL, the Signing secret and Extra headers. The request is always a POST with JSON: the body carries the event data (for example ticket.id, ticket.subject, contact.name), and the event type is in the X-SupportHub-Event header.
POST <your URL>
Content-Type: application/json
X-SupportHub-Event: ticket.created
X-SupportHub-Signature: sha256=<HMAC-SHA256 of the body, hex>
{"ticket.id": "…", "ticket.subject": "…", "contact.name": "…"}- The signature is an HMAC-SHA256 of the request body with your secret, sent in
X-SupportHub-Signatureassha256=…. Compute the same on your side and compare. - Extra headers go one per line as “Name: value”, or as a JSON object. Once saved, values are never shown again, only the names. An empty field keeps the saved headers; “Remove headers” deletes them. Content-Type, Content-Length, Host, X-SupportHub-Event and X-SupportHub-Signature can't be set.
- One attempt with a 10-second timeout, no retries.
For integration events with retried delivery, use the API webhooks.
Personal notifications
Each operator turns these on in “Profile → Notifications”, separately for each project. They arrive as a push and in the dashboard bell, and with the “Email copy” switch also by email to the operator's account address:
- New ticket, Ticket assignment, SLA violation and New message are on by default; Customer rating, Ticket resolved / closed and Ticket reopened are off. SLA violation also covers warnings about an upcoming breach. Email copy is off by default.
- Department notifications — all of the operator's departments, or only the ones picked.
- Push notifications on this device — one subscription per device for every project. “Send a test push” checks delivery and shows the projects where the personal schedule is muting notifications right now.
When nothing arrives
- The operator has a personal schedule on (“Profile → Work hours”): outside the marked hours they get no push, in-app notifications or email copies. With the schedule off, notifications always arrive. See Work hours and the on-duty badge.
- The customer is muted — their tickets send no notifications at all (contact moderation).
- The ticket belongs to a department the operator switched off in Department notifications.