Signed Crypto Trading Signal Webhooks: Entry Signals and Alerts Straight to Your Bot

A trading signal that reaches your bot two minutes late is a different signal. So is one that anyone could forge by posting JSON to your endpoint. Buildix now sends Entry Signals and alerts as signed crypto trading signal webhooks, with delivery logs, retries and a test button, so a bot can act on them without polling and without trusting unverified payloads.

This replaces the old webhook channel, which only covered generic alerts and sent a plain payload with no signature. The new system covers Entry Signals by timeframe, keeps generic alerts, and signs every event.

What Crypto Trading Signal Webhooks Send

Every event has the same envelope: an event id, an event type, a version number, a creation timestamp and a data object. The id is stable, so if the same event arrives twice because of a retry, your bot can drop the duplicate by id instead of opening a second position.

Two event types matter for most setups. The first fires when a new Entry Signal is published for a symbol and timeframe you follow, filtered by the minimum grade you set, so a bot that only trades B grade or better on the 15 minute chart never sees the noise below that line. The second fires when one of your price, funding or open interest alerts triggers, which is useful for bots that manage exits or hedge around funding flips rather than hunting entries.

Events for HIP-3 stock and commodity perps include a session field, so the payload tells your bot whether the signal fired during the US regular session or while the cash market was closed. For equity perps that distinction changes how much weight a signal deserves.

HMAC Signatures and Replay Protection

Each endpoint gets its own signing secret, generated when you create it and shown once. Buildix signs every request body with HMAC SHA-256 and sends the signature and a timestamp in the headers. Your receiver recomputes the signature with the same secret and rejects anything that does not match or that is too old.

In practice this closes the two cheapest attacks on a signal-driven bot. Nobody can forge a buy signal by posting to your URL, because they do not have the secret. Nobody can capture a real event and replay it an hour later, because the timestamp falls outside the accepted window. Treat the secret like an exchange API key: keep it in your environment, never in code you commit.

The developer docs describe the full payload schema and the signature check, so there is no guessing about field names, types or how the signed string is built. Verifying a signature takes a handful of lines in any language with a standard HMAC library.

Retries, Delivery Logs and Test Events

Networks fail. When your endpoint times out or returns an error, the event goes into a retry queue with increasing delays instead of being lost. A receiver that restarts for a deploy or drops for thirty seconds still gets the events it missed, and the stable event id means those late deliveries are safe to process once and discard if already seen.

Every endpoint has a delivery log with the latest attempts: status, HTTP code and latency. When a bot misses a trade, the log answers the first question in seconds. Either the event was delivered and the bot ignored it, or it was never delivered and the log says why.

A test button sends a sample event to your endpoint with a valid signature. It is the fastest way to confirm that your receiver parses the envelope and verifies the signature before you connect it to anything that trades.

Limits Built Into the Webhook System

A webhook system is also an outbound request machine, and without limits it can be abused. Endpoints must use HTTPS, private and internal network addresses are blocked, redirects are not followed and every request has a short timeout. Each endpoint has a cap on pending events, each account has a daily event ceiling and the alert channel has a minimum cooldown between repeated fires.

None of these limits get in the way of normal use. A bot following Entry Signals on a dozen symbols across two timeframes stays far below every ceiling. The caps exist so that a misconfigured alert or a hostile URL cannot turn the system into a flood.

Who Gets Webhooks and How to Wire Them to a Bot

Webhooks for Entry Signals and alerts are available from the Pro tier, with up to 5 endpoints on Pro. You create an endpoint from the alerts dashboard, copy the secret once, pick the event types and filters, and send a test event.

A minimal setup for an execution bot looks like this. Receive the POST, verify the signature and timestamp, drop duplicate event ids, check that the symbol and grade match your rules, then pass the signal to your own risk logic. Keep execution on your side: the webhook tells you what the orderflow says, and your bot decides size, stop and whether to trade at all. A webhook is an input to your system, not a replacement for it.

Configure endpoints on the Buildix alerts dashboard, and read the payload schema and verification code in the developer docs before going live.

The difference between a signal service and a signal feed a bot can trust is mostly plumbing: signatures, ids, retries and logs. That plumbing is now in place.