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.

Consumer keys

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.

Requesting 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 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: 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
  • 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
Support & Community

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.

About the API

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 updates.

API Versions

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".

API Modules
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.
API Module Description APIs
OAuth Acquire, renew, and revoke OAuth token(s). Get Request Token, Authorize Application, Get Access Token, Renew Access Token, Revoke Access Token
Accounts 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 Detail
Market 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
Order 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 Order Change
Streaming API Subscribe to receive timely push notifications of order status changes - fulfillment, cancellation, etc. See Streaming API documentation.
Rate Limits Check the API rate limits and see how many requests are still available in the current time interval. Get Rate Limits
Notifications Get notifications about the system and platform, such as new features. Get Notifications
API Syntax

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 ( 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.

Case sensitivity

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.

Sandbox syntax

The URL path for the sandbox environment is slightly different. Details can be found in our Sandbox documentation.

Data formats

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.

API Documentation

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:

  • Description
  • URL
  • 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.

Request parameters
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:
Parameter Type Required? Description
accountId path required 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).

Response properties
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.
Property Type Description
count integer Number of transactions in this response
transaction complex Container for the elements of a transaction
transactionId long Numeric transaction ID
transactionDate long 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.

Next Steps
1. Apply for a consumer key

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.

2. Review the documentation

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.

3. Explore the other Developer Platform resources

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 Developer Community.


By using E*TRADE API ("API") and accepting the terms of the Application Programming Interface License Agreement and the Application Programming Interface User Agreement, you agree that API may employ security policies, procedures and systems of Third Party providers which may or may not be less stringent and secure than the policies, procedures and systems of E*TRADE Securities LLC ("E*TRADE") or its affiliates. Material provided on API may have been produced by independent third parties not affiliated or endorsed by E*TRADE or its affiliates ("Third Party"). To the extent that API or Third Party providers express opinions or make recommendations, you understand that such opinions or recommendations are expressed by the Third Party provider and are not the opinions or recommendations of E*TRADE or its affiliates. E*TRADE is not responsible for the accuracy of market data displayed on API or made available by Third Party providers. There may be latency between the time an order (or other information) is submitted from API and the time the order is received by E*TRADE. The E*TRADE Two Second Execution Guarantee or any similar guarantee does not apply for orders placed through API and Third Party provider web sites. The E*TRADE CompleteTM Protection Guarantee does not apply. Orders created and submitted through API are not vetted until they are received by E*TRADE. It is possible that E*TRADE may reject an order placed through API. Please see the Application Programming Interface License Agreement and the Application Programming Interface User Agreement for more information.

The E*TRADE family of companies provides financial services including trading, investing, and related banking products and services to retail investors.

Securities products and services offered by E*TRADE Securities LLC, Member FINRA/SIPC.

System response and account access times may vary due to a variety of factors, including trading volumes, market conditions, system performance, and other factors.