API access for 3rd-party app development

Hi. I am working on a trade journal product that is meant to enable real-time journaling by integrating with trading platforms like Tradovate. Users would connect to their accounts via Oauth and the app would only read from the accounts and listen to positions being opened and closed.

The big question, after reading the documentation, is whether there is any alternate way to get my hands on API credentials without setting up a funded account. Obviously, that doesn’t make a lot of sense for me as the developer of a 3rd-party solution that is meant to be used by a multitude of users.

I’d really like to cover Tradovate as a supported platform for the journal.
Thanks in advance!

Unless you become a Tradovate partner (fees involved), the only documented way is the API with a monthly fee and an account with at least $1000 to activate the API

Ok, thanks. Where can I learn more about becoming a Tradovate partner and fees?

Contact their support directly.

You are reading the situation correctly. The Tradovate API is tied to having an active account with API access enabled, so there is no documented way to obtain credentials without going through that process.

Most third party developers end up doing one of these:

• open a small funded account just for development and testing
• partner with Tradovate if they plan to distribute a commercial product
• rely on OAuth and have users connect their own accounts

In practice, the last option tends to be the cleanest architecture for tools like journaling apps because users authenticate directly and the app only listens to account events.

We ran into similar constraints while building execution infrastructure around multi account futures trading and automation at Proteryx.com. The typical approach ends up being user initiated OAuth plus streaming account events rather than trying to operate with platform level credentials.

If your journal only needs to read fills, positions, and account updates, the streaming APIs and order events should give you everything you need once the user connects their account.

Curious if you are planning to store fills only or also track order lifecycle events for the journal.

Thanks for your reply @proteryx.

I’m primarily interested in tracking fills and monitoring when users enter, scale in, scale out of, or exit positions. The idea is to prompt them to take notes continuously, the moment they take action in the markets, as a basis for summative reflection at the end of the trading day.

Hi @ogw

That makes sense, and honestly that’s a solid use case for the streaming side of the API.

If your focus is:

• fills
• entries and exits
• scale in / scale out events

For what you’re building, the cleaner approach is to rely on order lifecycle + execution events.

What has worked well for us: but I don’t know if you can access this data?

• listen to order updates (submitted, working, filled, partially filled)
• map fills to positions to detect entry vs exit
• track position size changes to infer scale in / scale out
• trigger journaling prompts on fill events, not order placement

For example:

• position goes from 0 → 1 = entry
• 1 → 2 = scale in
• 2 → 1 = partial exit
• 1 → 0 = full exit

This gives you structured, reliable signals without guessing from the order book. (And avoiding the DOM?)

We ended up following a similar pattern while building execution and automation flows around Tradovate accounts at Proteryx. Trying to use DOM data for anything beyond visualization quickly became unreliable, especially if you want consistent behavior across users.