Exchange Short Grant Code

Redeem a short grant code for a session.

Available to: Anonymous callers, from a NinjaTrader-owned origin

Environments: Live. The endpoint is not blocked on Demo, but it only ever redeems codes minted in partner mode, which depends on a partner configuration provisioned on Live.

Rate Limit: 10 requests per hour, 3-second back-off, counts failed requests only

Partners do not normally call this endpoint. It is the other half of the shortGrantCode handoff, and it is called by the NinjaTrader-hosted application that receives your redirect: the application reads the code from the URL, exchanges it here for a real access token, and the user lands signed in. It is documented so you can reason about the full round trip and interpret what a user sees when a handoff fails.

How the Code Is Validated

Four checks run in order, and the first failure ends the request:

1. Origin. The request must come from a NinjaTrader-owned origin: a tradovate.com, ninjatrader.com, or ninjatrader.dev host. This is why the exchange is performed by the NinjaTrader application rather than by your own page.
2. The code itself. Codes are single-use: redemption deletes the stored code, so a second attempt with the same value fails. Codes also expire on the lifetime returned as expires_in when they were minted, and a newer code for the same user supersedes an older one.
3. Client IP. The resolved client IP must match the expectedClientIp the code was bound to.
4. The user. The account is re-validated at redemption: it must be an active trader account that is not an organization administrator, and it must still belong to the partner organization the code was minted for.

All four failure modes surface as errorText values on an HTTP 200 response. See the table below.

Because the IP comparison is an exact string match, two textual forms of the same IPv6 address do not match. Emit expectedClientIp in the same form the client will present at redemption.

Field Details

code is the value returned by shortGrantCode. appId and appVersion identify the application redeeming the code and are required. The optional deviceId feeds device-trust evaluation on the resulting session; when it is omitted, the device recorded at the time the code was minted is used instead.

Response Fields

A successful exchange returns the same AccessTokenResponse payload as a normal sign-in: accessToken, mdAccessToken, expirationTime, userId, name, and the account-status flags.

Sample Call

curl -X POST "https://live.tradovateapi.com/v1/auth/exchangeshortgrantcode" \
  -H "Content-Type: application/json" \
  -d '{
        "code": "<code from /auth/shortgrantcode>",
        "appId": "NinjaTrader Web",
        "appVersion": "1.0",
        "deviceId": "<client device id>"
      }'

{
  "accessToken": "…",
  "mdAccessToken": "…",
  "expirationTime": "2026-08-05T18:20:00.000Z",
  "userId": 12345,
  "name": "trader-name"
}

Common Failure Scenarios

• The code was already redeemed, expired, or was superseded by a newer code for the same user.
• The user’s IP at redemption differs from the expectedClientIp the code was bound to.
• The request originated from a host outside the NinjaTrader-owned origins.
• The account is inactive, is an organization administrator, or is no longer in the partner’s organization.
• The partner configuration was disabled or archived between minting and redemption.
• Repeated failures tripped the rate limit, which responds with a time-penalty body rather than an HTTP error.

Error Messages

Device-trust evaluation also runs on the resulting session, so a user with two-factor authentication enabled can be denied at redemption for an untrusted device or a new machine. Those denials carry their own errorText values, which are shared with the normal sign-in flow rather than specific to this endpoint.