Debugging UnifyPort webhooks with webhook.site

What it actually does

webhook.site hands you a throwaway HTTPS URL the moment you open it. Anything posted to that URL — from a curl one-liner to a real production webhook — shows up in the dashboard with full headers, raw body, query string, and timing. No signup, no install. The URL persists for a week on the free tier, longer with a paid plan.

When to reach for it in a UnifyPort integration

The honest answer is: whenever you suspect the problem might be on our side, not yours. Concretely, three moments come up a lot:

• 1. First-touch sanity check. Before you've finished wiring your real handler, point the device's webhook endpoint at a webhook.site URL and trigger a test message. If the event lands, you know the connectivity, account binding, and provider session are all healthy.
• 2. Diffing a missing event. When your handler isn't seeing an event you expected (say a Telegram message.received), add a second target temporarily pointed at webhook.site. If it arrives there but not on your handler, the bug is in your code; if neither sees it, file a ticket with the delivery ID.
• 3. Inspecting fields you forgot existed. The dashboard shows the full normalized JSON we ship — including data.attendees, data.conversation.title, and other optional fields that don't appear in every event. Easier than re-reading the docs.

Spotting the X-Device-Signature

When a target has a signing secret configured, every delivery carries three custom headers:

You'll see all three rendered in webhook.site's Headers panel. To prove the signature is correct without writing code yet, copy the timestamp and raw body, then run them through our CyberChef walkthrough with your secret — the resulting hex should match the header byte-for-byte.

When not to use it

Anything that resembles production traffic: real customer messages, signing secrets you actually use, PII you don't want sitting on someone else's server. webhook.site URLs are guessable and public — assume anything you post there could be read. For longer-lived debugging on a real account, fold in smee.io or a self-hosted bin instead.

Alternatives we like

• Pipedream RequestBin — better when you need to watch a slower stream of traffic over hours.
• smee.io — forwards to localhost instead of just capturing; better for local-development loops.
• ngrok — full local tunnel with a built-in inspector at 127.0.0.1:4040. The one we open most during real development.

Common questions

Is webhook.site safe for production webhooks?

No. webhook.site URLs are guessable and the dashboard is public — anyone who knows the URL can read every captured request. Use it only for prototyping with throwaway secrets or non-PII test events. For long-running debugging on a real UnifyPort account, switch to smee.io or a self-hosted bin.

How long do webhook.site URLs last?

Seven days on the free tier; longer on paid plans. The URL stays valid until expiry or until you manually delete it from the dashboard — meaning a single bin can capture traffic across multiple test sessions without rotating.

Can webhook.site verify UnifyPort signatures automatically?

No. webhook.site only displays the X-Device-Signature header value — it doesn't recompute HMAC. To prove the signature matches, copy the timestamp and raw body from the bin into our CyberChef recipe with your signing secret; the resulting hex should be byte-for-byte identical to the header.