_
Complete developer guide to connecting TradingView alerts to your own trading bot via webhooks. Covers Pine Script alerts, secure webhook receivers, order execution, risk checks, and production deployment.
tags: python, tradingview, crypto, tradingbots, webhooks, fastapi_
TradingView is still one of the best charting and signal platforms available. Many developers already have working Pine Script strategies or indicators they trust. The missing piece is reliable, automated execution.
This guide shows you how to turn TradingView alerts into real orders using webhooks and a custom bot. We’ll cover:
- Writing alerts that send structured data
- Building a secure webhook receiver (FastAPI)
- Validating and parsing incoming signals
- Connecting the signals to exchange execution (CCXT for CEX, or your Solana executor)
- Adding risk checks before any order is sent
- Handling failures, retries, and logging
- Deploying the system so it stays online
The result is a clean separation: TradingView handles detection and charting, your bot handles risk and execution.
Note for memecoin traders: TradingView works well for larger-cap pairs and some Solana tokens that have reliable data feeds. For pure low-cap memecoin sniping and on-chain filters, you will still want dedicated listeners. If you need a complete memecoin-focused strategy framework, see https://selar.com/60lw5u0623. This article focuses on the TradingView → bot bridge that many hybrid systems use.
Why TradingView + Webhooks?
Advantages:
- Excellent charting and backtesting tools
- Large library of community scripts
- Alerts can fire on any condition you can code in Pine
- Webhooks let you push signals to any server you control
- No need to poll TradingView APIs constantly
Limitations:
- Alert frequency is limited by your TradingView plan
- Data quality on very new or low-liquidity memecoins can be poor
- You are still responsible for execution quality, slippage, and risk
This architecture is ideal when you already have a Pine Script edge and want reliable automation without rewriting everything in Python.
High-Level Architecture
TradingView Alert (Pine Script)
↓ HTTPS POST
Your Webhook Receiver (FastAPI / Flask)
↓ Validate + Parse
Risk Manager
↓ Approved
Execution Layer (CCXT or Solana bot)
↓
Exchange / DEX
↓
Logging + Telegram Alerts
Keeping these layers separate makes the system easier to debug and improve.
Step 1: Creating Useful Alerts in Pine Script
A good alert message is structured and machine-readable. Avoid free-text messages when possible.
Example alert message format (JSON-like):
{"strategy":"momentum_v2","symbol":"BTCUSDT","side":"buy","price":67250.5,"timeframe":"15","key":"YOUR_SECRET"}
In Pine Script you can build this with alert() or the newer alert_message parameter in strategy orders.
Simple example inside a strategy:
//@version=5
strategy("Webhook Example", overlay=true)
longCondition = ta.crossover(ta.sma(close, 14), ta.sma(close, 28))
if (longCondition)
strategy.entry("Long", strategy.long)
alert('{"strategy":"sma_cross","symbol":"' + syminfo.ticker + '","side":"buy","key":"YOUR_SECRET"}', alert.freq_once_per_bar)
For indicators (not strategies) you can use:
if longCondition
alert('{"side":"buy","symbol":"' + syminfo.ticker + '","key":"YOUR_SECRET"}')
Tips:
- Always include a secret key so your server can reject unauthorized requests
- Include symbol, side, and any extra context (timeframe, stop level, strategy name)
- Test alerts first with a service like webhook.site before pointing them at your real server
- Remember TradingView has rate limits on how many alerts can fire
Step 2: Building the Webhook Receiver
We will use FastAPI because it is fast, modern, and easy to secure.
pip install fastapi uvicorn python-dotenv httpx loguru tenacity ccxt
Basic receiver:
# main.py
from fastapi import FastAPI, Request, HTTPException, Header
from pydantic import BaseModel
import os
from dotenv import load_dotenv
from loguru import logger
import hmac
import hashlib
load_dotenv()
app = FastAPI(title="TradingView Webhook Bot")
WEBHOOK_SECRET = os.getenv("WEBHOOK_SECRET")
ALLOWED_IPS = os.getenv("ALLOWED_IPS", "").split(",") # optional
class AlertPayload(BaseModel):
strategy: str | None = None
symbol: str
side: str
price: float | None = None
timeframe: str | None = None
key: str
@app.post("/webhook")
async def tradingview_webhook(request: Request, payload: AlertPayload):
# 1. Basic secret check
if payload.key != WEBHOOK_SECRET:
logger.warning("Invalid secret key received")
raise HTTPException(status_code=403, detail="Forbidden")
# 2. Optional IP allowlist (TradingView publishes their IPs)
client_ip = request.client.host
if ALLOWED_IPS and client_ip not in ALLOWED_IPS:
logger.warning(f"Request from non-allowed IP: {client_ip}")
raise HTTPException(status_code=403, detail="Forbidden")
logger.info(f"Received alert: {payload.dict()}")
# 3. Pass to risk + execution
result = await process_alert(payload)
return {"status": "ok", "result": result}
Run it:
uvicorn main:app --host 0.0.0.0 --port 8000
For production you will put this behind Nginx or Caddy with HTTPS (Let’s Encrypt).
Step 3: Processing the Alert & Risk Checks
Never execute blindly. Always run risk checks first.
# risk.py
from loguru import logger
MAX_POSITIONS = 3
MAX_RISK_PER_TRADE = 0.02 # 2% of equity
DAILY_LOSS_LIMIT = 0.05
class RiskManager:
def __init__(self):
self.open_positions = 0
self.daily_pnl = 0.0
def approve(self, symbol: str, side: str, size: float) -> bool:
if self.open_positions >= MAX_POSITIONS:
logger.warning("Max open positions reached")
return False
if self.daily_pnl <= -DAILY_LOSS_LIMIT:
logger.warning("Daily loss limit hit — trading paused")
return False
# Add more checks: symbol whitelist, max size, etc.
return True
In the main flow:
async def process_alert(payload: AlertPayload):
# Normalize symbol (TradingView uses BTCUSDT, CCXT often wants BTC/USDT)
symbol = normalize_symbol(payload.symbol)
# Calculate size (example)
size = calculate_position_size(symbol)
risk = RiskManager()
if not risk.approve(symbol, payload.side, size):
return {"executed": False, "reason": "risk_rejected"}
# Execute
order = await execute_order(symbol, payload.side, size)
return {"executed": True, "order": order}
Step 4: Execution Layer
You can reuse the CCXT infrastructure from the earlier production bot article, or call your Solana executor.
Simple CCXT example:
import ccxt.async_support as ccxt
from loguru import logger
exchange = ccxt.binance({
"apiKey": os.getenv("BINANCE_KEY"),
"secret": os.getenv("BINANCE_SECRET"),
"enableRateLimit": True,
"options": {"defaultType": "future"} # or "spot"
})
async def execute_order(symbol: str, side: str, amount: float):
try:
order = await exchange.create_order(
symbol=symbol,
type="market",
side=side.lower(),
amount=amount
)
logger.success(f"Order placed: {order['id']}")
return order
except Exception as e:
logger.error(f"Execution failed: {e}")
raise
For Solana memecoins you would call your Jupiter or Raydium execution function instead.
Always:
- Log the full order response
- Send a Telegram notification on fill or failure
- Update your internal position tracker
Step 5: Security Best Practices
Webhook endpoints are public. Protect them properly:
- Shared secret in the alert message (as shown)
- IP allowlisting (TradingView publishes their outbound IPs)
- HTTPS only
- Rate limiting on your endpoint
- Request signature (more advanced — HMAC of the body)
- Idempotency keys so the same alert cannot trigger twice
- Run the receiver with minimal privileges
Example simple rate limiter with FastAPI middleware or a library like slowapi.
Step 6: Making It Production-Ready
Logging & Alerts
from loguru import logger
import sys
logger.add("logs/webhook_{time}.log", rotation="20 MB", retention="10 days")
logger.add(sys.stdout, level="INFO")
Send critical events to Telegram:
async def notify(message: str):
# simple httpx POST to Telegram Bot API
pass
Error Handling & Retries
Use tenacity for transient exchange errors. Catch specific exceptions (rate limits, insufficient funds, network issues) and decide whether to retry or alert.
Position Tracking
Keep a lightweight local state (Redis or even a SQLite file) of open positions so the bot knows what it currently holds. This prevents duplicate entries and helps with exit logic.
Health Checks
Add a simple /health endpoint that returns 200 if the bot is alive and can reach the exchange.
Deployment
Recommended path:
- VPS (Hetzner, DigitalOcean, etc.)
- Docker + Docker Compose
- Caddy or Nginx for automatic HTTPS
- Systemd or Docker restart policies
Example docker-compose.yml snippet:
services:
webhook-bot:
build: .
ports:
- "8000:8000"
env_file: .env
restart: unless-stopped
volumes:
- ./logs:/app/logs
Point your TradingView alert URL to:
https://yourdomain.com/webhook
Test thoroughly with the TradingView “Test” button and with small size live orders.
Advanced Patterns
Once the basic bridge works you can add:
- Multiple strategy support (different Pine scripts → different risk parameters)
- Exit alerts (separate webhook messages for closing positions)
- Dynamic position sizing based on TradingView-sent stop distance
- Paper-trading mode that logs signals without sending orders
- Multi-exchange routing (send BTC signals to Binance, SOL signals to your Solana bot)
- Confirmation candles or secondary filters before execution
Common Pitfalls
- Alert message format breaks when you change Pine Script
- Forgetting to normalize symbols (BTCUSDT vs BTC/USDT)
- No secret → anyone can spam your endpoint
- No risk checks → one bad alert can open oversized positions
- TradingView plan limits causing missed alerts
- Not handling partial fills or order rejections cleanly
- Running without HTTPS or proper authentication
When to Use This vs Pure On-Chain Bots
TradingView webhooks shine when:
- You trade liquid pairs with good TradingView data
- Your edge is chart/pattern/indicator based
- You already have working Pine Scripts
Pure on-chain / sniper bots are better when:
- You focus on brand-new memecoins
- You need block-level speed and custom filters
- Social + on-chain data is more important than classical technical analysis
Many serious traders run both systems side by side.
For a dedicated memecoin strategy that already includes filters, scoring, and risk rules, the framework at https://selar.com/60lw5u0623 remains the recommended starting point.
Final Checklist
- [ ] Pine Script sends clean, structured JSON messages
- [ ] Webhook secret is validated on every request
- [ ] HTTPS is enabled
- [ ] Risk manager runs before any order
- [ ] Execution errors are caught and alerted
- [ ] Positions are tracked
- [ ] Logs and Telegram notifications are working
- [ ] System restarts automatically on failure
- [ ] You have tested with small size
You now have a complete, production-oriented bridge between TradingView and your own execution engine. This pattern scales cleanly and keeps your strategy logic where it is easiest to maintain (Pine) while giving you full control over risk and order management.
Build carefully, size conservatively, and keep improving the risk layer — that is usually where the real durability comes from.
Related articles in this series
- Production-ready CCXT bot
- Solana memecoin sniper architecture
- Memecoin strategies: hype + on-chain signals
Resource
Top comments (0)