Webhook key: securing your Autoview webhook
A webhook URL is only as private as the people who know it. Anyone who finds or guesses one, a leaked link, a scraped page, a misconfigured share, can send it a POST and it will be processed like any other alert. A webhook key closes that gap: it's an optional shared secret your alert has to carry, and a request without the right one never reaches your command.
What a webhook key actually does
When you set a key on a webhook, every request to that webhook has to include it somewhere in the payload. Autoview checks for the key before it parses anything else. No key, or the wrong key, and the request is rejected outright, no order gets placed, and nothing from the message body is read. It's a gate in front of your commands, not a setting inside them.
It's optional. A webhook works fine with no key set at all. Setting one is a recommended extra layer once your webhook URL exists anywhere outside your own head, not a requirement to get started.
The two ways to send it
There are exactly two places a webhook key can live in a request, and you only need to use one.
- In the webhook URL itself, as a query string: append
?key=yourkeyto the end of the link, for examplehttps://autoview.com/hook/<identifier>/?key=yourkey. Whatever sends the alert has to include this in the URL it posts to. - At the start of the alert message, as the first characters of the message body. Autoview checks whether the message begins with your key and, if it matches, strips it off before reading the rest of the command. Everything after the key is processed exactly as if the key weren't there.
Pick whichever fits how you're generating alerts. If your alert sender lets you edit the webhook URL directly, the query-string method is usually the simpler of the two. If it only lets you edit the message text, put the key at the front of that instead.
What happens when it's missing or wrong
A request with no key, when one is required, or the wrong key, gets rejected before Autoview reads any further. If your alerts are firing on the sending side but nothing is executing on the exchange, a mismatched webhook key is one of the first things worth checking, right alongside the usual suspects on the common error messages guide.
Setting or changing a webhook key
A webhook's key lives under that webhook's own Advanced configuration section, alongside its name. Set it when you create the webhook, or add one later to a webhook that doesn't have one yet. There's no separate approval step: save the change and every request after that point needs the new key.
A webhook key isn't tied to any particular alert sender. Whatever is generating your alerts, whether that's a charting platform's alert system, a script, or anything else that can send a POST, uses the same two methods above. Autoview doesn't care what sent the request; it only checks whether the key matches.