Inbound Triggers

Inbound triggers are automation rules that start from an external app. When a connected app sends an event, for example a new Whop member or a failed Stripe charge, Ticket Tool can open a ticket, post a message or run a flow for you. Automation Rules covers the rule builder itself; this page covers the app side.

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

The store apps, GitHub, Linear, Ko-fi and the Incoming Webhook send events. Jira, Trello, ClickUp, Asana, Slack, Notion and Gumroad are outbound only.

App	Events
Whop	membership activated (new or renewed), membership updated (canceled, expired or changed), payment succeeded, payment failed
Stripe	charge failed, charge refunded, invoice payment failed, checkout completed, subscription created, updated or canceled, trial ending, dispute opened
Patreon	member created/updated/removed, pledge created/updated/canceled
Sellix	order created, paid, canceled, disputed, partially paid; subscription created or canceled
Tebex	payment completed or declined, refund, chargeback, dispute won or lost, subscription started, ended or canceled
Lemon Squeezy	order created or refunded; subscription created, canceled, expired; subscription payment succeeded or failed
Paddle	transaction completed or payment failed, subscription created, past due or canceled, refund or credit created
Ko-fi	donation, membership, commission, shop order
GitHub	issue opened, closed or reopened, issue comment added, pull request closed or merged, release published
Linear	issue created, updated or removed, comment added
Incoming Webhook	anything it receives

How it works

App sends event

The external app posts a webhook to your unique URL

Ticket Tool verifies it

The signature is checked and duplicate events are ignored

Rules match

Your rules for that event are found

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

Click Set up webhook on the connection. The dialog shows the webhook URL, the steps for that app, and the signing secret:

Apps that issue their own secret (Stripe, Whop, Paddle and others): paste it in and click Save secret.
Apps where you choose the secret (GitHub, Linear, Incoming Webhook): click Generate secret and paste it into the app. It is shown once.

Ticket Tool uses the secret to verify every incoming event is genuine. It is encrypted and never shown again.

Add a rule

Under Automations → Rules, click New rule and choose:

The event: one of the connected app's events, such as Charge failed.
The action: open a ticket, send a message, or run an automation flow.
Conditions (optional): checks on payload fields by path, such as data.plan equals Pro. A field can equal, not equal or contain a value, or just be present. The rule fires only when every condition matches.

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.

Post in the linked ticket

For GitHub and Linear events about an issue, posts the event (and an optional message of yours) in the open ticket whose flow created that issue. See Acting on the linked ticket.

Close the linked ticket

Closes that ticket, with your close reason if you set one.

Do something in a connected app

Runs one action in any connected app, such as posting to Slack when a Stripe dispute opens. Fields can use the event fields you map, as {{inputs.<label>}}.

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

When a rule opens a ticket or posts in a linked one, it adds an event card. The card shows the app's name and icon, what happened (such as "Membership activated"), and a few details from the event, such as the member, product, price and renewal date. When the event links to the record, a View in button opens it in the app. Turn off Show event details on the rule to leave the card out.

To choose the details yourself, map payload fields. Each mapping is a label plus a path into the event data. For example label "Plan" with path data.plan shows "Plan: Pro" on the card. A rule with mappings shows those instead of the default details, and messages and flows can use them as {{inputs.<label>}}.

Flows post nothing of their own, so a flow decides what to send.

Acting on the linked ticket

When a flow running in a ticket creates a GitHub or Linear issue, the ticket is linked to it (you can see the link under Connected apps in the ticket's side panel). Events that name that issue can then reach the ticket:

App	Events that find the linked ticket
GitHub	issue closed, issue reopened, issue comment added
Linear	issue updated, issue removed, comment added

For example: a bug-report flow creates a GitHub issue, and a rule on Issue closed posts "Fixed in the latest release" in the ticket and closes it. An event about an issue no ticket created is skipped, and the run says so.

Incoming Webhook

The Incoming Webhook connection gives you a URL that any app, form tool or script can post JSON to. Each delivery fires the connection's Received event, and your rules can read any field with conditions and field mappings.

Prove a delivery is yours in whichever way the sender supports:

Send the secret in an X-Webhook-Secret header.
Add it to the URL as ?token=<secret> for senders that can't set headers.
Sign the raw body with HMAC-SHA256 in X-Signature-256 (hex or base64, sha256= prefix optional). Typeform and Tally signatures work as they are.

Deliveries are deduplicated by an Idempotency-Key, X-Request-Id or X-Event-Id header when there is one, otherwise by the body within a 10-minute window.

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. Each event that matches a rule is recorded under Automations → Activity Logs, on the Activity tab, as a run of that rule marked Ran, Skipped or Error.

Debugging a trigger

If a rule does not fire, check the Activity tab under Automations → Activity Logs. A Skipped run shows its reason, such as the event not matching the rule's conditions or the rule having no target channel, flow or category. An Error run shows what went wrong. No run at all means the event never reached the rule: check that the rule is on for that event, and the signing secret, since an event that fails the signature check is rejected before any rule sees it.

Integrations: connect apps, use them inside flows, and linked tickets
Automation Rules: triggers, conditions and actions for every rule
Using Support Flows: for more advanced automation