How to Automate Stock Trading with Alpaca in 2026

Automate Stock Trading with Alpaca: Start With an Offline Preview

To automate stock trading with Alpaca, separate your strategy calculation from account checks, request construction, and broker submission. Begin with an offline request preview, then test a deliberately enabled paper integration. An SDK request that prints successfully is not a broker acceptance, a fill, or evidence that a strategy is ready for live money.

This guide teaches the stock-order workflow. The executable example uses invented prices and account inputs. It needs no keys and makes no network requests. For a detailed implementation with an explicit paper submission option, use the Alpaca AI agent tutorial.

Step 1: Understand Account Mode and Keep Keys Separate

Alpaca's paper documentation describes a simulation account with separate credentials and endpoint. A Paper Only account can be created with an email address; do not confuse that with approval for a funded brokerage account. Follow the requirements shown for your account and region.

Before connecting an integration:

1. Open the broker dashboard and confirm that you are in the paper account.
2. Create credentials for that paper account and store them in a secrets manager or local environment. Never paste them into an article, shared log, or source repository.
3. Record the account mode and intended endpoint separately from strategy configuration.
4. Inspect permissions and how to revoke access. Do not switch to live keys merely to resolve a paper test error.

The offline example below does not use credentials or a TradingClient. Installing the SDK is the only setup it needs: run python -m pip install alpaca-py==0.43.2 in a virtual environment, save the complete Python block as alpaca_preview.py, and run python alpaca_preview.py. This version is the one used for the published example's offline checks; consult the SDK documentation before upgrading.

Step 2: Choose Order Semantics Before Writing a Loop

Read Alpaca's order documentation for the exact instrument and account:

• Market: requests execution at available prices; neither instant execution nor a specific fill price is guaranteed.
• Limit: specifies a price boundary, but may remain unfilled or partially filled.
• Stop: becomes a market order after its trigger; its fill can differ from the stop price. A stop-limit can remain unfilled.
• Bracket: entry plus conditional exits. Exit legs activate only after the entry fills completely. Partial take-profit fills adjust the remaining stop quantity; fast markets can fill both exits before cancellation.
• DAY: unfilled orders expire after the applicable session. A regular-hours DAY order submitted after the close can queue for the next trading day. A filled position is not automatically closed when an exit order expires.

Equity brackets require DAY or GTC and do not support extended hours. Inspect parent and leg states, not just the submission response.

Step 3: Run One Offline Strategy and Request Example

The following five prices, cash balance, position quantity, and order count are invented fixtures. They are not current SPY quotes, portfolio values, or recommended allocations. The teaching rule compares the latest three closes with all five; that is an above-average condition, not proof that a moving-average crossover just occurred.

The preview refuses unknown position/order state and invalid prices, skips existing exposure, and caps its one-share request at an invented $150 budget. A real integration also needs validated timestamps, complete account/order reconciliation, instrument permissions, session checks, and durable duplicate protection. Those are not supplied by an offline fixture.

from decimal import Decimal
import json

from alpaca.trading.enums import OrderClass, OrderSide, TimeInForce
from alpaca.trading.requests import LimitOrderRequest, StopLossRequest, TakeProfitRequest


def amount(value):
    if isinstance(value, bool) or not isinstance(value, (int, float, Decimal)):
        raise ValueError("Expected a known numeric fixture")
    result = Decimal(str(value))
    if not result.is_finite():
        raise ValueError("Non-finite fixture")
    return result


def preview(closes, *, cash, position_qty, open_orders):
    if not isinstance(closes, (list, tuple)) or len(closes) != 5:
        raise ValueError("Provide five invented closes")
    prices = [amount(value) for value in closes]
    if any(value <= 0 or value != value.quantize(Decimal("0.01")) for value in prices):
        raise ValueError("Use positive, cent-precision fixture prices")
    cash = amount(cash)
    position_qty = amount(position_qty)
    if cash <= 0 or position_qty < 0:
        raise ValueError("Invalid known cash or position quantity")
    if type(open_orders) is not int or open_orders < 0:
        raise ValueError("Open-order count must be known")
    if position_qty > 0 or open_orders > 0:
        return None
    fast = sum(prices[-3:]) / 3
    slow = sum(prices) / 5
    if fast <= slow:
        return None
    entry = prices[-1]
    if entry <= 2 or entry > min(cash, Decimal("150")):
        raise ValueError("Fixture exceeds the one-share preview budget")
    return LimitOrderRequest(
        symbol="SPY", qty=1, side=OrderSide.BUY,
        limit_price=float(entry), time_in_force=TimeInForce.DAY,
        order_class=OrderClass.BRACKET, extended_hours=False,
        take_profit=TakeProfitRequest(limit_price=float(entry + 2)),
        stop_loss=StopLossRequest(stop_price=float(entry - 2)),
        client_order_id="offline-alpaca-guide-only",
    )


request = preview([100, 101, 102, 103, 104], cash=150, position_qty=0, open_orders=0)
print(json.dumps(request.to_request_fields(), default=str, indent=2) if request else "No request")

It prints a one-share limit bracket at the fictional price 104, with a stop at 102 and a target at 106. These offsets illustrate request fields, not a tested risk/reward policy. The fixed client_order_id="offline-alpaca-guide-only" is display-only and unsuitable for submission. Real distinct decisions need distinct persisted IDs; retries for the same decision retain its original ID. The request model alone has no paper/live endpoint selection. Do not add a submission call and treat these fixtures as real market or account data. The SDK request reference explains the fields; broker-side validation is a separate step.

Step 4: Test Paper Behavior Without Assuming Live Parity

Paper trading is a simulation. Alpaca documents omitted market impact, latency-related slippage, queue position, regulatory fees, and dividends. Its simulated quantity checks do not reproduce available displayed liquidity, and paper orders can receive partial fills. Market-data entitlement also depends on the account: a Paper Only account has IEX access. See paper rules and assumptions.

Record what each paper test establishes:

There is no universal number of days or trades that certifies readiness. Test stale inputs, missing balances, open orders, restarts, partial fills, and session boundaries. Keep paper results separate from actual executions and include cost assumptions in any outcome review.

Step 5: Design Triggers and Reconciliation Before Automation

A scheduler, market-data stream, or authenticated webhook can trigger a strategy calculation. A repeated trigger must not automatically become another order. Give each intended action a stable identity, record it durably, and reconcile open orders and positions before permitting a new entry. Duplicate triggers, concurrent workers, or a restart should leave the same intended action visible for review.

A position lookup failure does not establish that you have no position. An authentication error, timeout, malformed response, or unavailable account state must pause new entries. Check open orders as well as positions: an accepted but unfilled entry can reserve exposure before a position exists.

For an ambiguous submission response, retain the original client order ID. The SDK's TradingClient provides get_order_by_client_id to retrieve the corresponding order. Reconcile that result, fills, and positions; do not blindly resubmit or create a new ID. If the result remains uncertain, halt further submissions and inspect the broker dashboard or contact broker support. Even an immediate missing-order response is not a reason to infer that an earlier timed-out submission was never accepted.

Step 6: Review Failures, Costs, and Account Restrictions

Use endpoint-specific request budgets and record rate-limit responses. The alpaca-py REST implementation contains HTTP retry handling. Inspect the installed SDK version's behavior before wrapping it: retrying a rate-limit response and reconciling a possibly accepted order are different operations. A catch-all exception loop cannot safely turn every failure into another submission.

Your operational review should include:

• A pause switch that stops new entries, plus confirmation of which existing orders remain active. Cancellation and closing a position are separate requests that can fail; neither promises an immediate liquidation.
• Limits on intended order value, aggregate exposure, and losses using known, reconciled account inputs. Missing or invalid values stop the workflow.
• Current account eligibility, instrument permissions, buying power, settlement, and applicable broker day-trading restrictions. Do not replace those checks with an article's hardcoded legal threshold.
• Data subscriptions, spreads, slippage, and applicable charges. Review Alpaca's regulatory-fee documentation and the terms for your specific account instead of assuming a commission headline means zero total cost.

This guide is educational software guidance, not legal, tax, or investment advice. Paper returns and a successful integration do not guarantee future outcomes.

How Tradewink Fits Into the Workflow

Use Tradewink to research a watchlist, review signal evidence, and keep paper decisions reviewable. Consult the Alpaca paper connection walkthrough for the current connection process and risk management essentials for the review checklist. Do not post broker secrets in a public channel or assume that connecting an account enables every automation feature.

Public subscriptions are paper-only; separately approved private beta accounts may submit live broker orders. Connecting a paper account, viewing a signal, or running this offline preview does not authorize live submission.

For the next coding step, use the detailed Alpaca AI agent tutorial. It separates dry-run evaluation from deliberate paper execution and documents the limits that still need operational review.