Webhooks vs. Events — Differences, When to Use Which

Tokity offers two ways to get notified when a ticket changes: Webhooks and Events. They cover the same underlying data, but differ in how much filtering, visibility, and control you get. This article explains how each works, and how to decide which one fits your integration.

Webhooks

A webhook works the standard way you'd expect: you register an endpoint, and Tokity sends an HTTP request to it whenever a ticket changes.

The key difference from a typical webhook implementation is that ticket changes aren't one generic event — you subscribe to the specific change types you care about:

• Ticket created
• Status changed
• Ticket updated (generic — fires on any ticket change)
• Comment added
• Ticket closed
• Ticket re-opened
• Time entry added
• Approval required
• Approval granted
• More info requested
• Ticket survey response received
• Ticket tags updated
• Ticket survey triggered

This lets you subscribe only to the events relevant to your integration, rather than filtering everything yourself after the fact.

The from property. Every webhook payload includes a from object showing the ticket's previous state. When from is null, that tells you the ticket didn't exist before this event — in other words, this is a ticket-created event. Otherwise, you can diff from against the current ticket data to work out exactly what changed. This means you can either rely on the specific event type you subscribed to, or subscribe broadly (e.g., "ticket updated") and determine what changed yourself by comparing from to the current values.

Why the payload is wrapped in an array. This is mostly historical: Tokity originally planned to support batching multiple events into a single call, so a receiver (like Power Automate) could enumerate and process several changes at once. In practice, this turned out to be impractical — the system sends events eagerly as they happen, rather than waiting to batch them, and with the number of distinct event types available, you're effectively always subscribing narrowly enough that each call ends up as a single item in the array anyway. The array format remains for backward compatibility and potential future use, but expect one item per call in practice.

Security. Each webhook registration gets its own auto-generated secret, used to sign every request — see the callout above for verification details.

Events

Events are Tokity's more advanced take on the same idea — think of it as a webhook with a built-in rules engine, plus a visual history of what happened. An event has three parts: trigger, conditions, and actions.

• Trigger — the same list of ticket change types available to webhooks (ticket created, status changed, comment added, etc.). Any matching change is recorded against the event.
• Conditions — built using a condition editor similar to Power Automate's, letting you filter by things like which queue the ticket belongs to, its priority, its tags, and more. You can chain multiple conditions together.
• Actions — one or more endpoints to call once a trigger passes all conditions, each configured the same way as a webhook endpoint.

Because filtering happens on Tokity's side before anything is sent, the event payload is simpler than a webhook payload — for example, there's no from property, since the filtering logic already handled comparing states before deciding to fire.

Visibility. Every event keeps a run history for 28 days, showing:

• Every time the trigger matched.
• Which condition (if any) filtered it out.
• If it passed all conditions, whether each action succeeded, and how quickly the payload was delivered (e.g., delivered in 35ms).

This gives you a clear audit trail of what fired, what got filtered, and what was actually delivered — something webhooks don't provide.

Security. Just like webhooks, each event has its own auto-generated secret — see the callout above for verification details.

Power Automate connector

The Power Automate connector (released under Tokity's original product name, DeskDirector) isn't a separate mechanism from events — when you build a flow using the connector, it creates an event behind the scenes on your behalf. So there are really just two ways to create an event: manually through the Admin Portal's event editor, or indirectly by building a flow in Power Automate.

The trade-off is in how much condition flexibility each path gives you. Events created manually support matching multiple values on a condition — for example, filtering by several queues at once. Events created through the Power Automate connector only support simple, single-value conditions — for example, a single queue at a time. If you need multi-value matching, build the event manually in the Admin Portal instead of through the connector.

This also matters for the 100-event limit: since a Power Automate flow counts as one event, flows that only differ by a single condition value (e.g., one flow per queue) are good candidates to consolidate into a single manually-created event with a multi-value condition — freeing up room under the limit.

When to choose which

Events are the recommended starting point for most integrations, especially with Power Automate, since you get built-in filtering plus a full run history without writing any filtering logic yourself. Events are a free feature, but capped at 100 events per tenant — this limit exists because of the underlying data Tokity has to maintain for the run history, and because the more filtering work Tokity does per ticket change, the more load it puts on the server. There's no way to guarantee that 100 active events won't all need to be evaluated against a single ticket change, so the limit keeps this predictable.

If you're approaching the 100-event limit, it's worth reviewing your existing events first: it's common to end up with several events that are otherwise identical except for a single condition value — for example, five separate events that only differ by which queue they're filtering on. These can usually be merged into a single event by updating that one condition to match multiple values (multiple queues, tags, priorities, statuses, etc.) instead of creating a new event per value.

Webhooks are the better choice if:

• You've hit the 100-event limit and have no more events left to consolidate.
• You'd rather do your own filtering (comparing from to the current state) instead of configuring conditions in the UI.
• You want to fan a single change out to multiple receivers yourself.

The trade-off with webhooks is that you don't get the run-history view events provide — Tokity only surfaces a webhook in the "deleted" section if it continues to fail outright, not a detailed per-call log.

For most organizations, events (or the Power Automate connector, for simple single-condition cases) comfortably cover what's needed. If you ever outgrow the 100-event limit, webhooks remain fully available as the fallback — subscribe broadly, and use the from property to work out what changed yourself.