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
| Surface | What it does |
|---|---|
| Bulk Import | Push CSV/XLSX files of records (loads, projects, related entities) into Offload. Async: POST returns a 202 with a status URL you poll until terminal. |
| Identity | GET /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/whoamireturns200with the bound organization on a live token. Use it as your deploy smoke-test. - Resource envelopes. Every resource carries
id,object,createdAt. Lists carryobject: "list",data,nextPageUrl. - Errors. Every error response uses the RFC 7807
application/problem+jsonenvelope with the Offload-specific extensionscode,requestId,docUrl. Branch your integration oncode. Codes areUPPER_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
nullfor 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.