Webhooks: in (live) and out (planned)
The per-user inbound webhook Sarathi runs today, how TradingView alerts are parsed, and a planned outbound webhook on decision and fill with a proposed payload.
Updated 30 Aug 2026
LiveSarathi has one webhook today and it points inward: TradingView posts to a URL that belongs to you, and the post becomes an order card. A second webhook that points outward, from Sarathi to a server of yours, is planned. This page keeps the two clearly apart.
Inbound webhook Live
Every account gets a URL of the form https://<server>/hook/<token>, where the token is 24 hex characters. It is revealed in Settings during onboarding and again in the Telegram link confirmation. Paste it into the Webhook URL field of a TradingView alert; there is nothing to configure on the TradingView side beyond that.
What TradingView does on its end is documented in its webhook help page: an HTTP POST with the alert message as the body, an application/json header when the body is valid JSON and text/plain otherwise, ports 80 and 443 only, a three-second timeout after which the request is cancelled, no IPv6, and a small fixed set of source IP addresses listed in TradingView's webhook help. Webhook alerts require two-factor authentication on the TradingView account, and the alert log has a webhook status column for failed deliveries.
Sarathi acknowledges within the timeout and does the card delivery afterwards, so a slow Telegram round trip never causes TradingView to mark the post as failed.
The contract, in brief
| Step | What happens | Response |
|---|---|---|
| Token lookup | Token must match an account | 404 unknown token |
| Body size | 16 KiB limit | 413 |
| Parse | JSON object, or plain text such as BUY BANKNIFTY 30 sl=57400; numeric fields must be JSON numbers | 400 with the error and the first 200 characters received |
| Placeholder | Body is an unexpanded {{...}} placeholder, typically an exit order with no alert_message | 200 ok, ignored; no card |
| Universe | Symbol must resolve to an active instrument | 400 symbol not in universe with a hint listing tier-1 symbols |
| Dedupe | id, else symbol, side, strategy and time together | 200 duplicate: true; no card |
| Credits | Delivery charged 2 credits beyond the allowance | 200 with status: pending, or status: held when exhausted |
Field names and aliases (sym, side, type, price, sl, tp, qty, time, id), symbol normalisation (NSE:, BSE: and MCX: prefixes stripped, 1! and 2! suffixes stripped, GOLD to GOLDM, SILVER to SILVERM) and the full response bodies are on the developer page. A worked TradingView-side example is on the webhook alerts page.
A minimal body:
{ "sym": "BANKNIFTY", "side": "BUY", "type": "ORB", "price": 57530, "sl": 57400, "qty": 30, "time": "2026-08-27T09:20:00+05:30"}Rotation
If the URL leaks, rotate it from Settings. The old token stops resolving immediately and posts to it return 404. Update the TradingView alert with the new URL; alerts already fired are unaffected because they are already signals.
What a relay cannot do
Generic relays that forward a TradingView alert to a chat or an email pass the text through unchanged. They do not parse a side and a stop, do not know that BANKNIFTY1! and BANKNIFTY are the same instrument, do not reject a symbol you cannot trade, do not drop a duplicate, do not expire a stale signal, and do not record a decision. The inbound webhook exists to do those six things before a human sees a card.
Outbound webhook Planned
An outbound webhook would let Sarathi call a URL of yours when something happens to a signal: a card is delivered, a decision is made, a fill or rejection comes back, or a signal expires. Uses that have come up are a spreadsheet journal, a position tracker, and a second notification channel Sarathi does not offer.
Nothing about this exists yet. There is no settings field, no delivery, no retry policy. It is listed here so the connector map is honest about what is planned.
Proposed payload
The shape below is a proposal for discussion, not a contract. It mirrors the journal columns so a receiver can rebuild the journal from events alone. Numbers are JSON numbers, times are ISO 8601 with the IST offset, and every event carries the signal id so events can be joined.
{ "event": "fill", "signal_id": 142, "symbol": "BANKNIFTY", "side": "BUY", "strategy": "ORB", "decision": { "action": "confirm", "size_mult": 1, "via": "telegram", "at": "2026-08-27T09:21:14+05:30" }, "fill": { "route": "paper", "status": "filled", "qty": 30, "price": 57532.5, "slippage": 2.5, "order_id": "paper-8f2c" }, "fired_at": "2026-08-27T09:20:03+05:30"}Open questions before it could ship: signing (an HMAC header over the body is the likely answer), retries and their cap, whether signal.received events are included or only decisions and fills, and whether the raw alert body is ever forwarded. If you would use this, the shape you need is worth an email; it changes what gets built first.
Where the card goes
The inbound webhook produces a card on two surfaces: the Telegram bot and the web dashboard. Both carry the same four actions, and the decision is recorded once, whichever surface it came from.
Get started
Create an account, reveal your webhook URL in Settings, paste it into a TradingView alert, and send a test alert. The first card lands on the paper route within seconds, and nothing is placed until you tap Confirm.
Questions
No. TradingView posts the alert body to a URL you paste into the alert dialog. Sarathi only ever sees that request. Webhook alerts need a TradingView plan that includes webhook alerts (check the current plan page) and two-factor authentication on your TradingView account.
If the body carries an id, or a time together with symbol, side and strategy, the second post is recognised as a duplicate and answered with 200 without a second card. Bodies with neither field are treated as new signals each time.
Not yet. An outbound webhook on decision and fill is planned and not built. The payload shape on this page is a proposal, not a contract.
Related
- Telegram order cardsWhat a Sarathi order card looks like in Telegram, what the four buttons do, how linking and unlinking work, what is never sent, and how the web mirrors it.
- How TradingView webhook alerts workWhat TradingView posts when a webhook alert fires: placeholders, JSON rules, the 3 second timeout, secrets in the URL, and the failures that break a bridge.
- The pre-live checklist for a Pine strategyTen checks before a TradingView strategy's alerts reach a broker: v6 compile, repainting, alert payloads, sessions, sizing, paper trades and the journal.
- NSE F&O in Pine: sessions, lot sizes and expiriesIST session guards, last-entry cut-offs, NIFTY, BANKNIFTY and SENSEX expiry days, current lot sizes with sources, and MCX hours for GOLDM and SILVERM.
- Paper broker: how Sarathi simulates fillsWhat the paper route fills, what it skips, how the journal records a paper fill, and how to move to a live broker once an adapter ships.