Dynamic API Hosts

Read your API hosts from the authentication response instead of hard-coding them.

View as Markdown

Some organizations run on dedicated, isolated infrastructure rather than the shared NinjaTrader environment. Users in those organizations reach the API on different hostnames, so a client that hard-codes demo.tradovateapi.com can’t serve them.

To support this, the authentication endpoints return an apiHosts object that names the host to use for each service. Your application should read those hosts and use them as the base for every subsequent REST and WebSocket call.

If your application hard-codes environment hostnames, it may stop working for users in organizations that move to dedicated infrastructure. Update your host resolution before those users are migrated.

Who Needs to Change

You need to make this change if your application does either of the following:

  • Stores a fixed map of environment to hostname (e.g., Demo to demo.tradovateapi.com) and builds request URLs from it.
  • Assumes the Demo and Live hosts share a domain, or derives one host from the other.

You don’t need to change anything if your application already builds its base URLs from a value returned at authentication time.

What You Get Back

A successful authentication response can include an apiHosts object:

Authentication response (abbreviated)
{
  "accessToken": "<your access token>",
  "expirationTime": "2026-09-04T18:00:00.000Z",
  "userStatus": "Active",
  "userId": 12345,
  "name": "<your username>",
  "apiHosts": {
    "live": "live.tradovateapi.com",
    "demo": "<your organization's demo host>",
    "mdLive": "md.tradovateapi.com",
    "mdDemo": "md-demo.tradovateapi.com",
    "replay": "replay.tradovateapi.com",
    "reportingLive": "<your reporting live host>",
    "reportingDemo": "<your reporting demo host>"
  }
}

The values above are illustrative. Treat whatever the response returns as authoritative, and don’t copy these hostnames into your configuration.

Every host is a bare hostname with no scheme. Your client adds https:// for REST calls and wss:// for WebSocket connections.

FieldReturnedUse
liveAlwaysLive trading REST and WebSocket host
demoAlwaysDemo (simulation) trading REST and WebSocket host. This is the host that varies by organization.
mdLiveAlwaysLive market data host
mdDemoAlwaysDemo market data host
replayAlwaysMarket Replay host
reportingLiveAlwaysLive reporting host
reportingDemoAlwaysDemo reporting host
adminLiveAdministrators and organization administratorsLive administrative REST host
adminDemoAdministrators and organization administratorsDemo administrative REST host
mdAdminLiveAdministrators and organization administratorsLive administrative market data host
mdAdminDemoAdministrators and organization administratorsDemo administrative market data host

Treat all hosts as authoritative, including live, mdLive, and replay. Those are currently the same for every organization, but they’re returned so that your client keeps working if that changes.

Update Your Client

1

Read the hosts at authentication

Call accessTokenRequest as you do today and read apiHosts from the response. The same object comes back from the social login token request and from renewAccessToken, modifyCredentials, modifyPassword, and setSocialCredentials, so you can pick it up wherever your application handles those responses.

At minimum, handle apiHosts on the response to your initial token request, whether you authenticate with credentials or with a social login. Reading it from the other responses is optional.

2

Store the hosts alongside your auth state

Persist the returned hosts for the session in the same place you keep the access token. Your request layer needs them on every call, not just the first one.

3

Route requests by purpose

Select the host for each request based on what the request does, rather than on a single environment setting:

RequestHost
Demo trading REST or WebSocketdemo
Live trading REST or WebSocketlive
Demo market datamdDemo
Live market datamdLive
Market Replayreplay
Demo reportingreportingDemo
Live reportingreportingLive

Build the URL from the stored host, for example https://<demo>/v1/account/list for a REST call or wss://<demo>/v1/websocket for a WebSocket connection.

4

Keep a fallback

apiHosts is optional, and it’s omitted when the response carries an error and when the response asks for a multi-factor authentication step. Keep your existing host resolution as a fallback for those cases so authentication failures and MFA prompts behave as they do today.

5

Re-read the hosts on every authentication

Resolve hosts again each time you authenticate or renew, and replace what you stored. A user’s organization can move to dedicated infrastructure between sessions, which changes the hosts they get back.

If Your Client Ignores the Returned Hosts

A user whose organization runs on dedicated infrastructure but whose client connects to the shared Demo host is refused after authentication:

  • REST requests receive HTTP 307 with a Location header pointing at the correct host. Many HTTP clients drop the Authorization header when a redirect crosses to a different host, so the retried request can fail even if your client follows redirects.
  • WebSocket connections are rejected with status 421.

Both apply to the Demo environment, which is where hosts differ by organization.

Parsing Notes

  • Ignore fields you don’t recognize. The response may carry additional hosts used by NinjaTrader tooling, and more can be added over time.
  • Treat apiHosts as optional at the type level. Don’t fail to parse a response that omits it.
  • Configuration endpoints aren’t part of apiHosts and continue to use your existing base host.

Next Steps