Read time … min

AI-native runtime for E*Trade trading strategies

Author in Cursor, Claude Code or any AI IDE. Deploy from GitHub into a managed cloud runtime with first-class MCP control, logs and region selection.

By the TradingHost engineering team

Section 01 · At a glance

At a glance

Broker
E*TRADE Securities LLC
Broker type
US-regulated full-service broker (Morgan Stanley subsidiary since October 2020)
Asset class
US equities, US options, US futures, bonds, ETFs, mutual funds
Asset coverage
US equities (NYSE, NASDAQ, ARCA, BATS, IEX listings), US listed options (OCC-cleared equity and index, single-leg and multi-leg), US futures via Power E*TRADE Pro, bonds (Treasury, corporate, municipal), ETFs, mutual funds. No direct crypto trading.
Runtime model
Containerised strategy runtime
Deployment source
GitHub
Languages
Any language that runs in a container
Common integrations
E*TRADE REST API with OAuth 1.0a, pyetrade (community Python), native HTTP clients with HMAC-SHA1 signing, custom connectors
AI workflow integration
MCP control surface for Cursor, Claude Code, GitHub Copilot and CLI agents
TradingHost role
Runtime, deployment, logs, health checks, region selection, MCP control
E*TRADE role
Broker account, API access, market data, execution venue, custody, settlement, tax reporting, margin management
Regulators
E*TRADE Securities LLC: SEC and FINRA registered broker-dealer (CRD 8163). SIPC member.
US retail
Yes. Sandbox environment available for development.
Affiliation
TradingHost is independent and is not affiliated with E*TRADE Securities LLC or Morgan Stanley, E*TRADE’s parent since October 2020.

Section 02 · What E*Trade offers

What E*Trade offers

E*TRADE exposes a REST API for US equities, options, account state and market data, authenticated with OAuth 1.0a request signing. Futures are routed through Power E*TRADE Pro (desktop), not the REST API. The OAuth 1.0a flow is the dominant operational detail because most modern brokers use OAuth 2.0 bearer tokens, and the signing logic is more elaborate.

Markets and strategy patterns

  • US equity systematic strategies via REST API
  • US options multi-leg orders with approval-level gating
  • Portfolio rebalancing for retirement and taxable accounts
  • Power E*TRADE Pro futures (separate desktop platform)
  • Sandbox-validated strategies before live deployment
  • OAuth 1.0a request signing on each REST call

API surface

Product surfaces
E*TRADE REST API for US equities, US options, account state, market data, transactions and order history. Futures and forex are handled through Power E*TRADE Pro, which is a separate desktop platform; the REST API does not currently expose futures order placement to retail. Sandbox endpoints mirror production shapes.
Connection methods
HTTPS REST against api.etrade.com (production) or apisb.etrade.com (sandbox). All requests are signed with HMAC-SHA1 per OAuth 1.0a; access tokens are short-lived and require an automated re-authorisation flow.
Authentication
OAuth 1.0a with request signing. Consumer key and secret are issued through the E*TRADE developer site; users authenticate the application against their E*TRADE account through the three-legged OAuth flow. Each request must be signed with HMAC-SHA1; the auth flow is materially more involved than the OAuth 2.0 bearer-token pattern used by newer brokers.

For specifics, refer to E*Trade

Specific endpoints, rate limits, options approval requirements and market data entitlements live in E*Trade’s developer documentation.

Section 03 · Build with AI

Build your E*Trade strategy with AI

Pick an integration method, fork a starter, and author your strategy in an AI IDE. Cursor, Claude Code, GitHub Copilot and CLI-based AI agents all work with the same GitHub-native deployment loop.

  • Native E*Trade REST

    Direct HTTPS REST against api.etrade.com (production) or apisb.etrade.com (sandbox). OAuth 1.0a request signing with HMAC-SHA1.

  • pyetrade

    Community Python wrapper that handles the OAuth 1.0a signing flow and exposes REST endpoints as Python methods.

  • Framework adapters

    NautilusTrader has a community E*Trade adapter; coverage and maturity vary by release.

  • Custom connector

    In-house implementation. The OAuth 1.0a signing logic is the part most worth getting right; the REST endpoints themselves are straightforward.

Library and framework support for E*Trade products

The OAuth 1.0a signing flow is the most distinctive integration detail; pyetrade handles it for Python projects. Futures are not in the REST API surface, so the futures cells are "no" across the matrix.

Library or frameworkUS equitiesUS optionsFuturesSandbox
Native REST + OAuth 1.0aSupportedSupportedNot documented as supportedSupported
pyetradeSupportedSupportedNot documented as supportedSupported
NautilusTraderPartially supportedPartially supportedNot documented as supportedPartially supported
Custom connectorSupportedSupportedNot documented as supportedSupported

✓ confirmed support per the library or surface docs. "no" indicates the surface does not expose the asset class; "check adapter" indicates support varies by release.

TradingHost does not force a library. It runs your project.

Author with AI

The OAuth 1.0a signing flow is the part of an E*Trade integration most worth templating once. Once the signing helper is in place, the REST endpoints themselves are straightforward and an AI IDE can scaffold them quickly. The TradingHost MCP control surface closes the loop on observability and runtime management.

Section 04 · Run on TradingHost

Run your code on TradingHost

E*Trade provides the broker account, API access and execution venue. TradingHost provides the production environment where your E*Trade-connected strategy runs.

Instead of running strategy code on a laptop, desktop machine, generic VPS or manually configured server, you deploy from GitHub into a TradingHost-managed container runtime.

You

  • Your repo contains your code.
  • Your deployment defines how it runs.
  • Your strategy connects to E*Trade.

TradingHost

  • Keeps the runtime online.
  • Surfaces logs and health checks.
  • Region selection.
  • Controlled deployment surface.

Deployment flow

  1. STEP 01

    Connect GitHub

    Authorise TradingHost to access your GitHub account.

  2. STEP 02

    Link a repo or start from a starter

    Point TradingHost at your existing E*Trade strategy repo, or fork a pyetrade starter for a working baseline with the OAuth 1.0a signing helper already in place.

  3. STEP 03

    Deploy into a TradingHost container

    Pick a region (US-East is the natural pick for US equities and options matching engines), supply your E*Trade consumer key, consumer secret and access tokens as environment values, and deploy. TradingHost runs your strategy on managed Kubernetes infrastructure.

  4. STEP 04

    Monitor logs and health

    Watch live logs, health and runtime state from the TradingHost dashboard. The same surface is reachable through MCP from any AI IDE. Trade execution stays on the strategy code path, not on MCP.

  5. STEP 05

    Update and redeploy

    Push changes to your GitHub main branch and TradingHost redeploys automatically.

Deploy

Section 05 · Operational notes

Operational notes for E*Trade

Things that bite you when you actually run an E*Trade strategy in a containerised cloud runtime. The OAuth 1.0a signing flow is the dominant operational reality. Every claim below is quoted or paraphrased from E*Trade’s developer documentation.

  1. 01 · OAuth 1.0a

    Request signing on every REST call

    E*TRADE’s REST API authenticates with OAuth 1.0a, which requires HMAC-SHA1 signing on every request. This is materially more involved than OAuth 2.0 bearer tokens used by newer brokers. pyetrade and similar community libraries handle the signing internally; custom connectors need a signing helper from the outset. Token rotation also requires the three-legged OAuth re-authorisation flow rather than a simple refresh-token swap.

    SourceE*TRADE developer site

  2. 02 · Sandbox

    apisb.etrade.com mirrors api.etrade.com endpoint shapes

    E*TRADE’s sandbox uses the host apisb.etrade.com against the same endpoint paths as production at api.etrade.com. Consumer credentials and access tokens are separate per environment. Promote a strategy from sandbox to live by swapping host and credentials; the strategy code does not change.

    SourceE*TRADE developer site

  3. 03 · Application approval

    Production application access is approval-gated

    E*TRADE issues sandbox consumer credentials freely; production credentials require a separate application review through the developer site. Plan an onboarding lead time before deploying live; sandbox-only deployments can run indefinitely.

    SourceE*TRADE developer site

  4. 04 · Futures via Power E*TRADE Pro

    Futures order placement is not exposed through the REST API for retail

    Futures trading on E*TRADE happens through Power E*TRADE Pro, which is a separate desktop platform. The REST API does not expose retail futures order placement. Strategies that require futures need a different broker (IBKR, TradeStation, Tradier) or need to bridge through the Power E*TRADE Pro desktop on a separate host.

    SourcePower E*TRADE Pro

  5. 05 · Options approval

    Options approval is per account and tiered

    Options trading on E*TRADE requires a tiered approval. Approval level controls which strategies the order endpoint accepts; orders that exceed the approved level are rejected at the broker. Plan strategies around your approved level or upgrade with E*TRADE before deploying.

    SourceE*TRADE options trading

Section 06 · Built for

Built for

TradingHost E*Trade runtimes are best suited to:

  • Developers building strategies in AI IDEs (Cursor, Claude Code)
  • US equity systematic strategy authors
  • Multi-leg options strategy automators
  • Long-horizon portfolio rebalancing programs
  • Existing E*Trade account holders moving to cloud-hosted automation

Connecting GitHub and creating your first strategy is free.

Section 08 · FAQ

FAQ

No. TradingHost is independent and is not affiliated with E*TRADE Securities LLC or Morgan Stanley, E*TRADE’s parent since October 2020.

No. TradingHost is a runtime for trading strategy code. E*TRADE Securities LLC is the broker-dealer (FINRA CRD 8163), a SIPC member. Your account, custody, market access, settlement and tax reporting all sit with E*Trade.

No. Your strategy code connects to E*Trade and sends order instructions according to your own logic, account permissions and integration method. TradingHost provides the runtime where that code runs.

No. E*Trade API access is provided by E*Trade. You are responsible for your E*Trade account, application registration, OAuth tokens and compliance with E*Trade’s terms.

Not via the REST API. Futures trading on E*Trade runs through Power E*TRADE Pro, which is a separate desktop platform. If your strategy requires futures, consider IBKR, TradeStation or Tradier instead, all of which expose futures through their REST APIs.

Yes, subject to E*Trade options approval. Approval level controls which strategies the broker accepts; TradingHost does not bypass approval.

E*Trade uses OAuth 1.0a with HMAC-SHA1 request signing, which is older than the OAuth 2.0 bearer-token pattern used by Alpaca, Tradier, Schwab, TradeStation and Tastytrade. Every request must be signed, and token rotation goes through the three-legged OAuth flow. Community libraries like pyetrade handle this; custom connectors need a signing helper from the outset.

Any language that runs in a container. E*Trade’s API is HTTPS REST, so any HTTP client with HMAC-SHA1 signing support can talk to it. pyetrade is the most maintained community Python wrapper.

Register a sandbox application at developer.etrade.com to obtain consumer credentials. Run the three-legged OAuth flow once to obtain access tokens. Develop against sandbox. When ready, apply for production credentials (separate approval). Connect your GitHub repo, link it to TradingHost, and deploy with credentials in TradingHost Secrets.

In your GitHub-controlled secrets workflow. TradingHost reads them at runtime through GitHub repository secrets, environment secrets or your own approved secret-management process. TradingHost does not need custody of your consumer key, consumer secret or access tokens. See platform secrets.

No. Strategies should never need withdrawal or money-movement permissions.

Yes. TradingHost supports MCP-based control for AI IDEs including Cursor, Claude Code, GitHub Copilot and CLI-based AI agents. MCP is a control and observability surface, not the trade execution path.

No. The PDT rule (FINRA Rule 4210) is enforced by E*Trade, not by TradingHost. Margin accounts under $25,000 are subject to PDT restrictions on day trading.

No. Your 1099 forms come from E*Trade at year-end, not from TradingHost.

No. SIPC covers your E*Trade brokerage account up to $500,000 (including $250,000 in cash). TradingHost’s runtime is not SIPC-insured because TradingHost is not a broker.

TradingHost runs in the EU and US-East regions. US-East is the natural pick for US equities and options matching engines. See the regions page.

No. TradingHost is focused on production runtime and deployment. Backtesting belongs in your research stack, framework or AlgoBuilder.