Skip to main content
Access to the engine is organized as three permission levels. Each level is a different credential, each credential opens a different set of routes, and the sets do not overlap. A credential presented outside its scope is refused with 401, every time, on purpose.

​
Tenant keys

A tenant key is the credential for the product you license: market data, news and the calendar, trading, and account state with its risk controls. It is a machine credential for your servers, not a login. This documentation is public and needs no key. Send it as a bearer header:
Everything a signed-in user can do beyond that surface, such as journals, alerts, scripts, and preferences, stays session-only. A tenant key cannot reach those routes. New routes are closed to keys by default and are opened one at a time, deliberately. That is what keeps a leaked key an incident instead of a disaster.

​
Partner keys

A partner key has the same token shape and one job: registering and managing account registrations under /api/partner/. It cannot trade, cannot read a trader’s account, and cannot fetch market data. A tenant key is refused on partner routes just as firmly. The two scopes are disjoint so that your provisioning system and your trading system can fail independently.

​
Session cookies

Traders signed in to a first-party app carry a session cookie. The cookie reaches the PREVIEW challenge routes and nothing in the key-scoped surface. You never mint, store, or forward these.

​
Sandbox keys

Open the developer sandbox to sign in and create a key. The sandbox walkthrough takes you from email verification to your first request. Sandbox keys are self-service and expire after 30 days. They begin with trdrs_sk_sandbox_, work only in the isolated sandbox, and cannot be used in production. The current preview grants instrument-catalog access; it does not issue partner keys or access to live trading. Sandbox sessions manage keys; keys cannot manage other keys.

​
How production keys are issued

Keys are issued by trdrs per commercial contract, one per scope per environment. The plaintext key is shown exactly once at issuance. The engine stores only a SHA-256 hash of it, so nothing in our database can be read back into a usable credential, by us or by anyone who gets a copy. Treat issuance as the only time the key exists in the open:
  • put it straight into your secret manager;
  • never commit it, log it, or send it to a browser or mobile app;
  • give each environment its own key, so staging can be revoked without touching production;
  • if a key may have leaked, tell your trdrs contact and we revoke it immediately. Revocation is instant and takes effect on the next request. You get a replacement key the same way you got the first one.
Admin and back-office operations on the engine itself are not reachable by any key. There is no admin API to leak a credential for.