- \n
x-api-key=<application key><\/code><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\nAdditionally, most requests also require:<\/p>\n\n\n\n
- \n
- A\u00a0Token<\/a>\u00a0in the header.\n
- \n
Authorization=Bearer <token><\/code><\/li>\n<\/ul>\n<\/li>\n\n\n\n- A\u00a0request ID<\/a>\u00a0passed as a query string\n
- \n
requestId=<app_name>-<company_name>--<new_guid><\/code><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\nNote<\/strong>: The TT REST API documentation provides the ability to create and send test requests<\/a>. These test requests also need the above-mentioned parameters where required by the endpoint.<\/p>\n\n\n\n
Application keys<\/a><\/h2>\n\n\n\n
Application Keys<\/strong> are created using the Setup<\/strong> application. An Application Key<\/strong> is associated with the login used to create it and the key will inherit the login’s permissions and access to data for the environment in which the key was created. Separate application keys<\/strong> are required for making requests from the UAT and Live environments.<\/p>\n\n\n\n
Consult the documentation for more information on the environments<\/a> used by the TT REST API as well as creating application keys<\/a>.<\/p>\n\n\n\n
Tokens<\/a><\/h2>\n\n\n\n
To request a token, you send your application key and application secret within a POST request to the ‘\/token’ endpoint. Full documentation<\/a> can be found at the bottom of this page.<\/p>\n\n\n\n
When using the token in subsequent requests,
Bearer<\/code> is added to the front of the token you recieve.<\/p>\n\n\n\nNote:<\/strong> Tokens are set to expire after a given period of time. This period of time is communicated in the response to your token request as the “seconds_until_expiry” value. Your application will need to generate a new token before its token expires.<\/p>\n\n\n\n
Providing a Request ID<\/a><\/h2>\n\n\n\n
All Risk, Monitor, and Ledger endpoints require a query parameter named requestId<\/strong>. Its value must be of the form:<\/p>\n\n\n\n
<app_name<\/em>>-<company_name<\/em>>–<new_guid<\/em>><\/p>\n\n\n\n
where:<\/p>\n\n\n\n
- \n
- <app_name<\/em>> is a user-generated string used to identify the specific application making the call.<\/li>\n\n\n\n
- <company_name<\/em>> is a user-generated string used to identify the user’s company.<\/li>\n\n\n\n
- <new_guid<\/em>> is the\u00a0globally unique identifier<\/a>\u00a0for this request. Each separate request should have a distinct identifier so that it can be traced.\u00a0GUIDs<\/a>\u00a0can be created using a GUID generator.<\/li>\n<\/ul>\n\n\n\n
To avoid issues when submitting your request and requestId<\/strong>, you must adhere to the following format requirements:<\/p>\n\n\n\n
- \n
- Do not use special characters<\/strong>: TT strongly recommends you avoid using special characters ($ & + , \/ : ; = ? @ ” <> # % { } | ^ ~ [ ] `) when creating your\u00a0requestId<\/strong>. These characters may cause failures when passed to some TT backend components.<\/li>\n\n\n\n
- Do not include spaces<\/strong>: Your\u00a0requestId<\/strong>\u00a0cannot include blank spaces.<\/li>\n\n\n\n
- Match the case sensitivity of the\u00a0requestId\u00a0parameter<\/strong>: The request will only work if the query parameter uses the appropriate ‘lower camelcase’ format:\u00a0requestId<\/strong>. Alternate case structures (e.g.,\u00a0requestid<\/strong>,\u00a0requestID<\/strong>, or\u00a0requestiD<\/strong>) may result in a failed request.<\/li>\n<\/ul>\n\n\n\n
Note<\/strong> Requests submitted without the requestId<\/strong> query parameter will be rejected.<\/p>\n\n\n\n
Creating a Globally Unique Identifier<\/a><\/h3>\n\n\n\n
To create a unique identifier, you can use an online GUID Generator like guid.one<\/a> or any other GUID generator available online.<\/p>\n\n\n\n
These tools generate completely random values (e.g., 47a1e1c4-0c94-4fb3-94a9-d772382458a3<\/strong>) that meet the criteria for creating a value used for identification.<\/p>\n\n\n\n
Note: <\/strong>You must includes all characters, including hyphens, when using this value to access TT REST API.<\/p>\n\n\n\n
For additional information on GUID values, visit guid.one\/guid<\/a>.<\/p>\n\n\n\n
Using Authentication and request IDs in test calls within documentation<\/a><\/h2>\n\n\n\n
The TT REST API documentation lets you make test calls for endpoints for all services. The Ledger, Monitor and Risk services require a token for addtional authentication. The documentation simplifies the process of authorizing your requests and for specifying a sample value for the new requestId parameter required for requests in these services.<\/p>\n\n\n\n
Rather than requiring you to authorize each request individually, the documentation provides an Authorize<\/strong> button that lets you enter the necessary authorization once for all calls in the service. When you click the Authorize button, you can enter the API key and token in the dialog box, as shown.<\/p>\n\n\n\n
![\"\"\/](\"https:\/\/library-staging.tradingtechnologies.com\/wp-content\/uploads\/2025\/09\/gs-authorize-dialog-new.png\")
<\/figure>\n\n\n\n- \n
- Enter your TT REST API Application Key from Setup.<\/li>\n\n\n\n
- Enter “Bearer\u00a0<\/strong>” followed by the token (include a space, but do not include the quotes).<\/li>\n<\/ol>\n\n\n\n
For any endpoint, you can click the Try it out<\/strong> button, populate the parameters, and execute the test request. While using the documentation to test your requests, a sample requestId parameter, in the proper format, is automatically populated so you need not generate a new GUID for each test request.<\/p>\n\n\n\n
![\"\"\/](\"https:\/\/library-staging.tradingtechnologies.com\/wp-content\/uploads\/2025\/09\/gs-swagger-requestId-scaled.png\")
<\/figure>\n\n\n\nNote<\/strong>: The sample requestId<\/strong> is valid only for test calls made from the documentation. When making requests from your application, you must generate a new and unique GUID for every request.<\/p>\n\n\n\n
Token Requests<\/a><\/h2>\n\n\n\n
To get a token, you send your application key and application secret within a POST request to generate a token. Expand the ‘\/token’ documentation below to view the required parameters for generating a token.<\/p>\n\n\n
<\/div>","protected":false},"excerpt":{"rendered":"All requests using the TT REST API must include:<\/p>\n
Additionally, most requests also require:<\/p>\n
Note<\/strong>: The TT REST API documentation provides the ability to create and send test requests<\/a>. These test requests also need the above-mentioned parameters where required by the endpoint.<\/p>\n
Application keys<\/a><\/h2>\n
Application Keys<\/strong> are created using the Setup<\/strong> application. An Application Key<\/strong> is associated with the login used to create it and the key will inherit the login’s permissions and access to data for the environment in which the key was created. Separate application keys<\/strong> are required for making requests from the UAT and Live environments.<\/p>\n
Consult the documentation for more information on the environments<\/a> used by the TT REST API as well as creating application keys<\/a>.<\/p>\n
Tokens<\/a><\/h2>\n
To request a token, you send your application key and application secret within a POST request to the ‘\/token’ endpoint. Full documentation<\/a> can be found at the bottom of this page.<\/p>\n
When using the token in subsequent requests,
Bearer<\/code> is added to the front of the token you recieve.<\/p>\nNote:<\/strong> Tokens are set to expire after a given period of time. This period of time is communicated in the response to your token request as the “seconds_until_expiry” value. Your application will need to generate a new token before its token expires.<\/p>\n
Providing a Request ID<\/a><\/h2>\n
All Risk, Monitor, and Ledger endpoints require a query parameter named requestId<\/strong>. Its value must be of the form:<\/p>\n
<app_name<\/em>>-<company_name<\/em>>–<new_guid<\/em>><\/p>\n
where:<\/p>\n
To avoid issues when submitting your request and requestId<\/strong>, you must adhere to the following format requirements:<\/p>\n
Note<\/strong> Requests submitted without the requestId<\/strong> query parameter will be rejected.<\/p>\n
Creating a Globally Unique Identifier<\/a><\/h3>\n
To create a unique identifier, you can use an online GUID Generator like guid.one<\/a> or any other GUID generator available online.<\/p>\n
These tools generate completely random values (e.g., 47a1e1c4-0c94-4fb3-94a9-d772382458a3<\/strong>) that meet the criteria for creating a value used for identification.<\/p>\n
Note: <\/strong>You must includes all characters, including hyphens, when using this value to access TT REST API.<\/p>\n
For additional information on GUID values, visit guid.one\/guid<\/a>.<\/p>\n
Using Authentication and request IDs in test calls within documentation<\/a><\/h2>\n
The TT REST API documentation lets you make test calls for endpoints for all services. The Ledger, Monitor and Risk services require a token for addtional authentication. The documentation simplifies the process of authorizing your requests and for specifying a sample value for the new requestId parameter required for requests in these services.<\/p>\n
Rather than requiring you to authorize each request individually, the documentation provides an Authorize<\/strong> button that lets you enter the necessary authorization once for all calls in the service. When you click the Authorize button, you can enter the API key and token in the dialog box, as shown.<\/p>\n
For any endpoint, you can click the Try it out<\/strong> button, populate the parameters, and execute the test request. While using the documentation to test your requests, a sample requestId parameter, in the proper format, is automatically populated so you need not generate a new GUID for each test request.<\/p>\n
Note<\/strong>: The sample requestId<\/strong> is valid only for test calls made from the documentation. When making requests from your application, you must generate a new and unique GUID for every request.<\/p>\n
Token Requests<\/a><\/h2>\n
To get a token, you send your application key and application secret within a POST request to generate a token. Expand the ‘\/token’ documentation below to view the required parameters for generating a token.<\/p>\n","protected":false},"author":2,"template":"single-item-doc-uat","meta":{"_acf_changed":false,"footnotes":""},"docs-category":[736],"class_list":["post-7952","doc","type-doc","status-publish","hentry","docs-category-getting-started-tt-rest-api-2-0-uat"],"acf":[],"_links":{"self":[{"href":"https:\/\/library-staging.tradingtechnologies.com\/ja\/wp-json\/wp\/v2\/doc\/7952","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/library-staging.tradingtechnologies.com\/ja\/wp-json\/wp\/v2\/doc"}],"about":[{"href":"https:\/\/library-staging.tradingtechnologies.com\/ja\/wp-json\/wp\/v2\/types\/doc"}],"author":[{"embeddable":true,"href":"https:\/\/library-staging.tradingtechnologies.com\/ja\/wp-json\/wp\/v2\/users\/2"}],"version-history":[{"count":0,"href":"https:\/\/library-staging.tradingtechnologies.com\/ja\/wp-json\/wp\/v2\/doc\/7952\/revisions"}],"wp:attachment":[{"href":"https:\/\/library-staging.tradingtechnologies.com\/ja\/wp-json\/wp\/v2\/media?parent=7952"}],"wp:term":[{"taxonomy":"docs-category","embeddable":true,"href":"https:\/\/library-staging.tradingtechnologies.com\/ja\/wp-json\/wp\/v2\/docs-category?post=7952"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Do not include spaces<\/strong>: Your\u00a0requestId<\/strong>\u00a0cannot include blank spaces.<\/li>\n\n\n\n
- <company_name<\/em>> is a user-generated string used to identify the user’s company.<\/li>\n\n\n\n
- <app_name<\/em>> is a user-generated string used to identify the specific application making the call.<\/li>\n\n\n\n
- A\u00a0request ID<\/a>\u00a0passed as a query string\n
- A\u00a0Token<\/a>\u00a0in the header.\n