Signed WEBHOOK_EVENT Automation Triggers
How WEBHOOK_EVENT rules are configured, what token and secret fields mean, how signed inbound payloads trigger runs, and how users should troubleshoot rejected webhook events.
Signed WEBHOOK_EVENT Automation Triggers
Where you see this in the app
This page explains WEBHOOK_EVENT rules inside Workspace config & automations -> Rules.
These rules are for inbound events that should trigger an automation run for a specific post.
Creating a webhook-event rule
When you create a rule and choose Trigger -> WEBHOOK_EVENT, you are telling GetPaidX:
| Setting | What it means |
|---|---|
Enabled | The rule may accept inbound events and enqueue runs |
WEBHOOK_EVENT | The trigger comes from a signed incoming request or channel event, not from a schedule |
Cooldown (s) | Minimum time between runs started by that rule |
Prompt template | The instructions the automation will run when an event is accepted |
This is different from:
SCHEDULE, which runs on a timing rule,PURCHASE_SUCCEEDED, which runs after a successful buyer purchase.
Token, secret, and signature
The user-facing mental model has three parts:
| Piece | What it is for |
|---|---|
| Path token | Identifies which rule/post endpoint the external sender is targeting |
| Webhook secret | Shared secret used to prove the request is trusted |
| Signature header | The signed proof attached to each inbound request |
The current docs and API examples use these headers:
| Header | Meaning |
|---|---|
x-gpx-webhook-secret | The secret that matches the rule |
x-gpx-signature | The signed timestamped proof for the payload |
If either one is wrong, the run should not be accepted.
What a successful trigger does
When a valid event arrives:
- GetPaidX verifies the token and signature data,
- the matching post rule is identified,
- a
WEBHOOK_EVENTautomation run is enqueued, - the worker later processes that queued run in the workspace.
From an end-user standpoint, this means the webhook call does not need to finish the whole automation immediately. It only needs to be accepted and queued correctly.
Failure modes and user checks
| Problem | What to check |
|---|---|
| Rule never seems to fire | Confirm the rule is Enabled and really uses WEBHOOK_EVENT |
| Request is rejected | Recheck the token path, secret, timestamp/signature, and payload format |
| Request seems accepted but no result appears | Check the Runs tab to see whether the run is QUEUED, RUNNING, or FAILED |
| Telegram/WhatsApp behaves differently from your custom sender | Channel events are system-trigger sources that also enqueue WEBHOOK_EVENT runs, but their setup lives in the channel/status surfaces |
Related docs
Related docs
See it in action
Previous
Telegram and WhatsApp Channel Setup
How the profile-workspace Telegram and WhatsApp controls work, when the workspace is ready for each channel, and what the main channel states mean.
Next
Workspace System-Trigger Status
How the System triggers status cards work, what Telegram and WhatsApp status fields mean, and how those channel states relate to webhook-style automation runs.