Testing webhooks
How to exercise a consumer without waiting for real traffic.
In short
- Every account gets a test project; nothing you try there touches live traffic.
- A test event can be sent to one destination without publishing to everyone.
- Test projects may point at plain HTTP, which live projects may not.
Use the test project
Accounts open with two projects, live and test, each with its own keys, destinations and event log. New accounts land in test, so the first thing you try is not production traffic.
Send a test event to one destination
curl -X POST https://api.hookget.com/v1/endpoints/ep_…/test \
-H "authorization: Bearer $HOOKGET_KEY"This publishes a hookget.test event addressed to that destination only — useful
when you want to prove one consumer works without fanning out to the others.
Exercising the failure paths
The interesting tests are the unhappy ones. Point a test destination at a service you control and make it answer badly on purpose:
| Make it answer | What you should see |
|---|---|
| 500 | A retry scheduled, and the interval widening on each attempt |
| A slow response beyond the timeout | A timeout recorded as a failure, not a hang |
| 410 | The destination disabled immediately |
| Nothing at all (refused connection) | A connection error recorded with its class |
| 200 after several failures | The failure counter reset and the timeline showing the whole story |
Consumers should be tested against a wrong signature too. A verification function that has never returned false in testing is a verification function nobody has proven.