TradingView Webhook Error 415, 400, 401, 403 and 429 Explained
A TradingView webhook error such as 415, 400 or 429 is the receiving service's answer to your alert, not TradingView's verdict on it. TradingView sends the request, the service at your webhook URL decides what to do with it, and the number that comes back tells you which side to fix: a 4xx code means the receiver read the request and refused it, while a 5xx code means the receiver itself failed.
You will find the code under Alerts → Log, in the Webhook status column for each trigger. This guide explains the codes TradingView users run into most often, what usually causes each one, and how PineHook replaces bare status codes with an explanation you can act on.
What TradingView actually sends#
Most webhook errors become easier to read once you know what the request looks like. TradingView's webhook guide documents that every alert goes out as an HTTP POST from one of four published IP addresses, to port 80 or 443 only, and that the receiver has three seconds to answer before TradingView cancels the request.
The body of that request is whatever text sits in the alert's Message box. When the text is valid JSON, TradingView labels the request application/json, and when it is anything else, including JSON broken by a single stray character, the request goes out as text/plain. That one rule explains almost every 415 error.
TradingView webhook status codes at a glance#
| Code | Meaning | Usual cause |
|---|---|---|
| 200 | Accepted | The receiver took the message, though it may still refuse the trade later |
| 400 | Bad request | The message is malformed or a value is invalid |
| 401 | Unauthorized | A missing, wrong or expired key, token or license |
| 403 | Forbidden | The receiver does not accept requests from this sender |
| 404 | Not found | A wrong path in the webhook URL |
| 413 | Payload too large | The message exceeds the receiver's size limit |
| 415 | Unsupported media type | The receiver wants JSON and the message was not valid JSON |
| 422 | Unprocessable | A valid format with a field the receiver cannot act on |
| 429 | Too many requests | A rate limit or capacity limit was reached |
| 5xx | Server error | The receiver failed, and TradingView may retry |
TradingView webhook error 415#
A 415 appears when the receiver only accepts JSON and TradingView sent text/plain. Since TradingView picks the content type by checking whether the message parses as JSON, the real problem is almost always in the message text rather than in any header you could change, and these are the culprits to look for:
- curly quotes (“ ”) in place of straight quotes ("), usually introduced by pasting from a word processor or a notes app,
- a trailing comma after the last field,
- text before the opening brace or after the closing one,
- a placeholder that produces an unquoted word inside a value, such as a ticker in a field with no quotes around it.
Paste the message into any JSON validator with the placeholders replaced by sample values, fix whatever it reports, and save the alert again. If the receiver also accepts plain text, sending plain text on purpose avoids the problem altogether, which is the approach PineHook takes.
TradingView webhook error 400#
A 400 means the receiver could not use the message it was given. The usual reasons are a missing field, a misspelled parameter, a value that should be a number but is not, or a TradingView placeholder such as {{close}} that never expanded because of a typo in its braces. A bare 400 does not say which of these it was, so read the response detail if the receiver provides one, and otherwise compare the message TradingView sent against the receiver's documented format one field at a time.
Errors 401 and 403#
A 401 means the receiver did not recognise the credential in the message or the URL. Copy the key or token again from the receiver's dashboard rather than retyping it, and confirm that the subscription or license behind it is still active. A demo key used on a live alert is a frequent version of this mistake.
A 403 usually means the receiver recognised the request but will not accept it from this source. Services that check the sender's IP address against TradingView's published list answer anything else with a 403, which is why a test sent from your own computer with a tool like curl can fail while the identical message from TradingView succeeds.
Errors 404, 405 and 413#
A 404 means the URL's host answered but the path does not exist, so look for a missing or extra segment, a stray trailing character or an outdated URL format. A 405 means the path exists but does not accept POST requests, which usually happens when the URL points at a web page instead of the receiver's webhook endpoint. A 413 means the message is longer than the receiver allows, and long comments, repeated placeholders and full JSON objects copied from documentation are the usual causes, so remove anything the receiver does not read.
TradingView webhook error 429#
A 429 means the receiver is limiting how many alerts it accepts in a given period. A strategy that fires several alerts on the same bar, or several alerts sharing one key, can reach a per-minute limit quickly, so check the receiver's published limits and spread the alerts out where you can. TradingView does not retry a 429, which means any alert that received one did not run.
Errors 500 to 599 and timeouts#
A 5xx response means the receiver failed while handling the request. TradingView's resubmission rules say it resends after any response from 500 to 599 except 504, waiting five seconds between attempts for up to three resends per trigger. A retried alert can therefore arrive several seconds late, and a careful receiver should check that the entry still makes sense at the new price.
If the receiver takes longer than three seconds to answer, TradingView cancels the request and records the delivery as failed, and a timeout is not among the responses it resends. Depending on how far the receiver got before the cut-off, the order may or may not have been placed, so check the receiver's log and your broker's history before you send the same order by hand.
How PineHook replaces status codes with plain explanations#
A status code in TradingView's log tells you that something went wrong without telling you what, so PineHook keeps the codes short and puts the explanation where you will read it. PineHook reads the message body itself and recognises CSV or JSON automatically, which means it accepts both text/plain and application/json and never returns a 415 at all, so a plain CSV alert such as LICENSE,buy,EURUSD,size_lots=0.1 works exactly as written.
When PineHook does refuse an alert, the refusal lands in the Rejected panel of Signal Logs with the faulty parameter highlighted. Next to it is a sentence that says what is wrong and how to fix it, such as a stop loss on the wrong side of the entry or a misspelled parameter. The remaining codes keep their usual meaning: 401 means an unknown or inactive license key, 402 means the alert used a feature your plan does not include, 403 means the request did not come from TradingView's published addresses, and 413 means the message is over 2,048 bytes. Every message and its fix is listed in Alert error messages.
PineHook can also answer 200 with a blocked status, for example when Signal Authentication is on and the alert has no auth= value, or when one of your symbol filters excludes the symbol. TradingView shows those alerts as delivered, but the Signal Logs row names the exact setting that stopped the trade, which webhook delivered but no trade explains in more detail. You can create a PineHook account without payment details and send a test alert to see the explanations for yourself.
FAQ#
Can I set the Content-Type header on a TradingView webhook?
No. TradingView sets the header from the message content as described above, so to send JSON you make the message valid JSON, and to send plain text you use a receiver that accepts it.
Will TradingView resend an alert that got a 400 or 429?
No. Only responses from 500 to 599 other than 504 are resent. The refused alert will never run on its own, so fix the cause before the next trigger.
Why do I get a 403 when testing a webhook with curl or Postman?
Many receivers, PineHook included, only accept webhooks from TradingView's IP addresses, so a request from your own machine is refused. Use the receiver's own test tools instead, such as Signal Logs → Alert Test & Validate in PineHook, which checks a message without placing a trade.
Related guides#
- TradingView webhook not working
- Webhook delivered but no trade on MT5
- Alert error messages
- PineHook alert command format
TradingView is a trademark of its owner, and PineHook is an independent product that is not affiliated with, endorsed by, or sponsored by TradingView. Leveraged trading carries a high risk of loss, so test any automated setup on a demo account before you trade it live.
