Engineering Glossary · Integrations
Webhooks: Your Endpoint Has a Response-Time Budget
The same event arriving three times is almost never a provider bug; it is your endpoint taking too long to say it got the first one.
The short answer
A webhook is an HTTP POST pointed at you rather than by you — and the service sending it is timing your reply, which makes your endpoint's response time part of the contract rather than an implementation detail.
Providers allow a handful of seconds, then treat the delivery as failed and retry it on a backoff schedule. So the shape that works is always the same: verify the signature, write the payload to a row or a queue, return 200 immediately, and do the real processing on the next cron tick. Anything that talks to a database, resizes an image or calls a third party inside the request is how you end up with duplicate orders.
By the HostingFast team · Reviewed 12 August 2026
0
Jargon left undefined
100+
Entries, all cross-linked
Real
Working examples
Free
To read, always
You register a URL with the service and it posts event data there as things happen: a payment cleared, a form arrived, a branch was pushed. Reacting to an event beats asking over and over whether one occurred, and it removes the polling interval from your latency budget entirely.
The receiving end needs manners. Your endpoint should verify the signature on every delivery, because anyone who learns the URL can post to it, and it should answer promptly. A delivery that failed is normally retried by the service that sent it, which means your handler has to tolerate seeing the same event twice.
The budget nobody prints in bold
Read any provider's delivery documentation and you will find a timeout measured in single-digit seconds, followed by a retry schedule. Your handler is being graded against that clock on every event. Exceed it and the provider records a failure, queues a retry, and eventually starts backing off — so a handler that is merely slow looks identical, from the outside, to a handler that is down.
The observable symptom is duplicates. When the same order confirmation fires twice on a busy afternoon and once on a quiet one, the variable is not the provider. It is how long your endpoint took while the server was under load.
Acknowledge first, work afterwards
Split the handler in two. The synchronous half checks the signature, writes the raw payload and the provider's event ID into a table, and returns 200 with an empty body. That should complete in tens of milliseconds. The asynchronous half runs from cron, picks up unprocessed rows, and does the slow work where nothing is waiting on it.
Store the event ID and check it before processing. That single unique constraint is what makes retries harmless: the second delivery of the same event finds the row already handled and does nothing, which is exactly the behaviour you want at three in the morning.
Proving the endpoint is quick, not assuming it
Time it the way the provider does: curl -X POST -o /dev/null -s -w '%{time_total}' against the endpoint with a representative payload. Then check the raw access log in cPanel — the response time column tells you what real deliveries cost, including the ones that arrived while a backup was running.
One trap is specific to cached hosting. If your webhook path sits behind a full-page cache, the first delivery may be served from cache on the next one and your handler never runs. Exclude the endpoint path from LiteSpeed caching explicitly, then confirm the response carries no cache hit header before you trust it.
Where this lands on HostingFast
Cron is available from the control panel and over SSH, so the deferred half of the handler has somewhere to run without an external scheduler. Every plan ships with a free SSL certificate that renews itself ahead of expiry, which matters because virtually every provider refuses to deliver to a plain HTTP URL.
Follow-on entries: API, Cron Job, Git and WooCommerce — the four terms that usually turn up in the same stack trace as this one.
Definitions written for people who deploy
Every entry here started life as a support ticket. Rather than explain the same term for the two hundredth time, we wrote it down properly — with the command that measures it and the number that counts as good.
Mailboxes on your own domain come as part of the plan — email is included, never sold back to you at checkout.
- 100+ entries, each with the mechanism spelled out
- Commands you can paste, numbers you can compare against
- Neighbouring terms wired together at the foot of every page
- Written by the engineers who answer the tickets
Why HostingFast
Standard on every plan
The retry story told properly
Every integration entry covers what happens on the second delivery, because that is the one that corrupts data.
Mechanism, not vocabulary
How the thing works underneath, since you cannot tune what you only recognise by name.
Numbers rather than adjectives
Response-time budgets, timeouts and thresholds are named, not left as 'should be fast'.
Cache interactions flagged
Where a full-page cache silently changes behaviour, the entry says so and says which path to exclude.
Wired to its neighbours
Webhook runs into API, Cron Job and Git — the terms that share a stack trace with it.
This term, landed
Webhook defined, budgeted, secured and located in your own account — enough to build against tonight.
Quick Start
From order to online
- 1
Verify the signature before anything else
Compute the HMAC over the raw body, compare it in constant time, and reject on mismatch. Do this before parsing, because a forged payload should never reach your parser.
- 2
Write the payload and return 200
Insert the raw body and the provider's event ID, then answer immediately. Target tens of milliseconds; anything past a couple of hundred is worth investigating.
- 3
Process on cron, keyed by event ID
Pick up unprocessed rows on the next tick and mark them done. The unique constraint on the event ID is what turns a duplicate delivery into a no-op.
Built In
Loaded onto every plan
- LiteSpeed caching built into the server rather than bolted on by plugin
- NVMe SSD storage on every tier, not only the expensive ones
- Free SSL on every plan, renewed automatically before it can lapse
- cPanel, so the cron editor and the raw access logs are where you expect them
- Per-site PHP version switching from the control panel
- WordPress and 400+ other applications installed in one click
- Browser webmail plus IMAP, POP and SMTP for any mail client
- Upgrades applied in place — changing plan is not a migration
- A renewal price identical to the one you signed up at
- DDoS filtering absorbed out at the network edge
Frequently Asked
What people ask us most often
How long does a handler have before the provider gives up?
Assume single-digit seconds and design for far less. The safe pattern is to verify, persist and return 200 in tens of milliseconds, then process on cron. Providers vary, and rather than memorise each one's limit it is easier to build a handler quick enough that none of them matter.
Why did the same event arrive twice?
Because the first acknowledgement did not reach the provider in time, so it retried. That is normal behaviour, not a fault. Store the provider's event ID with a unique constraint and check it before you act, and the second delivery becomes a no-op instead of a second order.
Should the endpoint be excluded from the page cache?
Yes, explicitly. A full-page cache in front of a POST endpoint can serve a stored response and skip your handler entirely, which produces the worst kind of bug: deliveries the provider records as successful that did nothing. Add the path to the cache exclusions, then confirm the response comes back without a cache hit header.
Is the included SSL certificate sufficient for a webhook endpoint?
Completely, on every plan. The certificate issues as soon as your domain points at us and renews itself long before expiry, and cryptographically it matches any paid DV certificate. The paid options exist for wildcard coverage or organisation validation, neither of which a webhook endpoint has any use for.
Keep reading
API (Application Programming Interface)
The outbound half of the same conversation, and the one that sits inside your own response time.
Git
Version control as a deployment mechanism — the thing most deploy webhooks are actually triggering.
Best LiteSpeed Hosting
What LiteSpeed changes about caching, and which paths you have to keep it away from.
Web Hosting
Fast cPanel hosting on NVMe drives — SSL, migration and a year-one domain all included.
Laravel Hosting
Laravel with Composer, SSH and Git-driven deploys, where queue workers have somewhere to run.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Give the endpoint faster ground.
NVMe storage, LiteSpeed in the server and cron you control — with support that reads a log rather than a script.
View Web Hosting plans