Connecting TradingView Alerts to Public.com
TradingView cannot place a Public.com order directly. Your alert POSTs to an endpoint you control, which authenticates to Public, translates the payload, and submits. Three things are specific to Public: multi-leg orders use a separate endpoint from single-leg orders, preflight endpoints let you validate before placing, and API access is granted under an Individual API Program stated to be for personal, non-commercial use — which matters when deciding who operates the receiver.
The pipeline is the same shape as any TradingView automation. What changes is what the receiving half has to do.
Read the program terms before you build
Public grants API access under the Individual API Program, described as being for your own personal, non-commercial use. The developer agreement prohibits providing third parties with the right to access the program, and Public reserves the right to limit, restrict, or terminate participation at any time without notice. A separate partnership track exists for companies integrating Public into a product other people use.
For a receiver you run against your own account under your own credentials, this is the individual case. For a service that receives other people's alerts and trades their Public accounts, it is not. Where a self-hosted tool falls depends on whose credentials and whose environment — a legal question rather than an engineering one, and worth putting to counsel before building rather than after.
Authentication, and the three-second problem
Public uses a secret key exchanged for a bearer token with a validity window measured in minutes.
TradingView cancels a webhook request that takes longer than three seconds. That budget does not accommodate authenticating, constructing an order, submitting, and waiting for confirmation. Keep a valid token warm on a background refresh cycle, acknowledge the POST immediately, and do the broker work behind the response.
Treat authentication failures as non-retryable. An endpoint that retries auth on every failed alert is generating failed logins at whatever rate alerts arrive, and the absence of a documented penalty is not evidence there isn't one.
Translating the payload
Leg count selects the endpoint. This is the structural difference most likely to break a port from another broker. Public places multi-leg orders through a dedicated endpoint distinct from single-leg placement, with a matching multi-leg preflight. Make that routing decision in one place in your code. A receiver that treats spreads as a variation on the single-leg path works until the first spread.
Do not decompose spreads. Separately submitted legs can partially fill, leaving unintended exposure, and they price independently rather than as a package. Public exposes a strategy quote endpoint precisely so a package can be priced first.
Symbols need resolving. The instrument identifier in a TradingView alert is not necessarily what Public expects. Treat symbol mapping as a step, not a passthrough.
Include position context. A payload saying sell cannot distinguish closing a long from opening a short. Pine Script strategy alerts can carry {{strategy.position_size}}; use it rather than inferring.
Preflight is your safety layer
Public exposes preflight endpoints for single-leg and multi-leg orders that validate an order without placing it. In an automated pipeline this is more valuable than it is for a human, because there is no confirmation screen — the assertion layer is the only thing between a malformed alert and a position.
Preflight, assert against your own risk parameters, refuse to submit on failure. An alert arriving over an unauthenticated channel should never determine position size unchecked; compute size from your own capital rules and treat the payload value as a suggestion.
Validating without a sandbox
No sandbox environment appears in Public's documented API surface. Verify current availability directly, but plan for its absence, because it removes the usual rehearsal step.
Assemble the equivalent: exhaust the read endpoints first, since accounts, positions, quotes, chains, and greeks are all non-destructive and exercise authentication and parsing. Then point the alert at a request inspector and confirm the payload arrives with an application/json content type and fully resolved placeholders. Then use preflight. Then trade small and live, sized so being completely wrong is affordable.
That last step is not a workaround anyone should be pleased with, and it is worth noting that brokers who do offer paper environments observe that small amounts of real money still surface issues simulations do not.
Order status without a push feed
With no streaming endpoint in the documented surface, order status is a polling problem. Poll at an interval matched to how quickly your strategy actually needs to react rather than as fast as you can, and back off with jitter on failure.
Persist the order identifier the moment a submission is accepted. Accepted is not filled, and the identifier is your only handle for cancelling, replacing, or reconciling. On any ambiguous outcome — a timeout, a dropped connection — query rather than resubmit. Resubmitting an order that may already exist is how a receiver doubles a position.
The honest limits
Alert delivery is one attempt with no retry. Any exit that must happen should not depend on a future webhook arriving.
Commission-free is not cost-free. Spread and slippage dominate options trading costs, and the per-contract rebate on API-traded options is real but small against the spread crossed on every trade. Rebates change the margin, not the sign.
Access is discretionary and Public says so. Build the broker layer so swapping it is contained — easier on a self-hosted deployment where that layer is yours to change.
And the pipeline working says nothing about whether the strategy does. Position sizing is what bounds loss — capital divided by twenty as the ceiling per position, under the divide-by-20 rule — and it is unaffected by every component above. Since the PDT rule elimination replaced day-trade counting with real-time intraday margin, buying power moves continuously during a session, which makes assumptions cached at market open less safe than they used to be.
Frequently asked questions
Can TradingView trade directly on Public.com? No. TradingView sends an HTTP POST to a URL; something there must authenticate to Public and submit the order.
Can I use Public's API for an automation service? The Individual API Program is stated to be personal and non-commercial, with a separate partnership track for product integrations. Seek counsel for your situation.
How do I place a spread from a TradingView alert? Through Public's dedicated multi-leg order endpoint, not by sending separate single-leg orders.
Is there a Public.com sandbox for testing? None appears in the documented API surface. Validate with read endpoints, preflight, and small live orders.
How do I track fills? By polling order status. There is no push feed in the documented surface.
Disclaimer: This article is educational content about software engineering and trading automation. It is not investment advice, financial advice, tax advice, legal advice, or a recommendation to buy or sell any security. Any instruments named are used solely to illustrate mechanics. Options trading involves substantial risk of loss and is not suitable for all investors. Please read Characteristics and Risks of Standardized Options before trading options. Automated trading systems carry additional risks including software defects, missed or duplicated signals, network and connectivity failures, third-party service changes and outages, and unintended order behaviour that may prevent orders from being placed, modified, or cancelled. Past performance does not indicate future results, and no configuration, alert setup, position-sizing rule, or risk setting can guarantee a profit or prevent a loss.
StaxInvesting LLC sells self-hosted trading software. It is not a broker-dealer, investment adviser, or financial institution, and it does not manage accounts, hold member funds, place trades on behalf of members, or access member brokerage accounts. Members run the software in their own cloud environment, connect their own brokerage accounts under their own credentials, and are solely responsible for their configuration, their credential security, their compliance with third-party terms of service, and every trade executed in their account. Third-party platform details described here reflect publicly available documentation as of publication and are subject to change without notice; always verify against current official documentation. Consult a qualified financial adviser and tax professional regarding your individual circumstances.