Skip to main content
Ticket Tool
Documentation

Inbound Triggers (IFTTT)

Inbound triggers are simple "if this, then that" rules. When a connected app sends an event, for example a new Whop member or a failed Stripe charge, Ticket Tool can open a ticket or post a message for you. No flow building required.

Pro feature

Inbound triggers are part of Integrations, available on the Pro plan. You also need a connected app that supports events.

Which apps send events

Only the commerce apps send inbound events today: Whop, Stripe, Patreon, Sellix, and Tebex. The escalation and productivity apps (GitHub, Linear, Slack, Notion) are outbound only.

App Example events
Whop membership went valid (new or renewed), membership went invalid (cancelled or expired), payment succeeded, payment failed
Stripe charge failed, invoice payment failed, subscription created, subscription cancelled, dispute opened
Patreon member created/updated/removed, pledge created/updated/cancelled
Sellix order paid, cancelled, disputed, partially paid
Tebex payment completed, refund, chargeback, subscription cancelled

How it works

01
App sends event
The external app posts a webhook to your unique URL
02
Ticket Tool verifies it
The signature is checked and duplicate events are ignored
03
Rules match
Your rules for that event are found
04
Action runs
A ticket is opened or a message is posted

Setting it up

You set this up per connected app. The connection (webhook URL and signing secret) lives under Dashboard → Automations → Connections, and the trigger rules are built under Dashboard → Automations → Rules.

Copy your webhook URL

Open the connection under Automations → Connections. Each connection has its own webhook URL, shown with a copy button. It looks like:

https://dash.ticket-tool.app/api/integrations/webhooks/<app>/<connection-id>

Paste this into the webhook settings of the external app (for example Whop's or Stripe's developer settings).

Add the signing secret

The external app gives you a signing secret when you create the webhook. Paste it into the secret field and save. Ticket Tool uses it to verify every incoming event is genuine. The secret is encrypted and never shown again.

Add a rule

Under Automations → Rules, click Add rule and choose:

  • When this event fires pick one of the app's events
  • Do this open a ticket, send a message, or run an automation flow
  • Only when (optional) attach conditions on payload fields (by path, for example only when data.plan equals Pro) so the rule fires only for matching events

Save

Rules can be toggled active or inactive, so you can pause one without deleting it.

The secret is required

Without the signing secret saved, incoming webhooks are rejected. This stops anyone who guesses the URL from opening tickets in your server.

Rule actions

Open a ticket

Choose the category the ticket opens in, then who owns it:

  • Bot: the ticket is opened by Ticket Tool itself
  • Linked user: pull the Discord user id out of the event payload (you give the field path, for example data.discord_id)
  • Specific user: always assign it to one Discord user you choose

If you use linked user and that person is not in the server, you decide what happens: open the ticket as the bot with a note, or skip it.

Send a message

Choose a channel and the message is posted there, formatted with the app name, the event, and any fields you map.

Run an automation flow

Pick one of your support flows and the event runs it, so a single inbound event can drive a multi-step automation. See Using Support Flows for building flows.

Showing event details

For either action you can map payload fields into the ticket or message. Each mapping is a label plus a path into the event data. For example label "Plan" with path data.plan shows "Plan: Pro" in the ticket. This is how staff see the useful context (who, what plan, how much) without leaving Discord.

Safety and reliability

  • Signature verified. Every event is checked against your signing secret. Unverified events are rejected.
  • No duplicates. Each event carries an id; if an app retries the same event, Ticket Tool only acts once.
  • Logged. Every inbound event is recorded under Automations → Logs as delivered, skipped, or error, so you can see exactly what happened.

Debugging a trigger

If a rule does not fire, check Automations → Logs. A "skipped" entry usually means the linked user was not in the server, and an "error" entry shows what went wrong (often a missing or wrong signing secret).

Related