A Practical Guide to the Public.com API

Public.com is a comparatively recent entrant to the brokerage API space, and the documentation is better than the ecosystem around it suggests. There is an official Python SDK, a CLI, Postman collections, and a hosted MCP server for driving the account from an AI assistant.

This covers the endpoint surface, the authentication model, how order placement differs from what you may be used to, the economics, and the licensing term most integration guides skip.

The licensing term you should read first

Start here, because it determines whether the rest of this article is relevant to what you are building.

API access is granted under the Public Individual API Program, and Public states plainly that it is for your own personal, non-commercial use. The developer agreement goes further: you may not provide any third party with the right to access the Individual API Program, and participation may be limited, conditioned, restricted, or terminated by Public at any time, without notice, at their sole discretion.

Public maintains a separate partnership track for companies that want to integrate Public into a product their own users touch. That is a different agreement with a different conversation attached to it.

The practical dividing line: automating your own account under your own credentials is the individual case. Operating a service that trades other people's Public accounts is not, regardless of how the software is packaged.

Where a self-hosted tool sits depends on specifics — whose credentials, whose environment, who holds the key — and that is a legal question rather than an engineering one. If you are building anything other people will use, get the agreement in front of counsel before you build against it rather than after. This article describes the technical surface and does not interpret the terms for your situation.

Authentication

The model is a secret key exchanged for a bearer token via a create-personal-access-token endpoint. You request a token, receive it with a validity window measured in minutes, and send it on subsequent requests.

The design implications are the same ones that apply to any short-lived-token broker API, and the same defensive habits apply. Compute an absolute expiry when the token is issued and refresh proactively rather than discovering expiry by failing a request on the order path. Guard the refresh with a single-flight promise so concurrent callers do not each fire their own. Keep the secret key in environment variables or a secrets manager, never in source or a container layer, and redact it from logs.

Treat authentication failures as non-retryable. That is a general rule with broker APIs and it is worth holding to even where a specific vendor has not documented what happens when you hammer a login endpoint. The absence of a documented penalty is not evidence that there isn't one.

The endpoint surface

The reference is organised into a small number of groups, and the shape tells you a lot about the product.

Accounts and portfolio. List accounts, fetch a portfolio, fetch history. Read access covers real-time balances and buying power, portfolio value across asset classes, positions in stocks and ETFs, options, crypto, and bonds, money movements, order history, open order status, and dividends and interest.

Instruments. Fetch all instruments, fetch a single instrument, search bonds.

Market data. Quotes, option expirations, and option chains are POST endpoints, which surprises people expecting GET for reads — the reason is that these take a list of symbols in a request body rather than a query string. There are also bar endpoints, including an aggregated variant.

Option details. Greeks are available over REST, as is a strategy quote endpoint that prices a multi-leg package.

Tax lot selling. Unrealized tax lots, by symbol or in bulk, with a CSV variant. This is unusual to find in a brokerage API and genuinely useful if your process cares which lot it is closing.

Order placement. Preflight single leg, preflight multi leg, place order, place multileg order, get order, replace order, cancel order.

One thing worth noticing about that list: the documented surface is REST. No streaming market data endpoint appears in the reference. Compare that with brokers that route quotes through a WebSocket provider — the tradeoff is that you get greeks and historical bars from a plain REST call without a second protocol and a second symbology to learn, and you do not get a push feed. If your strategy needs tick-level updates rather than periodic polling, verify current streaming availability directly with Public before designing around it.

Preflight is a first-class endpoint, and you should use it

Preflight validates an order without placing it. It is separated into single-leg and multi-leg variants, and the CLI exposes it as a normal step in the workflow between checking a quote and placing an order.

For an unattended client this is the single most useful thing in the API. There is no human confirmation screen in an automated path, which is exactly why a programmatic validation step earns its round trip. Preflight, assert on what comes back against your own risk parameters, and refuse to submit if the assertions fail. Sizing errors caught before submission are cheap; the same error caught after is a position.

The cost is latency, and you should decide deliberately rather than by default. If an extra round trip is material to your strategy, run preflight on sizing changes and in testing rather than on every order, and keep the local assertions unconditionally.

Multi-leg orders are a separate endpoint

This is the structural difference most likely to trip you up if you are porting from another broker.

Some brokers model a spread as one order containing an array of legs, submitted to the same endpoint as a single-leg order. Public has a distinct place-multileg-order endpoint, with a matching distinct preflight-multi-leg.

Build your order abstraction so leg count selects the endpoint, and make that decision in one place. A client that treats multi-leg as a variation on the single-leg path will work until the first spread and then fail in a way that looks like a payload problem rather than a routing problem.

Do not decompose a spread into separate single-leg orders as a workaround. Separately submitted legs can partially fill, leaving exposure you never intended to hold, and they are priced independently rather than as a package. The strategy quote endpoint exists precisely so you can price the package first.

Order lifecycle

Place, get, replace, cancel. Replace is a PUT against the existing order; cancel is a DELETE.

The general discipline applies here as it does anywhere. A successful submission means accepted, not filled — persist the order identifier immediately, because it is your only handle for everything afterward. Reconcile against actual fills rather than assuming the quantity you submitted is the quantity you own. And on any ambiguous outcome, a timeout or a dropped connection after submitting, query rather than resubmit. Resubmitting an order that may already exist is how a client doubles a position.

With no push feed 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.

The economics are genuinely different

Most broker API comparisons treat cost as a footnote. Here it is a real differentiator and worth stating precisely.

Trading is commission-free, and Public runs an options rebate program in which contracts traded through the API earn a per-contract rebate rather than costing a fee. Public describes an adjusted rebate applying to QQQ, SPY, and IWM along with all contracts traded via the API, with members in tiers one through three earning six cents per contract and tier four earning ten cents.

For a high-frequency options process, per-contract economics compound in a way that a flat monthly platform fee does not. That said, keep it in proportion: a rebate measured in cents per contract is small relative to the bid-ask spread you cross on every trade, and a strategy that is unprofitable before rebates does not become profitable because of them. Rebates change the margin; they do not change the sign.

Verify current tiers and rates directly with Public before modelling them. Rebate programs change.

Tooling

The surrounding tooling is better than the API's relative newness would suggest: an official Python SDK, a CLI installable via pipx or uv that takes you from a live quote to a placed order in the terminal, official Postman collections, and a hosted MCP server that connects the brokerage to AI assistants including Claude and Perplexity.

A word on that last one. Connecting a live brokerage account to a natural-language agent is genuinely convenient and it removes a validation layer that exists for a reason. An agent that misreads an instruction places a real order in a real account. If you use it, use it against a small account, keep the position sizes bounded by something other than the agent's judgment, and understand that you are responsible for every order it places — Public's agreement says exactly that.

Note also that an unofficial reverse-engineered Public wrapper circulated before the official API existed and is now deprecated. If you find it in a search, it is not the path.

The honest limits

Access is discretionary. Public reserves the right to limit, restrict, or terminate participation at any time, without notice. That is standard language and it is also a real dependency. Build the broker layer so swapping it is contained.

Rate limits are not something I can quote. If you need a number, get it from Public rather than from an article. Build a conservative client-side limiter regardless.

REST-only market data is a design constraint, not a defect. It simplifies the client considerably and it means your data freshness is bounded by your poll interval. Know which of those matters more for what you are building.

Commission-free is not cost-free. Spread and slippage are the dominant costs in options trading and they are unaffected by a commission schedule. A rebate program is a real advantage at the margin and it does not make execution quality irrelevant.

And an API does not improve a strategy. Clean order placement executes a bad decision as faithfully as a good one. The control that bounds loss is position sizing, upstream of every endpoint above, which is why the divide-by-20 rule stays deliberately blunt: available trading capital divided by twenty as the ceiling on any single position. It constrains outcomes rather than predicting them.

How this fits a self-hosted client

StaxInvesting is software, not signals. The platform is provisioned into the member's own cloud environment, with broker credentials held in that environment's variables rather than in any vendor database, and no vendor access to running member instances. Because the client runs on the member's own self-hosted infrastructure, the broker connection is made from the member's environment under the member's own credentials — which is also the architecture that keeps the credential question as simple as it can be under an individual-use API program. Broker connections are trade-scoped; withdrawal permissions are never requested.

StaxInvesting is not a broker-dealer or a registered investment adviser and does not place trades on behalf of members.

Frequently asked questions

Does Public.com have a trading API? Yes. Public operates an official brokerage API covering stocks, ETFs, options, index options, crypto, corporate bonds, and treasuries, with documentation, an official Python SDK, a CLI, and Postman collections.

Can I use the Public API for a commercial product? The Individual API Program is stated to be for personal, non-commercial use, and the developer agreement prohibits providing third parties with access to it. Public runs a separate partnership program for product integrations. Seek counsel for your specific case.

How does Public API authentication work? A secret key is exchanged for a bearer token with a validity window measured in minutes, sent on subsequent requests.

Does Public charge for API trading? Trading is commission-free, and options contracts traded through the API earn a per-contract rebate under Public's rebate program. Verify current rates with Public.

How do I place a multi-leg options order? Through the dedicated multi-leg order endpoint, with a matching multi-leg preflight. It is a separate endpoint from single-leg placement.

What is preflight? A validation call that checks an order without placing it. For automated clients it functions as a programmatic pre-trade check in place of the confirmation screen a human would see.

Endpoint paths, request schemas, rate limits, and program terms are specified in Public's API documentation at public.com/api/docs and in the Individual API Program disclosures. Those are the authorities. This article describes the surface as documented at publication and is not a substitute for the specification 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 API 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, 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.