Webhooks
Push events to Discord, Slack, n8n or your own systems
Webhooks push events from Predite to your own server the moment they happen — no polling required. When a bot fills a trade, a stop-loss fires, or the scanner finds a new edge, Predite sends an HTTP POST to a URL you control. Webhooks are a Bot plan feature and are managed from Settings, on the Webhooks page.
Creating a webhook
You need three things: a URL that accepts POST requests, a label so you can tell your webhooks apart, and at least one event to subscribe to.
Your URL must be https in production. Predite refuses to deliver to private, loopback, or internal network addresses, and it will not follow redirects — this protects your account from a misconfigured endpoint being used to reach inside our infrastructure.
Events
Six events exist. Four are live today:
- •ev_signal — the scanner published a new Expected Value signal. Sent to every subscriber (not user-specific).
- •arb_opportunity — a new cross-platform arbitrage opportunity was found. Also sent to every subscriber.
- •bot_trade_executed — one of your bots opened a position, live or paper.
- •stop_loss_triggered — one of your protective exits (stop-loss, take-profit, or trailing stop) closed a position.
Two more are reserved and marked soon in the dashboard — whale_move and resolution_imminent. You can subscribe to them today, but they do not deliver anything yet.
Events about your own activity are only ever sent to you. Market-wide events are sent to everyone subscribed to them.
Payload format
Every delivery is a POST with a JSON body of this shape:
- •event — the event name, for example bot_trade_executed
- •timestamp — when the event happened, in ISO-8601
- •data — an object with the details for that event
Alongside it, Predite sends these headers:
- •X-Predite-Event — the event name
- •X-Predite-Timestamp — the same timestamp
- •X-Predite-Signature — the signature, formatted as sha256=<hex>
Verifying the signature
Each webhook has its own secret, shown in the dashboard and starting with whsec_. The signature is an HMAC-SHA256 of the raw request body, keyed with that secret, hex-encoded and prefixed with sha256=.
To verify, compute the HMAC of the body you received and compare it to the X-Predite-Signature header. If they do not match, reject the request — it did not come from us. Always verify before acting on a payload, and always use the raw body, not a re-serialized version of the parsed JSON.
Delivery, failures, and auto-disable
- •Each event is delivered as a single attempt with a 5-second timeout. There are no automatic retries — design your endpoint to respond quickly and do the slow work afterwards.
- •Any non-2xx response, timeout, or connection error counts as a failure.
- •After 10 consecutive failures, the webhook is automatically disabled and shows as AUTO-DISABLED. A single success resets the counter.
- •Re-enabling a disabled webhook from the dashboard clears the failure count.
Every attempt is recorded, so the dashboard shows total deliveries, consecutive failures, the last success, the last failure, and the reason it failed.
Good to know
- •Respond 2xx as soon as you have stored the event; anything slower risks the 5-second timeout.
- •Because there are no retries, treat webhooks as a fast notification channel rather than a guaranteed ledger — reconcile against the Public API if you need certainty.
- •You can pause a webhook at any time instead of deleting it.