Unimplemented Endpoints

I’m working my way through the API docs, trying requests sporadically in WebSockets and REST format. Some requests aren’t yet implemented, so I’d prefer to avoid debugging them until they are.

A few examples I’ve run into (for context, I’m using aiohttp and Requests in Python 3.9.5):

  • auth/renewaccesstoken : implemented in the “live” subdomain but not “demo”
  • contractMaturity/deps : returning 401 Access Denied despite full credentials
  • contract/getproductfeeparams : sends an empty “params” array back when called through a demo/live WebSocket, regardless of the “productIds” array. It returns 404 Not Found when POST’ed.

Is there a list we could reference that catalogues which requests are complete or incomplete, preferably broken out by subdomain and WebSocket/REST?

Personally, this would be very helpful in identifying where I am making mistakes versus finding a dud endpoint. It would also help distinguish a known issue from a problem warranting a new ticket or community topic.

Hello @Brady,

All endpoints should work with proper auth and parameterization.

I just ran some tests using the REST API. Please ensure:

  • All /auth/ calls should be made from the LIVE subdomain.
  • Regarding the other endpoints - I’m receiving 200 responses with JSON data for both contractMaturity/deps?masterid=799, and contract/getProductParamFees with data {"productIds": [ 799 ] } using standard REST calls.

I’ve confirmed this using the api.tradovate.com website with a valid token, and by calling into the browser console with a valid token, and using cURL in the console, so they should work.

“They all work” is a good place to start! :sweat_smile:

That is helpful to know about /auth/ and live.* only. I’ll go bug hunting for the rest and compare my requests to the API docs’ examples. If anything really, truly appears broken I’ll raise it.

I think my disconnect with contractMaturity/deps is the behavior of the response code. Using masterid=799 returns complete JSON data and response code 200. Using masterid=1 (or some other invalid integer) returns a 401 response code and the data "Access is denied". Usually these both point to an authentication issue, but in this case the server couldn’t find the requested Product id.

Using an invalid integer with contract/getproductfeeparams such as {"productIds": [ 0 ] } returns response code 200 but empty data. Using {"productIds": [ 799 ] } returns response code 200 and valid data.

My takeaway after more playing is: properly formatted queries return expected results. But improperly formatted queries return response codes and/or data which may or may not indicate the problem, or any problem at all. Still good to know, but not ideal.

Im having this issue with the https://demo.tradovateapi.com/v1/cashBalance/getcashbalancesnapshot. end point. I’m implementing exactly what the curl API specification has listed and I’m getting a 404 response. The only thing I can think of is that I might be sending my account ID incorrectly. @Alexander do you mind verifying whether or not the account ID is a 6 digit number that’s found after the “DEMO” prefix in the accounts page. Here is my code, which is pulled directly from the API’s specified curl request.
headers = {

'accept': 'application/json',

'Authorization': 'Bearer F6CPq8099ahswPAWmvLT3N5GHtSXCZWq2eiUMXJNMo4SiADsEa6AAOVvnDocZz1sZmMstlPOZoWbHakAuSOZdoAmFz_hNpJR05lRRqZtjfxgkU3_zI242TqFiaPhlMP2uYYbW6UkyseXySbZ2l0Yd7mnz7GoNAzZadjItYp0-KAj-GFFo4kx1rHPiuJcPUNmLBnnuyAlA1EKS7g',

'Content-Type': 'application/json',


data = ‘{“accountId”:999999}’

response = requests.post(‘https://demo.tradovateapi.com/v1/cashBalance/getcashbalancesnapshot’, headers=headers, data=data)


accountId is found through either account/find or account/list. It’s different from the numbers on the end of your account name.

For example, my demo account is “DEMO02758”. This is the name query parameter for account/find. So a GET request using https://demo.tradovateapi.com/v1/account/find?name=DEMO02758 will return:
{"id": 460563, "name": "DEMO02758", ...}

That "id" value, 460563, is what you want.

I’m finally getting the hang of the lexicon. Throughout all the API sections:

  • ./find uses a readable name, like an account name or a Globex product code
  • ./item uses an id parameter you grab using another method, like ./find or ./deps
  • ./deps uses an alternative masterid number as defined in the query parameters section of interest. This is useful because you can scope in context from another API section to find what you need (e.g. use a particular accountId to find a list of relevant orders in order/deps)
1 Like

@Brady is accurate, your account entity ID is different from the numbered account name. So if you’re looking for dependent entities, you’ll need to use the account entity ID.

To further what Brady has to say about the naming and parameterization conventions, you can find out more about naming and usage by browsing the Conventions section of the API docs:


And, of course, you can try any operation from the API Docs site given that you

  • click the ‘Authorize’ button and supply a valid access token,
  • correctly parameterize the endpoint in question.
1 Like

thats what it was @Alexander. thank you