For developers
Signing secret generator
Make a whsec_ webhook signing secret shaped exactly like ours, with its .env line, for testing a local receiver before a real endpoint exists.
Free, no accountIn your browser
Names the .env line below. A new secret is made every time you type, so copy it once the label reads right.
Result
Nothing generated yet
Say what this secret is for and one is made as you type.
What this is
This webhook signing secret generator makes a random whsec_ secret in your browser, shaped the way a real one is, so a local receiver can be tested before a live endpoint exists in the dashboard.
A webhook signing secret only exists so your own endpoint can prove a delivery really carries ResellerHQ's HMAC-SHA256 signature. Every endpoint created in the dashboard gets its own, shown once at creation and never again, in exactly this "whsec_" plus base64 shape - this page reproduces that shape locally so a receiver's parsing code can be built and tested before a real endpoint exists at all.
How to read the result
The secret above is random, made in your browser the moment you type a label, and never sent anywhere - paste it into whatever local script is signing a test payload and verifying against it. The .env line below names its variable off your label, so a project exercising more than one receiver keeps several of these straight instead of one shared variable getting overwritten by the next one generated.
"Verifying one of our webhooks" labels a secret made this way as local-testing-only, the same way this page does, then uses one in its own worked examples of recomputing a signature by hand in bash, Python and Node, and of reading the idempotency key generator's matching output.
Common mistakes
What goes wrong most often, and how to tell.
- Treating a page-made secret as the real oneA secret generated here only ever exists in this browser tab; it was never sent to ResellerHQ and ResellerHQ never signs a delivery with it, so verifying a genuine delivery against it fails every time, however correctly the verification code itself is written.
- Losing a secret before it is saved anywhereNothing typed or generated on this page is stored once the tab closes - there is no history to come back to. Copy the secret and its .env line into the project the moment the label reads right, the same way you would the one the dashboard shows exactly once.
Questions
What people ask about this tool.
- Every secret, real or generated here, is the literal prefix "whsec_" followed by 24 random bytes encoded as base64 - the same convention the wider Standard Webhooks ecosystem uses for a signing key, which is why libraries built against that specification already know what to expect.
- No. ResellerHQ signs a real delivery with the secret shown once in the dashboard at the moment an endpoint is created, which this page has no way to see or reuse - a secret generated here only ever matches a payload signed with that same value, for a local test receiver.
- Open Developers in the dashboard and create a webhook endpoint; its signing secret is shown exactly once at that moment, and is the only one ResellerHQ will ever use to sign a delivery to that endpoint - copy it immediately, because the dashboard will not show it a second time.
- Yes - running "openssl rand -base64 24" on the command line produces the same 24 random bytes, base64-encoded, that this page does; add the "whsec_" prefix afterwards and the result is indistinguishable from what this page generates.
Sources
Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.
- Standard Webhooks, “Standard Webhooks - specification” read 13 October 2026
- OpenSSL, “openssl-rand(1) - generate pseudo-random bytes” read 13 October 2026
Use it from the API
The same check, as one request.