The E*TRADE Developer Platform enables E*TRADE customers and developers to create their own investment applications that
leverage E*TRADE's extensive market data offerings, order-routing capabilities, and other services.
The platform's API also allows E*TRADE customers who currently use a third-party trading platform to view E*TRADE account
and market information and place trade orders directly to E*TRADE from that platform.
Using the E*TRADE Developer Platform, a client application can:
- Authenticate E*TRADE customers
- Directly manage trading: place orders, modify or cancel orders, and check order status
- Review specific information for an account, such as balances and current positions
- Retrieve price and other information about an index, stock, or option
- Receive system messages from E*TRADE
The E*TRADE Developer Platform provides most of its services via a REST API. Most of the API features are accessed via
simple HTTP GET requests. Requests that require detailed input, such as an order to buy or sell stock, use an HTTP POST request,
with the parameters included as either XML or JSON data. The HTTP DELETE request is also used, with one API, to delete messages
after they have been read.
Although most of the platform uses a RESTful request-response model, a streaming API is also provided, so that an application
can receive timely "push" notifications of order status changes.
The E*TRADE REST API uses the OAuth protocol to authorize every service request. In practice, this means that your application
must enable users to log in to their E*TRADE account and click a consent button to grant access for each session. For your
application to do this, even for testing purposes, requires an OAuth consumer key - a code that uniquely identifies the application
(i.e., the service consumer) and its developer.
We support two levels of consumer key. An individual key is tied to a single user ID, and allows access for only
that user. This is appropriate for developing applications for personal use, or for the early stages of a larger development
effort. A vendor key, on the other hand, permits access by multiple users and is appropriate for applications that
may be widely distributed.
Note that separate keys are required for accessing "sandbox" data (used for development and testing purposes) versus actual
production data. For this reason, a typical developer has at least two consumer keys.
To request a key, you must have an E*TRADE account. (You will also need the account so that you can log in and use your
application.) It can be a personal, professional, or corporate account. If you don't have one, you can quickly set one up
online at http://www.etrade.com. For development purposes, it is not
necessary to fund the account, but to do any actual trading will require funds.
When you are logged in to your account, request a consumer key via a secure message on this page: https://us.etrade.com/e/t/accounts/sccreatemsg. Select the subject "Technical Issue" and the topic "E*TRADE
API". Be sure to:
- State that you are requesting a consumer key
- Explain the type of application you are developing
- Specify whether you want an individual or vendor key
You may also want to request that your user account be approved as a non-funded account, so that you're not required to
have funds in the account to keep it open.
Within a few business days, a sandbox consumer key will be sent back to you by secure message, along with a Developer Agreement
which you will need to review and sign. When we've received your agreement and processed your request, we'll issue you a
production consumer key.
When you get the key, you will be notified of its scheduled expiration date - typically, two years from its creation date.
Note that if you are assigned an individual key, rather than a vendor key, it will only work with your E*TRADE account.
Attempting to use an individual key with a different user account will result in an error.
Developers and users are asked to sign several types of agreements:
- API Agreement - As a developer, you are asked to sign an API agreement before you will be issued a consumer
key for production data. As mentioned earlier, requesting a key requires that you log in to your E*TRADE account and send
a secure message.
- Authorization - As a user, whenever the application starts a session with the E*TRADE platform, you must
log in to your E*TRADE account and agree to an authorization request.
- RTQ Agreement - As a user, you must sign the Real-Time Quote Agreement before you can access data with
the quote API. You can do this at http://www.etrade.com.
- Extended-hours Agreement - As a user, you must sign the Extended-Hours Disclosure Agreement before you
can perform after-hours trading (if the application supports this feature). You can do this at http://www.etrade.com.
The E*TRADE Developer
Platform discussion board is a rich resource where you can learn more about the platform and share ideas and information
with the E*TRADE developer community. You may find answers there to technical problems or design challenges. Whether you're
a longtime E*TRADE developer or just getting started, we encourage you to participate in this active development forum.
The E*TRADE Developer Platform provides a REST API and related resources for creating customized investing applications,
opening the door not just to trading applications but to new applications and hybrids for algorithmic trading, social investing,
and market intelligence. The API can be used by individual E*TRADE investors building their own custom solutions as well
as third-party vendors building solutions for any E*TRADE customer.
Most of the platform services are REST APIs that provide information such as account lists, quotes, and alerts, or functionality
such as the ability to submit trade orders. Since the API is RESTful, it is easy to integrate into your application statelessly,
without complex session management, and it flexibly delivers data in either JSON or XML format.
In addition, the platform supports a streaming API that lets you subscribe to timely "push" notifications of order status
As the E*TRADE API evolves through multiple versions, development of new features always takes place on the most current
version of the API. Previous versions of the API are not revised except in the case of critical bug fixes.
The original platform version is designated as version 0 or "v0".
The APIs are organized into modules as shown in the table below. The module names are used as
part of the API syntax, and the same modules are used to organize the API documentation.
||Acquire, renew, and revoke OAuth token(s).
||Get Request Token,
Get Access Token, Renew Access Token, Revoke Access Token
||Get information on the user's accounts, including transaction histories, as well as any alerts for the user (trade executions,
order expirations, bill payments, etc.).
||List Accounts, Get
Account Balance, Get
Account Positions, List Alerts,
Read Alert, Delete
Alert, Get Transaction
History, Get Transaction
||Look up symbols and company information, get quotes, fundamentals, and performance history, and build option tables.
||Get Option Chains, Get
Option Expiration Dates, Look
Up Product, Get Quote
||Get a list of current orders, preview/place/modify/cancel orders for equities and options.
||List Orders, Cancel
Order, Preview Equity Order,
Place Equity Order, Preview
Equity Order Change, Place
Equity Order Change, Preview
Option Order, Place Option
Order, Preview Option
Order Change, Place Option
||Subscribe to receive timely push notifications of order status changes - fulfillment, cancellation, etc.
||See Streaming API
||Check the API rate limits and see how many requests are still available in the current time interval.
||Get Rate Limits
||Get notifications about the system and platform, such as new features.
In version v0, most of the REST API calls are GETs, some are POSTs, and one call uses a DELETE (to delete a message).
In most of these, the URL has very similar syntax. Here's an example:
After the host (etws.etrade.com) comes the API module (e.g., oauth, account, market,
or order), a standard path element /rest/, and the API endpoint (quote in this example). There
may be path parameters (MSFT in this example). At the end of the path, ".json" may be added to request JSON output
instead of the default XML. Finally, some APIs use query parameters, such as the detailFlag parameter shown here.
The API path and endpoint (market/rest/quote) are case-sensitive and should be lower case, as should the ".json"
parameter. Path parameters (MSFT) and query parameters are not case-sensitive.
The URL path for the sandbox environment is slightly different. Details can be found in our Sandbox documentation.
APIs that use HTTP POST will accept data in either XML or JSON format.
Responses use XML format by default. To receive JSON instead of XML, add ".json" in lower case at the end of the path
in the request URL.
Our API documentation is organized into groups based on API modules. Within the modules, each API is detailed separately.
The following information is typically provided:
- HTTP method(s)
- Request parameters, response properties
- Sample requests and responses
- Notes on usage
- Sample use cases
- Related APIs
In-depth topics such as authorization,
the sandbox test environment,
system messages, and rate limits are discussed separately
in Developer Guide articles.
In this documentation, request parameters are shown in tables that indicated whether each parameter
is required (always present), conditional (present under certain circumstances), or optional (decided
by the developer). For example:
||Numeric account ID
If parameters must contain one of a specific set of values, the table lists the possible values and the default value (i.e.,
the value that is assumed if the parameter is not specified).
Responses are XML or JSON structures, and some properties of the response may be complex,
meaning that they are parents of sub-properties. In tables that describe these complex structures, sub-properties are shown
indented under the parent, as shown below.
||Number of transactions in this response
||Container for the elements of a transaction
||Numeric transaction ID
||Date and time in epoch time
This documentation assumes that the developer is familiar with trading concepts and market terminology. For clarification
of market terms, you may find the E*TRADE
Financial Help Center helpful.
Dates and times are all US Eastern Time. Most times and dates in API responses are represented as epoch time, i.e., the
number of seconds since 12:00am on January 1, 1970.
Follow the instructions under Authorization above to get a consumer key so you can access
the platform and run the tutorial. You should receive a sandbox key and Developer Agreement within a few business days.
We recommend starting with the developer guides for authorization
and the sandbox. Then familiarize
yourself with the APIs. And no matter what language you're using, you may appreciate the simple Java
tutorial, which demonstrates getting authorized and requesting account data.
Our website includes SDKs and sample code for Java,
PHP, and VC++.
We've posted information on how to partner with us and links to 3rd-party
applications that use the E*TRADE API. Finally, you may find valuable ideas and information at our News page or our online