A systematic checklist for debugging webhooks when alerts fire but the bot does nothing.
In plain English
This guide explains the message path between an event source and your backend. Treat every incoming request as untrusted until it has been authenticated and validated.
HTTP POSTendpointJSONevent_id
Debug one boundary at a time
- Sender: did the alert actually fire?
- Network: did your endpoint receive a request?
- Parser: was the body valid JSON?
- Authentication: did the token match?
- Schema: were required fields valid?
- Queue/backend: was the event forwarded?
- Broker: was it accepted or rejected?
Log reason codes, not vague messages
invalid_json
missing_event_id
bad_symbol
bad_action
bad_token
duplicate_event
backend_timeout
broker_rejected
broker_rate_limitedUse a known test payload
Keep one harmless payload that can be sent with curl or Postman. This separates “TradingView problem” from “receiver problem”. Use a dry_run flag so the path can be exercised without placing an order.
curl -X POST https://example.com/api/webhook \
-H 'content-type: application/json' \
-d '{"event_id":"test-001","symbol":"BTCUSD","action":"buy","dry_run":true,"token":"..."}'Practical lesson: timestamps are crucial. Without timestamps at each boundary, a five-minute outage can look exactly like a five-minute period with no signals.
Before you rely on this in production
- The sender is authenticated.
- JSON/schema validation happens before business logic.
- Duplicate and stale events are rejected.
- Logs show why an event was accepted or rejected.