Skip to content

API overview

TrakIT’s API lets other systems work with your TrakIT data without anyone typing it in: create jobs and update work orders from your own systems, read invoices and bills into your accounting software, let suppliers send their bills, or fetch reports on a schedule.

There are two APIs. They differ in who calls them and how a call is authorized.

API For Authorization
Integration API (/api/v1) Your company’s own systems. A TrakIT user with API access signs in and sends a token. See Login token.
Public API (/api/public) Partners: suppliers sending bills, customers tracking their containers, systems fetching reports, yard systems. An API key set up for that partner. See API keys.

The integration API reads and changes TrakIT data as a TrakIT user who has API access: a system administrator for whom TrakIT Support has turned API access on. Everything the integration does is recorded under that user’s name. Sign in with Login (and sign the token out with Logout when it is no longer needed), then call:

Each public endpoint serves one kind of partner, with a key that allows that endpoint only:

The API is part of your TrakIT installation: its address is the one you sign in to TrakIT at, followed by /api/. With https://trakit.example.com as an example:

https://trakit.example.com/api/v1/GetJob
https://trakit.example.com/api/public/getbills

Always call the API over HTTPS.

  • A GET endpoint takes its parameters in the query string.
  • A POST endpoint takes a JSON body, sent with Content-Type: application/json, unless its page says it takes a file (multipart/form-data).
  • Endpoint names and query string parameters are not case-sensitive: /api/v1/getjob is the same as /api/v1/GetJob. For JSON bodies, use the field names exactly as each endpoint’s page writes them: some endpoints read them with their exact case.
  • Every answer is JSON, except the report files that QueryReport and AdvReport can return.

Endpoints answer with HTTP status 200 and the same JSON envelope, whether the request succeeded or not:

{
"Code": 1,
"Info": "",
"RetInfo": { },
"RowsAffected": 0,
"Scalar": null,
"Identity": 0
}
Field Meaning
Code 1 when the request succeeded, 0 when TrakIT refused it, -1 when an error stopped it.
Info Why the request was refused, or the error. Empty, or a short note, on success. Login returns the token here.
RetInfo The result: an object, a list, or null. Each endpoint’s page describes it.
RowsAffected For lists, the number of rows returned. Some endpoints use it for the number of records changed.
Scalar A single value, for the few endpoints that return one.
Identity The ID of the record created or changed, for endpoints that create or change one.

Always test Code before you read RetInfo. A few endpoints answer differently: with a file, with the data itself instead of the envelope, or with an HTTP error status when their key is missing. Their pages say so.

  • Sending: write dates as yyyy-MM-dd (2026-10-20) and dates with a time as yyyy-MM-ddTHH:mm:ss (2026-10-20T14:30:00). Some endpoints read dates with the regional settings of the TrakIT server, so a date such as 10/11/2026 can be read as 10 November or 11 October. The formats above are read the same way everywhere.
  • Receiving: dates come back in the same ISO 8601 form, 2026-10-20T14:30:00, with milliseconds when they are not zero (2026-10-20T14:30:05.437). Most carry no time zone, even when they are in UTC: each endpoint’s page says whether its times are in UTC or in local time.
What you get What to do
Code 0 The request was refused: Info says why, for example a missing field or a record that does not exist. Fix the request and send it again. Each endpoint’s page lists its messages under Rules.
Code -1 An error stopped the request. Send it again later. If it keeps failing, contact TrakIT Support with the endpoint, the time of the call and the Info text.
HTTP 404 The address is wrong, or a required query string parameter is missing: check the /api/v1/ or /api/public/ part, the endpoint name and the parameters.
HTTP 405 The endpoint exists but takes the other method: GET instead of POST, or the reverse.

If a call that creates something times out and you do not know whether it went through, check before you send it again: for example, look the job or bill up first. Sending it twice can create it twice, or be refused as a duplicate.