Fix TradingView Webhook 403 & 401 Errors: Step-by-Step Guide

Your TradingView alert fires. The webhook fires too. Then silence. Your bot never trades, your server logs a tradingview webhook 403 error or 401 error, and you’re left wondering what broke. You’re not alone. TradingView has over 100 million registered users and 50 million monthly active users, and a growing share of them run automated strategies that depend entirely on webhooks reaching a server cleanly. When they don’t, real money sits on the sideline.

This guide walks through every root cause of TradingView webhook 403 and 401 errors, with copy-paste server fixes for Nginx, Apache, Django, AWS, and Heroku.

What Is the Difference Between a TradingView Webhook 403 and 401 Error?

Broken authentication accounts for 29% of all API vulnerabilities. Both 403 and 401 look like “access denied” in your logs, but they mean completely different things and require different fixes. Mixing them up waste’s hours of debugging time.

Here’s the core distinction:

• 401 Unauthorized asks “Who are you?” Your server couldn’t verify TradingView’s identity. The credentials are missing, wrong, or expired.
• 403 Forbidden says “I know who you are, but you can’t come in.” Authentication passed (or wasn’t required), but something else is blocking access — a firewall rule, an IP filter, or a CSRF check.

This matters because fixing the wrong thing will never resolve your issue.

A useful mental model: a 401 is a bouncer asking for your ID. A 403 is a bouncer who checked your ID and told you the VIP list doesn’t include your name.

Why Does TradingView Send Webhooks From Specific IP Addresses?

TradingView sends all outbound webhook requests from a fixed set of IP addresses so receiving servers can verify the source. This is standard practice for webhook services, but it means your server’s firewall must explicitly allow those IPs. TradingView is the world’s number one most-visited investing website, so their infrastructure is designed for scale and reliability — but that design puts the allowlisting responsibility entirely on you.

TradingView’s 4 official outbound webhook IP addresses:

52.89.214.238
34.212.75.30
54.218.53.128
52.32.178.7

A few other requirements that catch people out:

• Ports: Only port 80 (HTTP) and port 443 (HTTPS) are accepted. Non-standard ports will fail silently.
• IPv6: Not supported. Your endpoint must resolve to an IPv4 address.
• Response timeout: Your server must return any HTTP 2xx response within 3 seconds. After that, TradingView considers the delivery failed.
• SSL certificate: TradingView identifies itself with a cert where CN = [email protected], Org = TradingView Inc.
• 2FA requirement: 2FA must be enabled on your TradingView account before you can send webhooks at all.

Miss any one of these and you’ll get a failed delivery — even if your server is otherwise healthy.

How to Fix a TradingView Webhook 403 Forbidden Error (Step-by-Step)

A 403 error is the most common issue developers hit when setting up TradingView webhooks, and the number one cause is almost always missing IP allowlisting. The global algorithmic trading market was valued at $21.06 billion in 2024 and is projected to reach $42.99 billion by 2030 — so getting these integrations right matters at scale.

Work through each cause below in order. Most people fix their problem at step one.

1. TradingView IPs Not Allowlisted (Most Common Fix)

Your server’s firewall or web server config is rejecting TradingView’s requests because it doesn’t recognize the source IPs. You need to add all four IPs.

Nginx fix — add this inside your server block, scoped to your webhook path:

location /webhook {
    allow 52.89.214.238;
    allow 34.212.75.30;
    allow 54.218.53.128;
    allow 52.32.178.7;
    deny all;

    proxy_pass http://your-app:8000;
}

Apache .htaccess fix:

<Location "/webhook">
    Require ip 52.89.214.238
    Require ip 34.212.75.30
    Require ip 54.218.53.128
    Require ip 52.32.178.7
</Location>

After updating, reload your web server. Don’t forget to restart — a config reload that fails silently will leave the old rules in place.

2. CSRF Protection Blocking the Endpoint

If you’re using Django, Rails, Laravel, or any modern web framework, CSRF middleware is probably on by default. TradingView doesn’t send a CSRF token. Your framework sees an unknown POST request and rejects it with a 403.

Django fix — decorate your webhook view:

from django.views.decorators.csrf import csrf_exempt
from django.views.decorators.http import require_POST

@csrf_exempt
@require_POST
def tradingview_webhook(request):
    # validate the secret token here instead
    payload = request.body
    # process alert...
    return HttpResponse(status=200)

Don’t just strip CSRF and leave the endpoint wide open. Validate a secret token in the request body or URL path instead.

3. Restrictive .htaccess Blocking Unknown POST Requests

Some shared hosting setups include blanket rules that block POST requests from unknown user agents or IP ranges. Check your .htaccess for rules like Deny from all or LimitExcept GET and ensure your webhook path is explicitly exempted.

4. Wrong Port

TradingView only sends to port 80 or 443. If your webhook URL uses :8080, :3000, or any custom port, TradingView will reject it before it even reaches your server. Move the endpoint behind a reverse proxy on port 443.

5. Wrong Token Scope

If you’re passing an API key in the webhook URL and that key only has read permissions, the server may return 403. Check that the token or API key attached to the webhook URL has write or execute permissions for the action it’s triggering.

From our experience: The single most common reason developers spend hours on this is checking token configuration first when the issue is actually a firewall rule. Always verify IP allowlisting before touching your auth config.

TradingView sends all webhook requests from four fixed IPv4 addresses (52.89.214.238, 34.212.75.30, 54.218.53.128, 52.32.178.7). Any server that doesn’t explicitly allowlist these IPs will return a 403 Forbidden response, blocking the alert delivery entirely.

How to Fix a TradingView Webhook 401 Unauthorized Error

A 401-error means authentication couldn’t be verified. The request arrived at your server, but your server doesn’t trust it. 65% of API breaches are driven by authentication flaws, which is why most production webhook setups require token validation. Here are the causes, from most to least frequent.

1. Missing or Wrong Secret Token

The most common pattern is to include a secret token in the webhook URL path, like:

https://yourserver.com/webhook/abc123secret

If that token is wrong, misspelled, URL-encoded incorrectly, or missing entirely, your server returns 401. Double-check the exact string in your TradingView alert URL matches what your server expects.

Also check for trailing slashes. abc123secret and abc123secret/ are not the same thing in most frameworks.

2. 2FA Not Enabled on Your TradingView Account

This one trips up a lot of developers. TradingView requires two-factor authentication to be active on your account before you can use the webhook feature at all. If 2FA is disabled, TradingView won’t send the webhook request, or your endpoint may never receive a valid request to begin with.

Go to TradingView Settings, then Security, and enable 2FA. This is a hard requirement, not optional.

3. Basic Auth Credentials Formatted Incorrectly

If your endpoint uses HTTP Basic Auth, the URL format must be exactly:

https://username:[email protected]/webhook

Common mistakes include special characters in the password that aren’t URL-encoded, or using the wrong separator. Encode the password with encodeURIComponent() if it contains @, :, /, or #.

4. Expired or Revoked API Key

If your server validates a Bearer token or API key from the request body, check that the key hasn’t been rotated or expired. This is more common on services like Firebase, Supabase, or custom Flask APIs where keys have expiry dates. Regenerate the key and update the TradingView alert URL.

5. Malformed Authorization Header on the Receiving Server

Some server configurations check for an Authorization header and return 401 if it’s absent. TradingView doesn’t send an Authorization header by default — it sends a plain POST with a JSON body. If your server middleware requires that header, move authentication into URL path token validation instead.

38% of organizations encountered authentication issues in production APIs in the past 12 months. For TradingView webhooks, the most common form of this is a secret token mismatch between the alert URL and the server’s expected value.

Click Here To Automate Futures Trading

Platform-Specific Webhook Fixes for Nginx, Apache, AWS, Django, and Heroku

45% of retail traders now use automated or algorithmic strategies, and each one runs on a different tech stack. Here are ready-to-use configurations for the five most common platforms.

Nginx

location /webhook {
    allow 52.89.214.238;
    allow 34.212.75.30;
    allow 54.218.53.128;
    allow 52.32.178.7;
    deny all;

    proxy_pass http://127.0.0.1:8000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_read_timeout 10s;
}

Apache .htaccess

<Location "/webhook">
    <RequireAny>
        Require ip 52.89.214.238
        Require ip 34.212.75.30
        Require ip 54.218.53.128
        Require ip 52.32.178.7
    </RequireAny>
</Location>

AWS API Gateway Resource Policy

Add this as an API Gateway resource policy to restrict access to TradingView IPs only:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": "arn:aws:execute-api:us-east-1:*:*/prod/POST/webhook",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "52.89.214.238/32",
            "34.212.75.30/32",
            "54.218.53.128/32",
            "52.32.178.7/32"
          ]
        }
      }
    },
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": "arn:aws:execute-api:us-east-1:*:*/prod/POST/webhook",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": [
            "52.89.214.238/32",
            "34.212.75.30/32",
            "54.218.53.128/32",
            "52.32.178.7/32"
          ]
        }
      }
    }
  ]
}

Django

from django.views.decorators.csrf import csrf_exempt
from django.http import HttpResponse, HttpResponseForbidden
import json, hmac, hashlib

WEBHOOK_SECRET = "your-secret-token-here"

@csrf_exempt
def tradingview_webhook(request):
    if request.method != "POST":
        return HttpResponseForbidden()

    # Token validation via URL path is simplest for TradingView
    token = request.GET.get("token", "")
    if not hmac.compare_digest(token, WEBHOOK_SECRET):
        return HttpResponse(status=401)

    payload = json.loads(request.body)
    # handle the alert here
    return HttpResponse(status=200)

Heroku

Heroku doesn’t offer native IP filtering. Use a token-in-URL validation approach instead:

import os
from flask import Flask, request, abort

app = Flask(__name__)
WEBHOOK_TOKEN = os.environ.get("WEBHOOK_TOKEN")

@app.route("/webhook/<token>", methods=["POST"])
def webhook(token):
    if token != WEBHOOK_TOKEN:
        abort(401)
    data = request.get_json()
    # process alert
    return "", 200

Set WEBHOOK_TOKEN as a Heroku config var. Your TradingView alert URL becomes https://yourapp.herokuapp.com/webhook/your-secret-token.

How to Test Your TradingView Webhook Is Working Before Going Live

Testing saves you from discovering problems during a real trade. With 70-80% of global equity trading volume now algorithmic, production failures carry real financial consequences. Test each layer before connecting a live alert.

Step 1 — Test Your Endpoint Directly With curl

Before involving TradingView at all, simulate a webhook POST from your local machine:

curl -X POST https://yourserver.com/webhook/your-secret-token \
  -H "Content-Type: application/json" \
  -d '{"action": "buy", "ticker": "BTCUSDT", "price": "65000"}' \
  -w "\nHTTP Status: %{http_code}\n"

You want HTTP Status: 200. If you get 403 or 401 here, the problem is your server config — not TradingView.

Step 2 — Test From TradingView’s IP Range Using a VPS or Proxy

Your local machine’s IP is different from TradingView’s. A rule that passes your curl test might still fail when TradingView sends it. Rent a $5 VPS on DigitalOcean or use a cloud function, assign it one of TradingView’s known IPs (or test from any external IP to verify there’s no IP-based block active beyond what you configured), and rerun the curl test.

Step 3 — Use a Webhook Inspection Tool

Services like webhook.site or RequestBin give you a temporary URL you can paste into TradingView’s alert webhook field. They capture the raw request so you can see exactly what TradingView sends — headers, body format, IP address. This is invaluable for debugging.

Step 4 — Use TradingView’s Built-In Alert Test

When creating or editing an alert in TradingView, there’s a “Test” or “Send” option that fires the webhook immediately. Use this to trigger a test delivery and watch your server logs in real time.

# Watch your server logs live during test
tail -f /var/log/nginx/access.log
# or for Apache
tail -f /var/log/apache2/access.log

A successful delivery shows a POST /webhook 200 line with one of the four TradingView IPs as the source.

How to Prevent TradingView Webhook 403 and 401 Errors Going Forward (Best Practices)

Key insight: Most webhook failures aren’t random — they cluster around deployment events: server migrations, SSL certificate renewals, framework upgrades that reset middleware, and key rotations. The single most effective prevention is a post-deployment checklist that re-validates every item below.

Here are seven practices that keep webhooks running clean:

1. Always use HTTPS on port 443. Plain HTTP on port 80 works, but a TLS certificate gives you an extra layer of verification. TradingView itself connects over HTTPS.

2. Keep your IP allowlist current. TradingView’s four IPs have been stable, but check the official support page after any major TradingView platform update.

3. Include a secret token in every webhook URL. It doesn’t need to be complex. A 32-character random string like openssl rand -hex 16 is enough. Store it in an environment variable, never in source code.

openssl rand -hex 16
# example output: 4a3b2c1d8e7f6a5b4c3d2e1f0a9b8c7d

4. Respond within 3 seconds. If your webhook handler does heavy processing — placing orders, querying databases, sending notifications — do the processing asynchronously. Return 200 OK immediately, then handle the work in a background job or queue.

5. Enable 2FA on your TradingView account. It’s a hard requirement. Without it, webhook delivery simply won’t work.

6. Rotate secret tokens on a schedule. Quarterly rotation is a reasonable minimum. Update the token in your TradingView alerts and on your server at the same time.

7. Add rate limiting to the webhook endpoint. Even with IP allowlisting, adding a rate limit protects against misconfigured alert loops that could fire hundreds of times per minute.

# Nginx rate limiting for webhook endpoint
limit_req_zone $binary_remote_addr zone=webhook:10m rate=30r/m;

location /webhook {
    limit_req zone=webhook burst=10 nodelay;
    allow 52.89.214.238;
    allow 34.212.75.30;
    allow 54.218.53.128;
    allow 52.32.178.7;
    deny all;
    proxy_pass http://127.0.0.1:8000;
}

Frequently Asked Questions

What to Fix First: Your Quick Reference Checklist

TradingView webhook 403 and 401 errors almost always come down to a small set of fixable causes. A 403 points to IP allowlisting, CSRF protection, or a firewall rule. A 401 points to a missing or wrong token, 2FA not being enabled, or an expired API key. With 150,000+ community scripts published on TradingView and millions of automated strategies running, this is a problem the community has solved well — the fixes are known, they’re specific, and they work.

Start with the checklist: allowlist all four TradingView IPs, confirm 2FA is on, validate your secret token, and make sure your server responds in under 3 seconds. Run a curl test before touching your TradingView alerts. Most issues resolve at that stage.

If you’re building a more robust trading system, make sure your webhook endpoint follows the platform-specific config for your stack — don’t assume defaults are safe.

Disclaimer:
This content is for informational purposes only and does not constitute financial, investment, or trading advice. Trading and investing in financial markets involve risk, and it is possible to lose some or all of your capital. Always perform your own research and consult with a licensed financial advisor before making any trading decisions. The mention of any proprietary trading firms, brokers, does not constitute an endorsement or partnership. Ensure you understand all terms, conditions, and compliance requirements of the firms and platforms you use.

Also Checkout: TradingView to Interactive Brokers Automation: The 2026 Guide