Migration Guide: GetAccessToken — API 1.6 → API 1.7

1. Endpoint Location

Implementation type API 1.6 (WebServices) API 1.7 (WebServices.NetCore)
JSON POST /FlightService.json/GetAccessToken POST /AuthService.json/GetAccessToken
XML POST /FlightService.xml/GetAccessToken POST /AuthService.xml/GetAccessToken
SOAP FlightService.asmx → GetAccessToken(string username, string password) AuthService.asmx → GetAccessToken(GetAccessTokenRequest)

The operation has moved from the FlightService into a dedicated AuthService. All clients must update their base URL accordingly.

2. Request Format

JSON (1.6)

Two supported modes — flat query string params or a raw JSON object with bare username/password keys:

POST /FlightService.json/GetAccessToken?username=foo&password=bar

{ "username": "foo", "password": "bar" }

JSON (1.7)

The request body must be a JSON object with the following structure. No query-string mode is supported.

{
  "Username": "foo",
  "Password": "bar"
}
Field Type Description
Username string API username
Password string API password

Note: Field names are PascalCase. Lowercase variants may still be accepted depending on the serializer configuration, but PascalCase is the canonical form.

XML (1.6)

Accepted a query string param username/password or an XML body with a root element containing Username and Password child nodes:

<GetAccessTokenRequest>
  <Username>foo</Username>
  <Password>bar</Password>
</GetAccessTokenRequest>

XML (1.7)

Same structure as 1.6. The body can also be passed as a request query string param:

<GetAccessTokenRequest>
  <Username>foo</Username>
  <Password>bar</Password>
</GetAccessTokenRequest>

SOAP (1.6)

Two separate string parameters:

<GetAccessToken>
  <username>foo</username>
  <password>bar</password>
</GetAccessToken>

SOAP (1.7)

SOAP messaging will not be available in upcoming versions of the API. Please plan your migration accordingly.

A single structured GetAccessTokenRequest message:

<GetAccessToken>
  <request>
    <Username>foo</Username>
    <Password>bar</Password>
  </request>
</GetAccessToken>

3. Response Format

1.6 — Plain string

The response body was a raw string: the token on success, or an error string like "1200 - Invalid credentials".

HTTP 200 OK
Content-Type: text/json

"a3f9b2c1D42"

1.7 — Structured GetAccessTokenResponse object

The response is now a full JSON object:

{
  "Token": "a3f9b2c1D42",
  "ExpiresAt": "2026-05-22T20:00:00Z",
  "IDWeb": 12,
  "WebDescription": "My Agency",
  "TransactionCode": null,
  "TransactionMessage": null
}
Field Description
Token The session token to use in all subsequent requests
ExpiresAt UTC expiry (8-hour TTL)
IDWeb Web account identifier
WebDescription Agency/web name
TransactionCode Error code string (e.g. "1200") on failure; null on success
TransactionMessage Error description on failure; null on success

Error handling change: In 1.6, errors were detected by checking if the response string started with a numeric code. In 1.7, check TransactionCode != null (or != "0").

4. Response Headers

Header 1.6 1.7
X-API-User-IDWeb Present (JSON and XML) Present
X-API-User-WebDescription Present (JSON and XML) Present
X-API-Version Assembly version string Assembly version string

5. API Version Enforcement

Starting in API 1.7, version enforcement is active: users must be authorized for the API version they are connecting to. When upgrading from 1.6 to 1.7, request API access for the new version from your account manager before switching endpoints.

6. Migration Checklist

  • Optionally update base URL from /FlightService.json → /AuthService.json
  • Update request body to use GetAccessTokenRequest model (PascalCase fields)
  • Update response parsing: read response.Token instead of the raw string; check response.TransactionCode for errors
  • Update error handling: stop checking for "1200 - " prefixed strings
  • Request API 1.7 access from your account manager before switching
See change history for this file
Loading...