Authentication & access

Keep credentials on the server

The contract uses an Authorization: Bearer header over HTTPS. Token issuance and credential management are outside this website. There is no API-key generator or sign-in flow in this documentation portal.

A credential must be bound to one carrier and one authorized integration. Server-side authorization derives the carrier from the verified credential; a caller-supplied carrier identifier must never grant access.

Authorization: Bearer $ACCESS_TOKEN
Accept: application/json

Request only the necessary scopes

• eld:vehicles:read — ELD vehicle references and connection health.
• eld:devices:read — hardware metadata and device state.
• eld:events:read — observed engine events.
• eld:logs:read — daily records and duty-status transitions.
• eld:hos:read — calculated clock summaries for an authorized log.
• eld:diagnostics:read — ELD diagnostic and malfunction state.
• eld:audit:read — structured record history, without actor identity.

Authorization applies to every record

The same scope and carrier checks apply to list results, single-resource lookups, cursor continuation, and related-record access. An opaque identifier is not an authorization mechanism. A foreign or inaccessible resource returns a uniform 404 without confirming whether it exists.

The contract is read-only. It does not authorize log edits, driver certification, user administration, or new identity scopes. No credential can enable a driver profile through an include or expand parameter.

Handle credentials deliberately

• Store credentials in a secret manager and rotate them through the issuing service.
• Never place access tokens in query strings, client-side code, screenshots, or shared collections.
• Redact Authorization headers from application and proxy logs.
• Stop retrying on 401; resolve credential validity through your authorized administrator.