offloaddocs
Type
Reference
For
Driver
Coordinator
Admin
Developer
On
Mobile app
Tablet
Desktop
API

Offload public API

The Offload Public API lets you read and write Offload data from your own systems (schedulers, ERPs, broker portals, scripts) using HTTPS and a single Bearer token. The same backends that power the Offload app power this surface, so what your integration sees is what an operator sees.

This portal is the reference for everything you need to integrate. Three pages set the foundation; each API has its own section below.

Start here

  • Authentication: how to get a token, what it looks like, how to verify it, and what to do on a suspected leak. Shared across every API on the portal.
  • Quickstart: verify your API token with a single request.
  • API Reference: interactive Scalar reference rendered from the live OpenAPI spec. Every endpoint, every field, every error code.

Available surfaces

SurfaceWhat it does
Bulk ImportPush CSV/XLSX files of records (loads, projects, related entities) into Offload. Async: POST returns a 202 with a status URL you poll until terminal.
IdentityGET /v1/whoami verifies a token is live and returns its bound organization. Use as the integration deploy smoke-test.

Every endpoint, every field, every error code lives on the single API Reference page (interactive Scalar embed at the bottom). The authentication and base-URL conventions on this introduction page apply to all of them.

Base URL

https://api.letsoffload.com

Every endpoint on the public API is mounted under /v1/. The server applies a global /api prefix, so the wire path is /api/v1/.... Breaking changes ship under /v2/, /v3/, etc. See Versioning below for the commitment that comes with that.

Cross-cutting conventions

These hold across every API on the portal.

  • One header for auth. Authorization: Bearer osk_live_.... See Authentication.
  • Token verification. GET /v1/whoami returns 200 with the bound organization on a live token. Use it as your deploy smoke-test.
  • Resource envelopes. Every resource carries id, object, createdAt. Lists carry object: "list", data, nextPageUrl.
  • Errors. Every error response uses the RFC 7807 application/problem+json envelope with the Offload-specific extensions code, requestId, docUrl. Branch your integration on code. Codes are UPPER_SNAKE_CASE (Google AIP-193) and are immutable for the life of v1.
{
  "type": "https://docs.letsoffload.com/api/errors/MISSING_FILE",
  "title": "Bad Request",
  "status": 400,
  "detail": "The multipart envelope did not include a `file` part.",
  "instance": "/v1/imports/jobs",
  "code": "MISSING_FILE",
  "requestId": "req_01HXYZ...",
  "docUrl": "https://docs.letsoffload.com/api/errors/MISSING_FILE"
}

The full table of codes the API can return lives on the API Reference → Error codes section.

Versioning and the 12-month support window

The public API ships under /v1/. v1 is supported for 12 months from the date v1 first ships publicly. Within that window, only additive changes (new optional fields, new endpoints, new optional params). Breaking changes ship in v2. If v2 lands sooner than 12 months after v1, v1 remains supported through the original 12-month window.

In practice:

  • A field you read today will still be there tomorrow.
  • A field added later is optional and may be null for records created before it landed.
  • Error codes are forever.
  • Status enum values are forever.

When v2 ships, Offload will publish a side-by-side migration guide and run both versions in parallel through the original support window.

Next

Open the Authentication page to get a token, then run through the Quickstart to send your first request.

Was this helpful?