A lot of software “has webhooks” in the sense that a ticket gets created and, synchronously, right there in the same request, it tries to POST to a URL. If that URL is slow or down, the person creating the ticket waits for it — or worse, the delivery just fails silently and nobody finds out until someone asks “wait, why didn’t Slack get pinged three days ago?”
Here’s how ThickGrass actually handles it, because the architecture is the whole point.
Firing a webhook never blocks the ticket save
When a ticket is created, a status changes, or a public reply is posted, Webhook::fire() runs — and all it does is look up which active webhooks are subscribed to that event and insert a row into a delivery queue. That’s it. No HTTP call happens in that request. The person who just filed a ticket never waits on your Slack workspace being reachable.
The actual delivery happens on its own schedule, with real retry logic
A separate, regular cron job picks up due deliveries and performs the real wp_remote_post() call. If it fails, the delivery isn’t dropped — it’s retried with a growing backoff (5 minutes, then 10, then 15, and so on) for up to 5 attempts before it’s marked permanently failed and logged to the audit trail where an admin can actually see it happened. Compare that to a system where a failed webhook just… doesn’t happen again, silently, forever.
Payloads that already speak Slack and Teams
Point a webhook at a Slack or Microsoft Teams incoming webhook URL and pick the matching payload format, and ThickGrass builds the message in the shape those platforms expect — a short, readable summary line, not a raw JSON blob you have to transform with a separate Zapier step just to make it legible in a channel.
Signed, when you want it
Set a secret on a webhook and every delivery includes an X-ThickGrass-Signature header — an HMAC-SHA256 signature of the payload — so the receiving endpoint can verify the request actually came from your ThickGrass install and wasn’t forged. It’s optional (a webhook with no secret sends unsigned), but it’s there for the integrations where you need to prove authenticity, not just receive data.
Why this level of detail matters
If you’re evaluating helpdesk software to plug into an existing stack — Slack, an internal dashboard, a data warehouse — the honest question isn’t “does it have webhooks,” it’s “what happens when the receiving end is down for ten minutes.” ThickGrass’s answer is: nothing gets lost, it just retries, and if it eventually gives up, you’ll know.
