Tickiti

WebSocket real-time events

Tickiti uses a WebSocket service called Tonic to keep the staff UI live without polling. When a colleague responds, an escalation fires, or a ticket changes status, every browser session that is watching gets the update within a second — the ticket list re-sorts, the conversation refreshes, the perspective counts re-tally.

How it fits together

  1. Tonic is a separate process Tickiti talks to. It can be co-hosted on the same server or run separately for scale. Each Tickiti install is associated with one Tonic.
  2. Pin codes identify a Tickiti install to Tonic. The first time Tickiti talks to a fresh Tonic, it generates a unique node key and a one-time pin code; an admin enters the pin into Tonic to register the connection.
  3. Browser connections happen automatically. Each staff tab opens a websocket to Tonic on page load and identifies itself with the user’s session. The Connected indicator at the bottom-left of the staff app reflects the live connection state.

What the WebSocket carries

  1. Ticket updates — new responses, status changes, priority changes, assignment changes, queue moves.
  2. Perspective count refreshes — whenever a ticket enters or leaves a perspective, the count badges update.
  3. Concurrent-editing locks — the “Nathan is responding to this ticket” banner is driven by Tonic. See Concurrent editing.
  4. Tags and acknowledgements — @-tagging a colleague produces a real-time notification.
  5. System events — escalations firing, mailbox errors, queue worker health.

Setup at a glance

The full deployment is covered internally; the customer-facing summary is:

  1. Run a Tonic process and expose it on a host:port your Tickiti install can reach (typically a private network).
  2. In Tickiti, visit the Tonic registration URL Tickiti gives you. It generates a node key + pin code.
  3. Enter the pin code into Tonic.
  4. Tickiti stores the bound credentials. Browser sessions immediately start connecting to Tonic.

If the connection drops — Tonic restarts, network blip — browsers reconnect automatically. The Connected indicator briefly flips to Reconnecting… and back.

Tonic notifications

Each user has a Tonic notifications flag (in User admin). When set, the user receives a stripped-down Tonic-style in-app notification rather than full HTML emails. Useful for power users who want a quieter inbox.

If real-time stops working

  1. Refresh the browser tab. The websocket should re-establish; the Connected indicator confirms.
  2. Check the Tonic process is running on its host.
  3. Check the firewall rules — corporate networks sometimes block long-lived websocket connections; you may need an exception.
  4. Tickiti will continue to work without Tonic — it falls back to regular page loads to refresh data, just less responsively. Real-time is an enhancement, not a hard dependency.

For developers building integrations

The Tonic protocol is currently internal — external integrations should consume Tickiti state via the REST API rather than connecting to Tonic directly. If you need real-time, the recommended pattern is to expose a webhook from Tickiti (via a small plugin) that fires when interesting events happen, and consume that webhook on your side. Talk to your Tickiti contact for current options.