The moment you ask a service to deliver alerts to a URL you control, two separate security questions appear. Can you trust what arrives? And can the service be tricked into sending requests somewhere it should not?
Verify what arrives
Your endpoint is public. Anyone who learns the URL can post to it, and if your handler acts on the contents — posts to a channel, moves a position — that is a problem. The standard answer is a shared secret and a signature: the sender hashes the exact body with a secret only the two of you know, and sends the result in a header. You recompute it and compare.
Two details matter. Hash the raw body, before parsing, because re-serialising JSON changes bytes and breaks the comparison for no reason. And compare the result in constant time, because a naive comparison leaks the correct signature one character at a time to anyone patient.
A timestamp in the signed payload is worth having too. Without it, an attacker who captures one valid request can replay it forever.
The risk on the sending side
The other half is not your problem but it should influence who you buy from. A service that will POST to any URL a customer supplies can be pointed at private addresses inside its own network. That is server-side request forgery, and it is the reason a serious provider resolves the hostname and refuses addresses in private ranges before connecting.
It is worth asking a vendor how they handle it. Blocking a literal hostname is not an answer; a name that resolves to a loopback address is the actual attack, and only resolution catches it.
Assume it can be replayed
Design your handler so processing the same alert twice is harmless. Networks retry, and idempotence is cheaper than being certain they will not.