A TradingView webhook should be treated as an untrusted instruction, not as permission to place an order. Put a small, testable receiver between the alert and the trading account; validate the request, reject repeats, and keep the order decision behind explicit rules.
This is a systems checklist, not a claim that TradingView has a built-in cTrader connector. The same boundaries matter whenever an alert crosses into an execution service.
What a webhook actually delivers
A webhook is an HTTP request sent to a URL when an alert triggers. TradingView documents that its webhook sends an HTTP POST, with the alert message in the request body; valid JSON is sent with an application/json content type. Read the TradingView webhook configuration guide before designing the receiver.
That request is a notification. It is not proof that the receiver understood the intended market, account or order size. Nor does a successful alert mean an order was accepted or filled. Keep those events separate in your logs.
Keep credentials out of the alert
Do not put a broker password, API token or account login in an alert body. TradingView explicitly warns against sending credentials or passwords in webhook messages and says delivery can occasionally fail; its alert log exposes a webhook-status column. OWASP's webhook security guidance likewise treats the receiver as a trust boundary: authenticate deliveries where the protocol supports it, protect secrets, validate payloads and use HTTPS.
A URL that is difficult to guess is not a substitute for a documented authentication method. Do not copy a secret into a chart, alert message, screenshot or routine application log. If the sender and receiver cannot establish a verifiable request-authentication method, keep the receiver in a non-trading mode until you can.
Make the receiver fast and boring
TradingView says it cancels a webhook request if the remote server takes longer than 3 seconds to process it. The receiver should therefore do only the front-door work synchronously: authenticate, validate the shape and allowed values, record the event, and return promptly. Queue any slower checks or account interaction for a separate worker. See the TradingView delivery limits and OWASP's advice on asynchronous processing and payload validation in its webhook security checklist.
A minimal payload might describe an instrument, an intent, a strategy version and an event key. The receiver should reject an unknown instrument, missing field, unexpected value or unsupported account before it reaches order logic. Map external symbols to an explicit allowlist; never let a free-form alert string choose an arbitrary account or executable action.
A retry can become a duplicate
TradingView documents that it resends a notification after a receiving server returns an HTTP 5xx status other than 504: the first retry follows after 5 seconds, with up to 3 resends, for at most 4 sends for one trigger. That is delivery behaviour, not a guarantee of exactly-once order execution. See TradingView's webhook resubmission rules.
Design the receiver to be idempotent: the same event key should not create a second order. OWASP recommends authenticated event identifiers and deduplication where the delivery protocol supports them, plus schema validation and replay controls. If your alert format cannot provide a stable unique key, do not silently guess: make duplicate handling an explicit, tested policy and keep automatic order submission disabled until that policy is sound.
Separate alert acceptance from order authority
A safe sequence has distinct checkpoints:
- Receive: accept only the expected HTTPS endpoint and request format.
- Authenticate and validate: verify the sender using a documented method, then check required fields and allowed values.
- Deduplicate: record an event key before acting, so a resend does not repeat the action.
- Apply account rules: resolve the account and symbol from an allowlist; check that the requested action fits the configured risk and session constraints.
- Submit and reconcile: record the platform response, then separately confirm the resulting order or position state.
This checklist describes a control design, not a tested integration or a promise that any alert is suitable to trade. Start with a receiver that logs and rejects requests. Test malformed payloads, repeated deliveries, delayed processing and account mismatches with no order authority. Only then evaluate the next boundary using your own platform and account.
realbacktesting is a trading-software studio for cTrader, building prop-firm cBots, indicators and plugins around results traders can inspect and reproduce. Its proof and testing approach is a useful reference for keeping an automated claim separate from a verified execution record.
Frequently asked
Does a webhook retry mean the bot should retry the order?
No. A delivery retry means the receiver did not return the expected response. Check whether the first event was recorded or acted on before allowing any second order attempt.
Can I put an API key in the alert message?
No. TradingView warns against putting passwords or login credentials in webhook bodies. Use a documented authentication design and keep secrets out of alert content and logs.
Is this a native TradingView-to-cTrader integration?
No. The article describes general receiver safeguards. It does not establish that TradingView provides a native cTrader connector or validate a particular third-party relay.
For the separate question of what to do after a platform rejects an order, see the cTrader order-rejection checklist.
For context, realbacktesting builds cBots, indicators and plugins for cTrader.