TradingView ↔ Plaid Bridgewebhook in · broker-native out · 4 signal types

A retail algo-trading product let users wire TradingView alerts directly to their brokerage. The V1 was a Zapier-grade pipeline: a webhook, a lambda, a broker call, a lot of hope. When it worked, it was magical. When it didn't, support got a screenshot of an unfilled order and a customer who had watched the market move without them.

The ask was for the bridge to stop being the weakest link. Authenticate the webhook, validate the signal, check that the user has the cash, place the order, log everything, and do all of it faster than the market can notice.

• End-to-end latency from TradingView webhook to broker acceptance under 250ms at p95.
• Plaid balance check on every non-trivial order — you do not want to learn about insufficient funds from the broker.
• Webhook authenticity verifiable from signature, not source IP. TradingView's egress IPs are not a stable contract.
• Idempotency across duplicated webhooks, flaky networks, and user panic-clicks.
• Clear, user-visible rejection messages — not just “order failed,” but why.

A Cloudflare Worker at the edge authenticates the webhook by HMAC signature and normalizes the payload into a canonical signal type (entry, exit, scale, flat). Invalid or replayed webhooks get dropped there — they never hit the origin.

Valid signals hit a Go service. It reads the user's current broker position, fetches a recent Plaid balance (cached aggressively, refreshed on rejection), runs a risk gate that enforces per-user limits and product-wide circuit breakers, and submits the order. Every step writes to a Postgres order ledger keyed on signal hash.

Idempotency is keyed on (user, symbol, signal-hash, window) — the same webhook fired twice within the de-duplication window gets exactly one order; outside the window it gets two, because that's what the user meant.

• Plaid freshness. Balances lag. A user deposits, sees their balance in-app, fires an order, and the bridge has a stale Plaid reading. We cache aggressively but bust on certain event types — and have a fallback path that accepts broker-side balance as authoritative.
• Partial fills. TradingView alerts are boolean. Brokers fill in pieces. The ledger has to represent “signal served” as a first-class state separate from “order filled.”
• Rejection UX. A rejection at the risk gate is a different user message than one at the broker. We built a small taxonomy of rejection reasons and surfaced them verbatim in-app.

Median webhook-to-broker time is 180ms. The risk gate rejects roughly 3.1% of incoming signals before they hit the broker — insufficient balance, circuit-breaker trip, stale signal, or product-level limit. Uptime has held at 99.97% over the last 180 days. Support volume related to “my alert didn't fire” is down by more than 80% since cutover.

I'd build a dry-run mode from day one. Users routinely want to wire a brand-new strategy and watch it would-have-fired for a week before going live. Retrofitting dry-run took a sprint; shipping it alongside the v1 would have taken two afternoons.