There are two ways to find out that price crossed a level. You can ask repeatedly until the answer changes, or you can register once and be told. The first is what most people build, because it is the obvious thing, and it is the more expensive of the two by a wide margin.
Polling costs you a request every interval whether anything happened or not. It also decides your own latency: you find out at the next poll, not at the crossing. Narrow the interval to fix that and the request count climbs again.
What a standing watch looks like
A standing alert is a condition you register once — a coin or a ticker, a level, and a direction. It is then evaluated by the thing that already computes the map, on every publish. When it is met, your endpoint receives a POST.
That inverts the cost. The evaluation happens where the data already lives, and you spend nothing until something actually occurs.
Verify the delivery
Anything that POSTs to a public URL has to be checkable, or anyone who learns the URL can send you a fake fire. Each delivery carries an HMAC-SHA256 signature over the raw request body, in a header. Compute the same HMAC with the shared secret and compare before you act on it. A delivery that does not verify is not yours.
The secret is shown once, at registration, and never returned again. That is deliberate: a secret you can read back is a secret anyone with read access can read back.
Conditions worth watching
The obvious one is a price level. The more interesting ones are structural — a named level like a flip zone rather than a fixed number, so the watch follows the book as it moves rather than a number you chose yesterday.
A condition that could never fire is worth catching at creation rather than at three in the morning. An alert set on a coin with no options book, or a named level on an instrument that does not publish one, should be refused with a reason when you create it, not silently accepted and never heard from again.