Ready to go further
Next: practice with no real money
Paper trading is the step before a small live size.
What is included
- What it is, in plain words
- The formula or mechanism, with exact arithmetic
- How it hits grid, martingale and DCA bots
- A check you can run before you switch a bot on
Who it is for
- People who run or plan to run a trading bot
- Anyone reading a backtest or a bot sales page
- Readers who want the numbers, not the pitch
- Not advice, and not a signal service
Key facts
- Alpaca API is a broker connection you reach from your own code. This page explains the general method, not the product's current features.
- A bot is only as trustworthy as its test. Before relying on any result here, check costs, fills, data and timing, and keep a stretch of data the rule never saw.
- The worked example on this page uses made-up numbers, checked in node on 31 Oct 2026. It shows the arithmetic, not how any product performs.
- Prices, fees, markets, versions, limits and supported languages change and belong to the vendor. We state none of them. Check the vendor's current pages.
- Start on a simulated account, keep stops where they still work if the bot stops, and move to real money only in very small steps, if at all.
What it is
Alpaca is a brokerage built around a developer-facing API, which is why its name comes up for people writing their own bots. The pattern is the same as for any broker API: you create a pair of keys, your program signs requests with them, sends orders over a web interface, and reads account, order and position data back. Official libraries exist for several programming languages, though which ones and how well they are kept up to date is for the vendor to say.
A distinguishing feature of services of this kind is a separate paper trading environment: the same API, a different address and a different set of keys, with simulated money. What markets are covered, what account types are offered, and what the costs are belong to the vendor and change, so check its current pages. This page explains how it works in general terms. We have not tested it for this page. Check the vendor's current terms.
How a bot connects here
The connection style is a broker API, with your own program as the bot. Typically one channel is for requests and another streams updates.
- Keys. Treat them like a password. Keep them out of the code and out of any repository, use paper keys while developing, and rotate them if they leak.
- Paper first. Point the program at the simulated environment, with its own keys. Switching to live is a change of address and keys, so make the switch one clearly named setting, not a scattered edit.
- Order requests. Market, limit and stop styles are normally available. Which ones apply to which instruments is for the vendor to say.
- Streaming updates. Fills and account changes arrive as events. A bot that only polls can act on old information.
- Data. Market data often comes from the same vendor, with its own limits and delays. Read the current terms, including any difference between free and paid feeds.
Worked example: a retry that doubles a position
A bot sends a buy order for 100 shares at a made-up $50. The request times out. The bot cannot tell whether the order was received. A naive bot resends. If the first order had in fact gone through, there are now two. A client order id, a label the bot attaches to each request, lets the broker refuse a duplicate. Whether and how a given API supports this is for the vendor to say. Numbers are made up and checked in node.
| Case | Shares held | Exposure | Loss on a 1 percent adverse move |
|---|---|---|---|
| Order sent once | 100 | $5,000 | $50.00 |
| Timeout, bot retries, first order had already gone through | 200 | $10,000 | $100.00 |
| Retry carries a client order id and the duplicate is refused | 100 | $5,000 | $50.00 |
The duplicate doubles exposure from $5,000 to $10,000, and doubles the loss on a 1% adverse move from $50.00 to $100.00. Nothing in the strategy changed. The cure is not luck, it is design: tag each order, and after a timeout read the order list and positions before sending anything again.
What to verify before trusting a backtest here
These checks apply to any platform of this kind. The answers come from the vendor's current documentation and from your own tests, not from this page.
| Check | Why it matters |
|---|---|
| Paper and live are separate settings | A single clearly named switch, defaulting to paper. |
| Timeout and retry logic | Check before resending. Use a client order id if the API offers one. |
| Partial fills and rejected orders | Position comes from the account, not from the bot's memory. |
| Data source and delay | A signal made on delayed data acts on the past. |
| Backtest costs | Enter spread, fees and slippage. See slippage. |
| Rate and usage limits | Read the vendor limits and log every refusal. |
How bots break on this kind of platform
- Duplicate orders. As the example shows.
- Leaked keys. A key pushed to a public repository is a live risk.
- Paper-to-live mistakes. Live keys in a paper test, or paper settings believed to be live.
- Stale data. The bot trades on delayed prices.
- No stop at the broker. If the bot dies, a stop that lives only in its memory dies too. See stop loss orders.
A safe order of work
Backtest with honest costs, forward test on new data, run on a simulated account for weeks, then trade a very small size and compare each step with the one before. See forward testing and paper trading.
What this page does not tell you
It does not tell you whether the product is suitable, what it costs, or how it behaves today. Those change and belong to the vendor. It does not give a strategy to trade. This page explains how it works in general terms. We have not tested it for this page. Check the vendor's current terms.
Keep Going
Related Tools and Guides
Keep exploring
FAQ
Frequently Asked Questions
Can I paper trade with a broker API?
Some brokers offer a simulated environment with the same API. Check whether yours does and how it simulates fills, which can be kinder than real ones.
Do I need to know Python to use a broker API?
Not necessarily, since web APIs can be used from many languages, but you do need to be able to program. See the Python trading bot page for a structure.
Does a good Alpaca API backtest mean a bot will make money?
No. A backtest shows how a rule behaved on past data under its assumptions. Costs, fills, data and luck can all make live results different.
Should I test on a simulated account before real money?
Yes, as a general practice. A simulated account tests your code and your plumbing. Its fills are usually kinder than real ones, so it does not prove a rule works.
Have you tested Alpaca API?
No. This page explains how it works in general terms and we have not tested it for this page. Check the vendor's current terms.
Are the numbers on this page real?
Example numbers are made up to show how the maths works, and the page says so. A figure only counts as exact when the page says it was calculated on a stated date. Nothing you enter in a calculator leaves your browser.
Can I use this to decide whether to run a bot?
It can show whether a bot's numbers hold together and how much an account can lose. It cannot say what the market will do, and it is not advice. Use it to ask better questions, then read the terms of your own broker or exchange.
Is this financial advice?
No. It is general education. The numbers are made up and it does not consider your situation.
Know the Risk Before You Run It
Free calculators and guides, added every week. Leave your details and we will email you when new ones go up.
Trading carries a risk of loss