Connecting an Automated Bot to Public.com: The Complete Setup Path

Public.com is a reasonable target for automation. Trading is commission-free, options contracts traded through the API earn a per-contract rebate rather than a fee, and the tooling is good — an official Python SDK, a CLI, and Postman collections.

The setup path has one genuine complication and one thing you should read before writing any code.

Read the program terms first

Public grants API access under the Individual API Program, and states it is for your own personal, non-commercial use. The developer agreement adds that you may not provide any third party with the right to access the program, and that participation may be limited, restricted, or terminated at any time, without notice, at Public's sole discretion. A separate partnership track exists for companies integrating Public into a product their own users touch.

For automation this matters more than it does for a read-only script. The dividing line is roughly: automating your own account under your own credentials is the individual case; operating a service that trades other people's Public accounts is not, however the software is packaged.

Where a self-hosted tool falls depends on whose credentials, whose environment, and who holds the key. That is a legal question, not an engineering one. If you are building anything other people will run, put the agreement in front of counsel before you build against it.

Stage 1: Account prerequisites

Options approval. Your account has to be approved for the strategies you intend to run. Spreads require a different level than long calls and puts. An unapproved strategy fails at order submission, not at connection, so confirm it before you configure anything.

Sizing. Decide this before the software is involved, because it determines outcomes more than any setting does. The divide-by-20 rule is the starting frame: available trading capital divided by twenty as the ceiling on any single position. Blunt on purpose — position sizing is the one control that bounds loss regardless of what the strategy, the market, or the software does.

On the margin environment: the PDT rule elimination effective June 4, 2026 removed the day-trade counter and the $25,000 equity floor in favour of real-time intraday margin monitoring. That is not simply more permissive. A framework that reacts to exposure continuously is less forgiving of oversizing than one that checked a threshold once a day.

Stage 2: Credentials

Public uses a secret key exchanged for a bearer token through a create-personal-access-token endpoint. Tokens carry a validity window measured in minutes, so your client refreshes on a cycle rather than authenticating once.

The engineering rules are the ordinary ones and they matter here as much as anywhere. Compute an absolute expiry when the token is issued and refresh proactively, so token rotation never happens inside an order path. Guard the refresh with a single-flight promise so concurrent callers do not each fire one. Treat authentication failures as non-retryable — a retry loop against bad credentials is how integrations get themselves restricted, whether or not a specific vendor has documented what happens.

Keep the secret key out of source, out of committed environment files, out of container image layers, and out of logs. Authentication errors are the ones people paste into support threads.

Stage 3: Supply credentials to your instance

On a vendor-hosted platform, connecting a broker means handing credentials to a company that stores them and trades from their infrastructure. You inherit their key storage and their breach history.

On a self-hosted deployment, the software is provisioned into your own cloud environment and credentials live in that environment's variables. StaxInvesting holds no member API keys in any vendor database and has no access to running member instances. A vendor breach cannot expose a credential the vendor never held — and under an individual-use API program, an architecture where the member's own credentials never leave the member's own environment is the simplest posture to reason about.

The honest counterpart is that this relocates responsibility rather than removing it. You own the environment, the hygiene, and the recovery. If a key leaks, rotating it is your job and nobody notices on your behalf.

Stage 4: Validation, without a sandbox

Here is the complication.

Several broker APIs ship a sandbox: Tradier issues tokens for both live and sandbox accounts, and Alpaca runs a paper environment on a separate host that simulates fills against real-time quotes. tastytrade runs a certification environment on a separate base URL. No sandbox environment appears in Public's documented API surface. Confirm current availability with Public directly rather than assuming it from this article, but plan for its absence.

That removes the conventional rehearsal step, so the validation has to be assembled from other parts.

Use preflight as your dry run. Public exposes preflight endpoints for both single-leg and multi-leg orders, validating an order without placing it. This is the closest thing to a safe rehearsal the API offers, and for an unattended client it is more valuable than it is for a human — there is no confirmation screen, so a programmatic validation step is the only thing standing between a sizing bug and a position. Preflight, assert the result against your own risk parameters, and refuse to submit when the assertions fail.

Validate reads exhaustively first. Accounts, portfolio, positions, quotes, option chains, greeks. All of it is non-destructive and it exercises authentication, routing, and parsing without risk.

Then use real money, small. When there is no paper environment, the first live orders are the integration test. Size them so that being completely wrong is affordable — one contract, a liquid underlying, during regular hours. This is not a compromise anyone should be happy with, and it is worth noting that even brokers who do provide paper environments observe that small amounts of real money surface problems simulations do not.

Or paper elsewhere. Strategy validation and integration validation are separate problems. A platform-level paper mode can answer whether the strategy and configuration behave sensibly, while the broker integration is validated separately through preflight and small live orders. Do not let one substitute for the other.

What to watch in the first weeks

Fill quality. Commission-free is not cost-free. Spread and slippage dominate options trading costs and are unaffected by a commission schedule. A rebate measured in cents per contract is real and it is small next to the spread you cross on every trade.

Multi-leg routing. Public places multi-leg orders through a dedicated endpoint separate from single-leg placement. If your client treats spreads as a variation on the single-leg path, it works until the first spread and then fails in a way that reads like a payload problem rather than a routing problem.

Order status. With no push feed in the documented surface, status is a polling problem. Poll at an interval matched to how fast your strategy actually needs to react, not as fast as you can, and back off with jitter on failure.

Your own behaviour. The most common failure mode in automated trading is not software. It is the operator disabling automation mid-drawdown, overriding an exit, or resizing after a loss. If you were going to do that, the automation was never really running.

The honest limits

Access is discretionary and Public says so. Build the broker layer so swapping it is a contained change rather than an excavation.

The absence of a sandbox is a real gap for automation, and no amount of preflight fully closes it. Preflight validates that an order is acceptable; it does not tell you how the fill behaves.

Rebates change the margin, not the sign. A strategy that is unprofitable before rebates is not profitable because of them.

And connecting a bot correctly does not create an edge. Automation removes hesitation and enforces exits; it does not rescue a strategy that does not work. A well-configured system running a poor strategy loses money more reliably than a person would, because it never gets bored and skips a trade.

Frequently asked questions

Can I connect a trading bot to Public.com? Yes, through the official API. Note that access is granted under the Individual API Program, stated to be for personal, non-commercial use.

Does Public.com have a paper trading API environment? No sandbox environment appears in Public's documented API surface. Verify current availability with Public. Plan validation around preflight endpoints and small live orders.

How does Public API authentication work for a bot? A secret key is exchanged for a bearer token with a validity window in minutes; the client refreshes on a cycle.

Does the software need my Public.com password? No. API credentials are separate from account login and can be rotated independently.

What does it cost to trade through the API? Trading is commission-free and options contracts traded through the API earn a per-contract rebate. Confirm current tiers with Public.

Endpoint paths, schemas, and program terms are specified at public.com/api/docs and in the Individual API Program disclosures. Those are the authorities, and this article is not a substitute for them or for legal advice.

Disclaimer: This article is educational content about software engineering and API integration. 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, order construction errors, credential compromise, network and connectivity failures, broker API changes, rate limiting, access restrictions, and outages that may prevent orders from being placed, modified, or cancelled. Past performance does not indicate future results, and no configuration, order type, 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 API terms of service, and every trade executed in their account. Third-party API details described here reflect publicly available documentation as of publication and are subject to change by the vendor without notice; always verify against current official documentation. Consult a qualified financial adviser and tax professional regarding your individual circumstances.