Kkiteob

Webhooks help

Kite postback, TradingView payload formats, secrets, and how to verify orders.

Your webhook URLs

Use these values in Kite Connect and TradingView for this deployment.

Kite postback

TradingView webhook

Kite postback (Zerodha order updates)

Register the HTTPS postback URL from the dashboard in Kite Connect. The app must be served over HTTPS— local http://localhost URLs cannot be used as the live Kite postback. Set KITE_POSTBACK_URL to a tunneled HTTPS endpoint (e.g. ngrok) or deploy behind HTTPS.

TradingView webhook

Use POSTto your app's TradingView webhook URL with either:

  • Plain text — five fields separated by double underscores __:{{ticker}}__{{strategy.order.action}}__{{strategy.order.price}}__{{interval}}__{{timenow}}
  • JSON — structured fields that map to Kite place-order parameters.

Authentication

If a secret is configured (TRADINGVIEW_WEBHOOK_SECRET or MongoDB kite_webhook_access.webhookSecret), send Authorization: Bearer <secret> on every request. For JSON bodies only, you may alternatively send webhook_secret in the JSON; it is stripped before events are stored.

Live endpoint (store + place order)

The live URL persists each payload and attempts to place an order when mapping succeeds. You need KITE_ACCESS_TOKEN, or MongoDB plus opening this app in the browser while logged into Kite so the session token is synced for server-side webhooks.

Testing and cross-check

  • Live saves each payload server-side (e.g. webhook_events). Compare that row to the HTTP response (data.order_id vs message) and to Kite postbacks (or your broker UI) to confirm the order was accepted.
  • One TradingView alert should correspond to one Kite order. Long is usually BUY to open and SELL to close; short (e.g. MIS) is SELL to open and BUY to close. Your strategy must send the correct action each time — this app does not track position or flip direction for you.

Back to overview