---
name: trackerrms-oauth-app
description: Establishes which TrackerRMS credential a connector actually needs and obtains it — the customer-generated bearer token from Tools & Settings (self-serve, one per database, regenerating kills the old one) or the OAuth 2.0 authorization-code flow whose client secret TrackerRMS issues on request — plus the mandatory token-for-JWT exchange step, the three regional host pairs, the read/write scope pair, rate limits, sandbox access and a safe credential handoff. Use when asked to get TrackerRMS (Tracker) API credentials, register a TrackerRMS OAuth app, find a Tracker access token, or fix a Tracker auth error like a 401 on every call, a connection that died when another integration was set up, or calls hitting the wrong regional host. For any other vendor's developer portal, use that vendor's skill instead.
---

# TrackerRMS API Credentials

**Read this first, because it decides the shape of everything else: TrackerRMS has both a customer-generated bearer
token and a real OAuth 2.0 authorization-code flow, and neither of them is what you send on an API call.** Both are
inputs to a third step. Tracker's own API reference is unambiguous: "**All calls to this API require an authorised JWT
token**, which is obtained by exchanging a valid OAuth2 access token for a JWT token using the
**/api/auth/exchangetoken** endpoint." Whatever credential you obtain, the connector exchanges it for a short-lived
JWT and sends *that* as the bearer. A client that sends the customer's token straight at the API gets 401 on
everything and looks like a credential problem when it is an architecture problem (§2).

**Neither credential is fully self-serve, but only one of them needs TrackerRMS.** The bearer token *is* self-serve:
the customer generates it themselves in **Tools & Settings → Security Settings → API**, and Tracker says plainly that
it "bypasses the need for the OAuth2 step of our authentication process." The OAuth client secret is not: Tracker's
help centre says the `client_secret` is "issued on request," and points at `clientsupport@tracker-rms.com`. There is
no developer portal, no app-registration form and no console. Decide which model you are building against before doing
anything else (§1).

Three more things cost real time. **There is exactly one bearer token per Tracker database** — "If you generate a new
token the previous token will become invalidated" — so a customer setting up a second integration silently kills your
connection (§5). **The OAuth host and the API host are different domains**, and there are three regional pairs; get
either wrong and everything 404s (§3). And **the REST API is still described by Tracker as a beta** — "Beta
version—stable but evolving," with a JWT lifetime quoted as "valid for 7 days during beta" (§ Platform state).

## Inputs to collect before you start

Ask in one batch. Never invent.

| Input | Notes |
| --- | --- |
| **Credential model** | Customer-generated bearer token, or OAuth 2.0? (§1) |
| **Region** | US, Canada, or UK/Rest of World — sets *two* hostnames, not one (§3) |
| **Who generates the token** | It must be someone with access to Tools & Settings in the customer's database (§5) |
| **Does any other integration already use that database's token?** | Blocking — regenerating breaks whatever holds the old one (§5) |
| **Client ID and secret**, if OAuth | Issued by TrackerRMS on request; there is no portal (§5) |
| **Redirect URIs** | Every callback host, final, up front (§4) |
| **Scope set** | Tracker documents exactly two: `read` and `write` (§6) |
| **A sandbox** | Created by TrackerRMS on request; there is no self-serve sandbox (§5) |
| **New credentials or an edit to existing ones?** | New OAuth credentials orphan every existing authorization (§2) |

## Quick Start

1. Establish which **credential model** this actually needs (§1). Most wrong turns start here.
2. Understand the **token → JWT exchange**; it is mandatory and it is not optional plumbing (§2).
3. Pin the **region** and both of its hostnames (§3).
4. If OAuth: give TrackerRMS every callback host when you request the secret (§4).
5. Obtain the credential — the customer's Security Settings screen, or a request to TrackerRMS (§5).
6. Send `read` and/or `write` as the scope; there is nothing finer (§6).
7. Check the rate limit before promising a sync cadence — and remember the exchange call counts (§7).
8. Verify with a real round trip against the right regional pair (§8).
9. Hand the credential to a human, never to source control (§9).

## Platform state (verified 2026-09-20 — re-verify before trusting)

- **There is no developer portal.** Nothing on `tracker-rms.com` registers an application, lists apps, or shows a
  client ID. The OAuth `client_secret` is "issued on request," and the help centre's route for it is
  `clientsupport@tracker-rms.com`. For anything larger, Tracker's REST API overview asks for "your company and
  integration goals, the specific use case or workflow, rough API call volumes" by email to
  `trackerapi@tracker-rms.com`.
- **OAuth 2.0 authorization code is genuinely documented**, with its own OpenAPI definition ("OAuth2 API") published
  alongside the main reference. Authorize and token live at `/oAuth2/Authorize` and `/oAuth2/Token` on the
  `evoapi*` hosts — **a different domain from the REST API** (§3).
- **The documented `client_id` is a fixed literal, `EvoApi_1.0`.** Both the OpenAPI summary ("For client\_id use
  EvoApi\_1.0") and the help-centre authentication topic print it. The token-endpoint prose in the same OpenAPI
  document contradicts this, describing `client_id` as "Your app's `client_id`". **Resolve this with TrackerRMS before
  building** — it is the difference between a per-partner client and a shared one, and it changes what a client secret
  even identifies.
- **The two documents also disagree on the token response shape.** The OAuth2 description shows a standard
  `{ access_token, token_type: "Bearer", expires_in: 3600, refresh_token }`; the machine-readable schema on the same
  endpoint shows a single `{ "Token": "..." }`, and the help centre shows a bare UUID-shaped `Token`. A client written
  against one will not parse the other. Confirm with a real exchange before trusting either.
- **Scopes are just `read` and `write`**, comma-separated, and `scope` is a **required** parameter on the authorize
  call even though the prose walkthrough omits it (§6).
- **The REST API is beta.** "Beta version—stable but evolving." The JWT is quoted as "valid for 7 days during beta,"
  and Tracker warns that JWTs expire and clients should re-exchange on a 401.
- **Rate limits are published twice and do not match**: the API reference says "Presently 600 requests per minute";
  the help centre's REST API overview says "Rate limit is ~100 requests/min." **Plan against 100** and confirm (§7).
- **The old API still exists.** Tracker's July 2025 notice says the new REST API has shipped and "The old API
  connections will still function but there will be no updates." The old surface is a different thing — a widget API
  taking username/password or an OAuth token directly, with a separate "unique client API key." Do not mix its
  instructions into a new build (§1).
- **Sandbox is by request**: "Please reach out via Live Chat, ticket or email clientsupport@tracker-rms.com to have an
  API Sandbox account created to start testing the new version."

If the docs or the settings screens do not look like this, stop and report what you actually see.

## 1. Which credential, and who issues it

| Credential | Who issues it | How the customer gets it | Notes |
| --- | --- | --- | --- |
| **Bearer token** (Tracker calls it the API token) | The customer, self-serve, inside their own database | Tools & Settings → Security Settings → API → copy the existing token or generate a new one | **One per database.** Generating a new one invalidates the previous one. No expiry documented |
| **OAuth 2.0 access token** | TrackerRMS issues the `client_secret`; the customer then grants access through the flow | Authorize → code → token exchange | Refresh token supported; `expires_in: 3600` in the documented example. Client secret is not self-serve |
| **Partner Integration API Key** | Already present in the customer's account | Profile menu → Tools & Settings → Customization → **Display Settings** | **A different thing.** Not the REST API bearer token, and not an OAuth credential — see the trap below |
| **Username and password** | The customer | — | Legacy. Tracker: passed "in clear text over SSL however oAuth is recommended." Belongs to the old API surface |

Three traps follow directly:

- **"API key" means two different things in Tracker's own help centre.** The **Partner Integration API Key** on the
  Display Settings screen is a separate identifier associated with the older widget API, where it is used alongside a
  username to check a logon. It is **not** what `/api/auth/exchangetoken` accepts. A customer who has been sent to
  Display Settings and comes back with a key will be holding the wrong string, and it will fail with a generic 401.
  Send them to **Security Settings → API** instead, by name.
- **The bearer token deliberately skips OAuth.** Tracker documents it as bypassing the OAuth step entirely, which
  makes it the pragmatic model for a platform connecting many customers: ask each customer for their token and their
  region, and store the pair. That is a supportable design, and it needs nothing from TrackerRMS.
- **But it is a single shared secret for the whole database.** See §5 — this is the operational cost of choosing it.

> **Product fact — dated.** As of **2026-09-20**, Unified.to's TrackerRMS connector supports **both** models. In token
> mode it asks the customer for one value it labels "Access Token" and instructs them to generate it at
> "Tracker RMS → setting → Security → Security Settings → API → Access Token → Generate Token" — Tracker's own wording
> is Tools & Settings → Security Settings → API, which is worth using verbatim when talking to a customer. In OAuth
> mode it runs an authorization-code flow sending `client_id`, `redirect_uri`, `response_type`, `scope` and `state` on
> the authorize call, with scopes **comma-delimited**, and exchanges and refreshes with form-encoded POSTs carrying the
> client id, client secret and redirect URI; **PKCE is not used**. Its scope set is per unified object and per
> direction, drawn from exactly `read` and `write`. It offers three regional choices, each pairing an API host with its
> own OAuth host. **In both modes it performs the token-for-JWT exchange before calls** and sends the resulting JWT as
> the bearer — see §2 for the caveat. It records the sandbox route as a request to Tracker's client-support address.
> Its list operations are POSTs with page-number paging and an updated-after filter. Confirm all of this with the
> connector's owner before acting on it.

## 2. The JWT exchange — the step that is easy to miss

Whatever credential you hold, the call sequence is the same:

1. Obtain a credential — the customer's bearer token, or an OAuth access token from the flow.
2. `POST /api/Auth/ExchangeToken` on the **REST API host** for that region, with a JSON body whose single field is
   `bearerToken` set to the credential.
3. Take the returned JWT and send it as `Authorization: Bearer <jwt>` on every subsequent call.

Tracker's own step-by-step confirms the customer-generated token goes into exactly the same endpoint: "Navigate to the
Auth section and utilize the /ExchangeToken endpoint to obtain your JWT token after pasting in the token from Tracker
into the request body." So one exchange endpoint serves both credential models, which is why a connector can support
both with one code path.

What the docs say about the JWT's life: it **expires**, the quoted figure is **7 days during beta**, and Tracker's
instruction is behavioural rather than numeric — "you should always check for an authentication failure (401)
response and obtain a new JWT token by calling the /api/auth/exchangetoken endpoint, if necessary." Build the 401-and-
re-exchange path; do not hardcode seven days.

Two things worth settling before you ship:

- **Cache the JWT.** It is valid for days. Exchanging on every API call doubles your request count against a limit
  that may be as low as 100/minute (§7), and adds a full round trip of latency to every operation.
- **The exchange call itself is an API call.** Whatever the real rate limit turns out to be, budget the exchanges into
  it.

> **Product fact — dated.** As of 2026-09-20, Unified.to's TrackerRMS connector performs the exchange in a shared
> setup step wired into list, get, create, update, delete and passthrough, and there is **no caching of the returned
> JWT visible in that helper** — so each operation appears to spend an extra exchange request. At a documented ceiling
> of roughly 100 requests per minute that halves effective throughput. Worth confirming with the connector's owner
> before promising a sync cadence, and worth raising as a fix.

## 3. Region: two hostnames, not one

Tracker is regional, and the **OAuth endpoints and the REST API live on different domains**. The OAuth2 definition
says so explicitly: the authorize and token endpoints "are published on a separate domain to this API."

| Region | REST API host (data + JWT exchange) | OAuth host (authorize + token) |
| --- | --- | --- |
| US | `https://evousapi.tracker-rms.com` | `https://evoapius.tracker-rms.com` |
| Canada | `https://evocaapi.tracker-rms.com` | `https://evoapica.tracker-rms.com` |
| UK and Rest of World | `https://evoglapi.tracker-rms.com` | `https://evoapi.tracker-rms.com` |

Notes:

- **There is no per-customer subdomain.** Unlike many ATS vendors, Tracker does not put the customer's account in the
  hostname — the region does that, and the credential identifies the account. So the connect flow needs a **region**,
  not a subdomain, and the customer finds it by looking at the server location in the URL when they are logged in
  (Tracker's own step 1).
- Guessing the region is not safe: the wrong pair returns 404s and auth failures that read like a bad credential.
- The main API reference's machine-readable definition *also* lists the OAuth paths, contradicting the "separate
  domain" statement. Use the separate OAuth hosts above, which is what both the OAuth definition's server list and the
  help centre print.
- A sandbox host `apisandbox.tracker-rms.com` appears in Tracker's Visual Studio quick-start; it is not one of the
  three production regions and should only be used with a sandbox account Tracker has created for you (§5).

## 4. Redirect URIs

For **OAuth only** — the bearer-token model has no redirect.

`redirect_uri` is required on the authorize call, and the token exchange must send the "Same `redirect_uri` used
above." Register **every** callback host when you request the client secret. For Unified.to these are one per data
center; confirm the current list with the platform owner rather than assuming:

```
https://api.unified.to/oauth/code          # us (default)
https://api-eu.unified.to/oauth/code       # eu
https://api-au.unified.to/oauth/code       # au
https://api-dev.unified.to/oauth/code      # dev
```

What TrackerRMS does **not** document anywhere: whether redirect URIs are registered at all, how many are allowed,
the matching rule, whether wildcards or `http://localhost` are accepted, or how to add one later. **Do not assert any
of it.** Assume exact string matching and no trailing-slash forgiveness, put the full list in the same email that asks
for the secret, and ask TrackerRMS to confirm how a future addition is handled.

Note also that the Unified.to hosts above are one-per-region for *your platform's* data centers, which is a separate
axis from Tracker's US/CA/UK regions (§3). A customer in Tracker's Canada region can still be served by any of your
data centers; do not conflate the two lists.

## 5. Obtaining the credentials

### Path A — Customer-generated bearer token (self-serve, available today)

1. The customer logs in to their Tracker database and **notes the server location in the URL** — that is the region
   (§3).
2. **Tools & Settings → Security Settings → API.** They copy the existing token, or generate a new one.
3. They give you the token **and** the region.

Two facts to put in front of the customer at the same time, because they are the ones that cause support tickets:

- **There is one token per database, and generating a new one invalidates the old one.** Tracker states it directly.
  So: if anything else already uses that database's API token — another vendor, an internal script, a partner
  integration — **do not let them press Generate.** Have them copy the existing token instead. And warn them that if
  they later generate a fresh token for someone else, your connection dies at that moment, with no notice.
- **Who may see that screen is not documented.** Tracker's guidance on an adjacent settings screen is "If you don't
  have access to this please speak to your internal database administrator," and the same is likely true here — but it
  does not name a role or permission. If a customer contact reports they cannot see Security Settings, escalate to
  their Tracker administrator rather than guessing at a permission name.

Tracker does not publish an expiry for this token. Absence of a documented expiry is not a guarantee of immortality —
monitor for 401s on the exchange call, not just on data calls.

### Path B — OAuth 2.0 authorization code

Only after TrackerRMS has issued a client secret. The documented flow, against the OAuth host for the region:

- **Authorize** — `GET /oAuth2/Authorize` with `client_id`, `response_type=code`, `scope`, `redirect_uri` and
  `state`. All five are marked required in the machine-readable definition. The user authenticates in Tracker's UI and
  the code comes back to your redirect URI with the `state` you sent.
- **Exchange** — `POST /oAuth2/Token`, **form URL-encoded**, with `grant_type=authorization_code`, `code`,
  `redirect_uri`, `client_id` and `client_secret`.
- **Refresh** — same endpoint, `grant_type=refresh_token` with `refresh_token`. `refresh_token` is one of the two
  enumerated grant types.
- **Then exchange again.** Tracker's own step 7: "Use this token and exchange the token at the auth end point of the
  api to get your JWT for making your calls" (§2).

What Tracker does **not** document: refresh-token lifetime, whether the refresh token rotates, whether there is a
revocation endpoint, and whether PKCE is supported. **Say so rather than filling the gaps.** The prudent build stores
whatever the refresh response returns, refreshes on a schedule rather than lazily, and treats a failed refresh as
"send the customer through the flow again."

### Path C — asking TrackerRMS for what you need

One email usually covers all three of these; send it once rather than three times:

- **A client secret** (and a definitive answer on `client_id`, §Platform state) — `clientsupport@tracker-rms.com`.
- **A sandbox account** — same address, or live chat or a ticket. There is no self-serve sandbox, which means that
  without one, the only test tenant is a customer's production database. Say that out loud before anyone runs a create.
- **A deeper integration conversation** — `trackerapi@tracker-rms.com`, with company, integration goals, the specific
  workflow and rough API call volumes.

TrackerRMS publishes **no review timeline, no cost, no partner tiers and no SLA** for any of this. Do not invent one.

Anything only a human can do — being given access to Tools & Settings, signing anything, replying to Tracker — hand
back rather than looping.

**If this session has no browser automation** (the usual case for a CLI or cloud run), do not pretend to click. Give
the user an exact, ordered click path with the literal values to paste — the redirect URIs from §4, the scope strings
from §6 — or a ready-to-send email for Path C, then continue once they report back with the token or the client
secret.

## 6. Scopes

Tracker documents exactly two, and the security definition on the OAuth endpoints lists nothing else:

| Scope | Grants |
| --- | --- |
| `read` | Read access |
| `write` | Write access |

Rules and caveats:

- **Comma-separated**, as Tracker's own example spells it: `read,write`. Not space-separated.
- **`scope` is required** on the authorize call in the machine-readable definition, even though Tracker's prose
  walkthrough lists only `response_type`, `client_id`, `redirect_uri` and `state`. Send it.
- **There is no per-object or per-module scope.** `read` is read across the API surface. A connector cannot express
  "candidates only" through scopes; if that granularity matters to a customer, it has to come from Tracker-side
  permissions, and Tracker does not document how those interact with API access.
- **A read-only integration should ask for `read` alone.** It is the only least-privilege lever available here, so
  use it.
- The bearer-token model has **no scope selection at all** — the token carries whatever the database's API access
  allows. Do not tell a customer they can scope it down; they cannot.

## 7. Rate limits, beta status, and the old API

- **The two published figures disagree.** The API reference: "Tracker implements rate limiting on the API. Presently
  600 requests per minute." The help centre's REST API overview: "Rate limit is ~100 requests/min." **Plan against
  100**, confirm with TrackerRMS, and instrument for both.
- Exceeding it returns **429 Too Many Requests**. Tracker does not document a `Retry-After` header or any
  rate-limit headers — do not rely on one; back off on your own schedule.
- **Budget the JWT exchanges into the limit** (§2). An uncached exchange per operation roughly doubles your request
  count.
- **Errors follow RFC 9457 (Problem Details).** Tracker also warns that "your client must be prepared to gracefully
  handle additional members of the response" — a beta API adding fields is expected, not exceptional.
- **Beta means the surface moves.** "Beta version—stable but evolving," and the JWT lifetime is explicitly framed as a
  beta figure. Re-read the reference before a release rather than trusting a cached note.
- **The old API is still up.** Tracker's July 2025 notice: the old connections "will still function but there will be
  no updates." If you inherit code or documentation referencing widget endpoints, `checkLogon`, a username/password
  credential or the "unique client API key," it belongs to that surface, not this one.
- Tracker publishes a searchable rendering of the reference at the `/redoc` path on each API host, and per-area
  OpenAPI definitions behind the Swagger UI's definition selector — useful when you need a machine-readable schema
  rather than a page.

## 8. Verify end-to-end

Do not stop at "the token came back."

1. **Exchange first.** `POST /api/Auth/ExchangeToken` on the region's API host with the credential, and confirm a JWT
   comes back. If this fails, nothing else will, and the cause is the credential or the host — not your query.
2. Make one real read with the JWT — not with the original token — and confirm a 200.
3. **Re-exchange and confirm the new JWT also works.** That is the path your connector will take on every 401.
4. Deliberately call the **wrong regional host** once, so you know what that failure looks like in your logs before a
   customer produces it (§3).
5. On OAuth: run authorize → callback → token → exchange → read, end to end, and **record what the token response
   actually looked like** (§ Platform state — the docs disagree). Then refresh and read again.
6. Confirm your connect flow captures the **region** as a first-class input, not an inference.
7. Watch request volume during a real sync, counting exchanges (§7).

| Symptom | Cause |
| --- | --- |
| 401 on every data call, credential is definitely correct | Sending the customer's token or the OAuth access token directly instead of the exchanged JWT (§2) |
| 401 after working for days | JWT expired — re-exchange; Tracker tells you to do this on any 401 (§2) |
| 401 on the exchange call itself | Wrong credential (the Display Settings "API Key" rather than the Security Settings token), or the token was regenerated (§1, §5) |
| Everything broke at once for one customer, nothing changed on your side | Someone generated a new token in that database; the old one was invalidated (§5) |
| 404 on every call, credential is valid | Wrong regional host, or the OAuth host used for data calls (§3) |
| Authorize URL rejected or looping | `scope` omitted — it is required in the machine-readable definition even though the prose omits it (§6) |
| Token exchange returns something your client cannot parse | Vendor docs disagree on the response shape; log the raw body and compare (§ Platform state) |
| `client_id` rejected, or accepted but unexpected | The fixed `EvoApi_1.0` literal versus a per-app client id — settle it with TrackerRMS (§ Platform state) |
| Customer says there is no API section in settings | They lack access to Tools & Settings; escalate to their Tracker administrator (§5) |
| 429 under light load | The real ceiling may be ~100/min, and uncached JWT exchanges double your call count (§2, §7) |
| Responses contain fields your schema rejects | Beta API adding members; Tracker warns to handle them gracefully (§7) |
| Instructions in an old runbook do not match anything | It describes the pre-July-2025 API surface (§7) |

## 9. Hand off — never commit the token

- **Do not** write the bearer token, client secret, OAuth access token, refresh token or a JWT into source control, a
  test, a fixture, a committed `.env`, a ticket, a PR body or a chat channel. Values go to the human running this, for
  their secret store or console. The **region** is not a secret and may be recorded; the token is, and they usually
  arrive in the same message — separate them before you paste anything.
- The bearer token is **the database's only API token** (§5). Treat a leak as an incident that also breaks every other
  integration on that database when it is rotated, and say so when you report it.
- If a code change is needed (a callback host, a regional host, JWT caching), keep it secret-free and say plainly what
  the human must set out of band.
- Report a secret once so it can be pasted into the secret store, say clearly that it is now in the transcript and can
  be regenerated — with the caveat above — then move on.
- Close with: which credential model you ended up on; the **region** and both of its hostnames; the client ID if
  OAuth, and what TrackerRMS said about whether it is per-app; where the secret was delivered; the authorize, token
  and exchange endpoints; the scope string; whether the JWT is cached; whether anything else uses that database's
  token; the rate limit you are planning against; and whatever is still waiting on TrackerRMS.

## Stop and ask

Hand back to a human rather than guessing when: **no client secret has been issued** and the ask is OAuth credentials
(say so in the first reply — do not start a registration that cannot complete, because there is nowhere to register);
TrackerRMS has not confirmed whether `client_id` is per-app or the shared `EvoApi_1.0` literal; the customer's
database already has an API token in use by someone else and generating a new one would break it (§5); the only
available test tenant is production and the task involves writes (§5); the connector sends the raw token rather than
the exchanged JWT, or re-exchanges on every call (§2); a customer needs finer-grained permissions than `read`/`write`
(§6); a promised sync cadence depends on which of the two published rate limits is real (§7); anything in scope
depends on the pre-July-2025 API surface (§7); or the settings screens and the API reference do not match the
**Platform state** section.

## References

Verified to resolve on 2026-09-20.

- Tracker API reference — UK and Rest of World (authentication, errors, rate limits, response codes) — https://evoglapi.tracker-rms.com/swagger/index.html
- Tracker API reference — US — https://evousapi.tracker-rms.com/swagger/index.html
- Tracker API reference — Canada — https://evocaapi.tracker-rms.com/swagger/index.html
- Searchable rendering of the reference — https://evoglapi.tracker-rms.com/redoc
- OAuth2 API definition (authorize/token parameters, scopes, regional servers) — https://evoglapi.tracker-rms.com/swagger/evoapi.oauth2/swagger.json
- Authentication API definition (the token-for-JWT exchange) — https://evoglapi.tracker-rms.com/swagger/auth/swagger.json
- Main API definition — https://evoglapi.tracker-rms.com/swagger/v1/swagger.json
- REST API Information (regional docs, token location, JWT lifetime, rate limit, contact) — https://academy.tracker-rms.com/Home/Lesson/1272
- REST API Authorization (generating the bearer token; one token per database) — https://academy.tracker-rms.com/Home/Lesson/1273
- Connect your Project to the Tracker REST API (sandbox host, client generation) — https://academy.tracker-rms.com/Home/Lesson/1274
- Get Partner Integration API Key (the *other* key, in Display Settings) — https://academy.tracker-rms.com/Home/Lesson/1323
- Authentication (OAuth2 parameters, regional endpoints, sandbox request, old API notice) — https://academy.tracker-rms.com/Home/Lesson/355
- REST API help chapter index — https://academy.tracker-rms.com/Home/Search/?ChapterId=248
- TrackerRMS help centre — https://academy.tracker-rms.com/
- Sandbox API reference host — https://apisandbox.tracker-rms.com/swagger/index.html
- TrackerRMS website — https://www.tracker-rms.com/
- TrackerRMS contact — https://www.tracker-rms.com/contact/