TradingView alert to a real options order: picking the strike when the alert doesn't say

A TradingView strategy knows when to go long. It does not know which contract. The alert it fires says SPY, long, maybe a price, and then it is someone's job to turn that into BTO SPY 23 Oct 770C. Most of the time that someone is a human with a mouse, and the contract they pick at 9:31 is whatever their eye lands on in the chain.

This post is about taking that decision out of the moment and into a rule set, so an alert that says nothing about strikes still comes back as a specific, consistent order. I build Nyria, which is where I run this; the method is general.

What the alert carries, and what it doesn't

A minimal alert from a TradingView strategy, as the webhook sends it:

{
  "action":    "open",
  "direction": "long",
  "ticker":    "{{ticker}}"
}

Three fields. No strike, no expiry, no quantity, no order type. You could put them in: Pine can emit {{close}}, and you can hard-code an offset into the message. But a strike written into an alert goes stale the moment the underlying moves, and a hard-coded expiry is wrong by Tuesday. The alert is the right place for the signal and the wrong place for the contract.

So the division of labour is: the alert says what and which way; a strategy-level rule set says which contract; the bot says how much and in which account.

The rule set

On Nyria these sit on the strategy as option settings, set once. Equivalent knobs exist in any serious self-built system; these are the ones that matter.

Strike selection. Either an offset from the money, such as 1 OTM, or a target delta, such as 0.30. Offset is simple and predictable. Delta adapts to volatility and is what most people actually mean when they say "a little out of the money". Pick one and stop choosing by hand.

Expiration. A range in trading days, 0 to 31 out. A 0DTE strategy sets it to 0. A swing strategy sets a window and takes the nearest listed expiry inside it. The alert never names a date; the rule does.

Order type. Market, or limit at the price the alert names. If the alert carries no price, market.

Sizing. This belongs on the bot, not the strategy, because the same strategy runs in a paper account and a live one at different sizes. A budget per entry does it: at $1.85 a contract, a $500 budget buys 2 contracts (one contract is 100 shares, and the bot never rounds up). The same strategy, deployed by a second person with a $2,000 budget, buys 10.

With those four set, the three-field alert above becomes:

BTO SPY 23 Oct 770C @ 0.52  x2

and the next alert tomorrow, with SPY at a different price, becomes a different strike and the same rule.

The cases where it should refuse

A strike-picker that always finds a contract is a bug. The rules have edges, and the order should not go out when the data cannot satisfy them. The refusals I want written down, in plain words, next to the alert that caused them:

• No delta available. The chain has no delta for the strikes in range, so a delta target cannot be met. Nothing ordered.
• Nearest contract too far from target. The strategy asks for 0.30 delta and the closest available is 0.62. Common in the last hour of a 0DTE session. Nothing ordered.
• No live quote. The contract the rule picked has no bid and ask. Nothing ordered.
• Outside hours. The alert arrives before 9:30 ET, after 4:00 ET, or on a holiday.
• One contract costs more than the budget per entry. "One SPY contract costs $185, more than this bot's $150 budget. Raise it to at least $185."

Each of these is a decision the human used to make silently and badly at 9:31. Writing them as refusals means you see them, on paper, before any of them costs money.

Exits

Exits come from exit alerts, matched leg for leg against what the bot holds. The strategy's exit fires {"action": "close", "direction": "long", "ticker": "SPY"} and the bot sells the contract it opened, not a fresh pick from the chain. STC SPY 770c, written by a person in a Discord channel, does the same thing.

Nothing waits at the broker between alerts. For a 0DTE strategy that has one hard consequence: a contract still open at 4 PM ET expires at the broker, and the exit alert has to arrive before the bell. Build the exit into the strategy's own logic, where the entry already lives.

Spreads

The same rule set extends to multi-leg orders: up to four legs on one expiration, each leg the same quantity, placed as one order. Verticals, iron condors, straddles. Ratio spreads, calendars and diagonals are not in scope, and I would be suspicious of any alert-driven system that claimed to do them from a three-field message.

Running it, paper first

The order of operations that has saved me the most:

1. Create a strategy that trades options, TradingView as the source. Copy the webhook URL it shows into the TradingView alert.
2. Set the option settings: strike rule, expiry range, order type.
3. Paste a real alert, press Check format, read back the ticker, strike, expiry and side it found. Fix the strategy, not the alert, if any of them is wrong.
4. Deploy a bot on Nyria Paper with a budget per entry. Free, no card.
5. Let a week of alerts fire. Read every fill and every refusal on the Logs tab.
6. Deploy a second bot on the broker account with the same sizing.

Step 5 is the one people skip. It is also the only step that tells you whether your strike rule picks the contract you would have picked, or the one you should have.

Where to start

Free account at nyria.io, a strategy with TradingView as the source, option settings set once, a paper bot. The first alert that says only long and comes back as a specific contract is the whole argument.