generated: '2026-09-09' method: searched source: https://www.advancednavigation.com/downloads/versioned/kinematica/kinematica_api_reference_manual-1.6.pdf docs: https://www.advancednavigation.com/accessories/gnss-ins-post-processing/kinematica/api-reference-manual/ note: >- Derived from the published Kinematica API Reference Manual (document v1.6, API v1.2, dated 06/01/2026), section 4 "Authentication". Advanced Navigation publishes no OpenAPI, so there are no securitySchemes to read mechanically; every field below is quoted from the provider's own PDF. summary: types: [apiKey] api_key_in: [query] oauth2_flows: [] schemes: - name: apiKey type: apiKey in: query parameter_name: apiKey description: >- "All requests done through the API are connected to an account and must be authenticated. To authenticate any request while using the API the user's API key just needs to be included in the request." The key is issued per Kinematica account and is displayed on the account page. example_form: https://hq.advancednavigation.com.au/kinematica/api/alldatasets?v=1.2&apiKey=API_KEY sources: ['https://www.advancednavigation.com/downloads/versioned/kinematica/kinematica_api_reference_manual-1.6.pdf'] - name: v type: apiKey in: query parameter_name: v description: >- Not authentication, recorded here because it is mandatory alongside the key on every call: the API version number. A request whose version is incompatible with the server is rejected with {"success":"false","message":"Incompatible API Version"}. sources: ['https://www.advancednavigation.com/downloads/versioned/kinematica/kinematica_api_reference_manual-1.6.pdf'] observations: - >- The API key travels in the query string on GET calls (and as a form field on POST calls), so it is written to server access logs, browser history and proxy logs by construction. There is no header form, no bearer token, no OAuth, and no documented key rotation or scoping mechanism. - >- Probed live 2026-09-09: GET https://hq.advancednavigation.com.au/kinematica/api/alldatasets?v=1.2 returns HTTP 200 with body {"success":"false","message":"Invalid API key"} — the API answers anonymously with a 200 and signals failure in the JSON body rather than with 401/403. gaps: - No OAuth 2.0 / OpenID Connect surface; no scopes; no mTLS. - No account-level permission or scope reference published. - Failed authentication is reported as HTTP 200 with success:"false", not an HTTP 401.