E*TRADE API in 2026: Keys, OAuth 1.0a, Token Rules and Order Limits

The E*TRADE API is the one big-broker interface that still runs on OAuth 1.0a, hands you a verification code to paste by hand, and expires every access token at midnight Eastern. Those three facts explain most of the questions people type into Google about it, from how to get a key to why a script that worked at 4 PM fails the next morning. This page walks the whole path as of November 2026: who can get a key and how, what the sign-in flow really does, what the sandbox is and is not, the order rules the Order API enforces, and where a third-party app like JorgAI stands with it. It is written from E*TRADE's own documentation and from building and testing an adapter against the sandbox, not from a rewrite of the docs.
Context first. E*TRADE has been part of Morgan Stanley since the acquisition closed on October 2, 2020 (Morgan Stanley press release), and the brokerage still runs its own retail platform and its own developer platform. The Developer Platform is a REST API, version 1, authorized with OAuth, and E*TRADE's getting-started page says it is free for developers to use. It is separate from the Equity Edge Online API that Morgan Stanley at Work runs for stock-plan administrators, which turns up in the same searches and has nothing to do with a retail brokerage account.
Who can get an E*TRADE API key, and how
E*TRADE issues two kinds of keys under its API Developer License Agreement. An Individual Use Developer builds something to manage his or her own personal accounts. A Vendor Use Developer builds an application made available to customers, which is what any third-party trading platform is. Each kind comes as a sandbox pair and a production pair of consumer key and secret.
| Individual key | Vendor key | |
|---|---|---|
| Who it is for | You, trading your own E*TRADE accounts | A company whose app other E*TRADE customers connect |
| How you request it | Signed in at us.etrade.com: the API Developer Agreement and the User Intent Survey (the questionnaire); keys appear in the same place | E*TRADE technical support by phone (1-800-387-2331), asking for the API developer team; a case number is opened |
| Time to keys | Same day in our case (October 8, 2026) | Open at the time of writing; requested October 29, 2026 |
| Scope | Works with any of the accounts under your login | Any customer who authorizes the app |
| Callback | Out-of-band verifier code by default | A registered callback URL removes the paste step |
Two practical notes from going through it. The questionnaire can be submitted once per login; after that the page becomes read-only and shows the existing key, so a company that first answered as an individual cannot upgrade itself to Vendor from the website. And E*TRADE's own chat support told us plainly that it does not handle this by email: the Vendor path is a phone call and a case number, and the follow-up comes by phone too.
OAuth 1.0a: the sign-in flow and the two token rules
Every other broker API JorgAI connects to uses OAuth 2. E*TRADE uses OAuth 1.0a with HMAC-SHA1 signatures, the only signature method its docs accept, and the flow has three legs (Get Request Token, Authorize Application, Get Access Token):
- The app fetches a request token, which is valid for five minutes, with a timestamp that must be accurate within five minutes.
- The member opens E*TRADE's authorize page, signs in and approves. With the default out-of-band callback, E*TRADE then shows a verification code on screen that the member pastes back into the app. With a registered callback URL, E*TRADE redirects instead and the paste disappears; the request-token response says which mode applies through oauth_callback_confirmed.
- The app exchanges the request token and the verifier for an access token and secret, which sign every request from then on.
Then come the two rules that trip people up. First, the docs state that the access token expires at midnight US Eastern time: when it does, the member must log in again and the application must secure a new access token. Second, if the application does not make any requests for two hours, the access token is inactivated and must be reactivated through the Renew Access Token API, which needs no action from the member. So a script that polls every minute during the day stays alive, a script that sleeps through lunch needs a renew call, and every script starts the next morning without a token.
How a platform lives with that
JorgAI's adapter runs a small refresh worker during market hours that renews any token idle for more than two hours, and it treats the midnight expiry as a daily event: when a day rolls over, the member is asked to sign in to E*TRADE again before the auto-trader resumes on that account. One more detail from testing: the pasted verifier is case-sensitive. Two of our first connection attempts failed with a 400 because the code had been typed in lower case.
| Broker API | Auth | Access token life | Refresh without the member |
|---|---|---|---|
| E*TRADE | OAuth 1.0a, HMAC-SHA1 | Until midnight US Eastern; inactive after 2 idle hours | Renew for idle tokens only; a new day needs a new sign-in |
| Schwab Trader API | OAuth 2 | 30 minutes | Refresh token valid 7 days, then re-authorize |
| tastytrade | OAuth 2 | 15 minutes | Refresh token, no fixed re-authorize window |
| Alpaca | API key pair or OAuth 2 | Keys do not expire | Not needed |
| Tradier | OAuth 2 | 24 hours | Refresh token |
The sandbox is a demo account, not a paper account
The sandbox host is apisb.etrade.com with the same paths as production, while the OAuth legs are served from the production host for both environments. What the sandbox returns is a canned demo account: fixed balances, fixed positions and order responses that confirm the request shape rather than simulate a market. That is enough to prove authentication, request signing, the preview-then-place sequence and error handling. It is not a place to test a strategy, and it does not behave like Alpaca's paper environment or Schwab's live account used with small sizes. Plan on the sandbox for plumbing and on a small real position for the first live order.
Order rules the Order API enforces
The Order API is a two-step interface. An order is previewed first, and the place request must carry the preview ids returned, within three minutes. Changing an order is the same pair of steps against the order id, and cancellation is its own request. The fields that matter for automation:
| Field | Values the docs list | What it means for software |
|---|---|---|
| priceType | MARKET, LIMIT, STOP, STOP_LIMIT, trailing-stop and hidden-stop variants, on-open and on-close variants, net debit/credit for spreads | Core equity orders are covered; STOP is E*TRADE's stop-on-quote |
| orderTerm | GOOD_FOR_DAY, GOOD_UNTIL_CANCEL, GOOD_TILL_DATE, IMMEDIATE_OR_CANCEL, FILL_OR_KILL | Day and GTC are the ones most automation uses |
| marketSession | REGULAR, EXTENDED, EXTO | Extended-hours orders must be limit orders, cannot be all-or-none and cannot be odd lots |
| quantityType | QUANTITY, DOLLAR, ALL_I_OWN | Equity share counts are whole numbers; the API's own error asks for a whole number of shares |
| clientOrderId | Unique per account | Our adapter uses a 20-character id, the maximum the API accepts |
| Brackets | No bracket or OCO group for equities in the order docs we read | Targets and stops have to be managed by the software, or placed as separate orders |
| Size rules | All-or-none only at 300 shares or more; short sales in even lots | Rare for small accounts, but the preview will refuse them |
Whole shares are the rule that changes behavior most. Like Schwab and Tradier, E*TRADE takes a share count on an equity order, so a per-trade dollar cap turns into a floor-to-whole-shares calculation, and a stock priced above the cap is skipped rather than bought in part. Dollar-amount sizing exists as a quantity type in the docs, but JorgAI's adapter sizes in whole shares and rejects fractional quantities before they reach the preview step.
Market data
The platform has quote and market endpoints, but a Vendor application does not need to depend on them. JorgAI's E*TRADE adapter takes its prices and bars from the same market-data feed its other adapters use, and uses E*TRADE only for the account, positions, orders and transactions. That keeps order handling identical across brokers and means a slow quote endpoint cannot hold up an exit.
Rate limits
The documentation pages we read do not publish a request-per-second or per-minute figure for the retail Developer Platform. Treat the two-hour inactivity rule and the five-minute timestamp window as the hard constraints, keep polling modest, and expect the usual HTTP throttling responses rather than a documented quota.
Python and the E*TRADE API
Most of the search demand around this API is from people writing their own scripts, and the official docs are language-neutral REST with JSON available by adding a .json suffix to a path. Community Python libraries exist that wrap the OAuth 1.0a legs and the account and order endpoints, and the signing itself is handled well by standard OAuth 1 client libraries. Whatever you use, the design constraints above still apply: a renew call after idle periods, a fresh sign-in every trading day, preview before place, and whole-share quantities. A personal script can live with the daily sign-in. A platform serving many members has to automate everything except that one step, which is the reason the Vendor key and a registered callback matter.
Where JorgAI stands with E*TRADE
JorgAI connects members' own brokerage accounts and carries out the rules they set inside them. The E*TRADE adapter is built and was first connected against the sandbox on October 29, 2026, using Individual keys. A Vendor key, the one that lets other E*TRADE customers connect, was requested by phone on the same day and is pending. Until E*TRADE issues it, E*TRADE is not available to members, and it is listed as in progress on the broker roadmap. When it opens, the connection will work the way this page describes: authorize on E*TRADE's own page, a daily sign-in because of the midnight rule, whole-share orders, and exits managed by the software. The brokers that are connected today, and what each API allows, are compared in the capability matrix and the order types comparison.
For the two most similar large-broker APIs, see the Schwab Trader API explained and how Schwab's token refresh works, and for the OAuth 2 brokers, the tastytrade API page and Tradier's order rules. If you are weighing whether to hand any app your broker access at all, this guide to connecting a trading bot safely covers what a key can and cannot do.
Quick answers
Is the E*TRADE API free?
Yes. E*TRADE's getting-started page says the Developer Platform is free for developers to use. You still need an E*TRADE account and the signed developer agreement.
How do I get an E*TRADE API key?
Signed in at us.etrade.com, complete the API Developer Agreement and the User Intent Survey. Individual keys were issued to us the same day. A Vendor key for an app that other customers use is requested through technical support by phone.
Does the E*TRADE API use OAuth 2?
No. It uses OAuth 1.0a with HMAC-SHA1 signatures and a request token, authorize, access token flow, with an out-of-band verification code unless a callback URL is registered to the key.
Why does my E*TRADE access token stop working?
Two reasons by design: the token is inactivated after two hours without requests and must be renewed through the Renew Access Token API, and it expires at midnight US Eastern every day, after which the user has to sign in again.
Is there an E*TRADE sandbox?
Yes, at apisb.etrade.com, with sandbox keys. It is a canned demo account that confirms your requests work; it does not simulate a live market.
Can the E*TRADE API place bracket orders?
The order documentation lists single orders with market, limit, stop, stop-limit and trailing variants, plus spreads for options. We found no bracket or OCO group for equities, so a platform manages the target and the stop itself.
Does the E*TRADE API allow fractional shares?
Equity orders take a share quantity and the API's error message asks for a whole number of shares. JorgAI treats E*TRADE as whole shares only.
Can I connect E*TRADE to JorgAI today?
Not yet. The adapter is built and tested on the sandbox; the Vendor key that opens it to members is pending with E*TRADE. The broker roadmap page shows the current status.
How we put this together. Token and order rules are quoted from E*TRADE's Developer Platform documentation (request token, access token, renew, orders) and its getting-started page, all read on November 8, 2026. The key path, the verifier behavior, the sandbox description and the adapter's rules come from building and connecting JorgAI's E*TRADE adapter on the sandbox in October 2026. Search demand is from Google Ads data pulled on November 8, 2026. Where E*TRADE changes a rule, its documentation wins over this page.
To see whole-share sizing and software-managed exits run in a simulator before any broker is connected, start on the free plan.
JorgAI is software that carries out the rules you set in your own brokerage account. It is not investment advice and does not predict or promise results. Trading involves risk of loss. E*TRADE is a trademark of its owner; JorgAI is not affiliated with or endorsed by E*TRADE or Morgan Stanley.
More in Getting Started
Keep reading
Let the AI do the trading.
Set it up in minutes. 7 day free trial on Starter, Plus and Pro.
Get started freeGet the weekly market read and new tools by email
One email a week: what moved, what the data says, and the next free tool when it ships. No spam, unsubscribe in one click.
More from the blog
Every other post, newest first
210 more posts
Keep reading
Stops, targets and a daily loss limit, enforced for you.
JorgAI runs the rules you set inside your own brokerage account. Zero withdrawal permissions, disconnect anytime.
Showing 18 of 210. Keep scrolling.




















