SDKs and versioning

The v5 API is described by an OpenAPI 3 spec at https://api.transdirect.com.au/openapi.json. The TypeScript SDK, the API Explorer and these reference pages are all built from that spec. If anything here disagrees with the spec, the spec is right.

TypeScript SDK

@transdirect/api-sdk is a typed client generated from the spec. It is built on the standard fetch API, so it needs Node.js 18 or later, or another runtime that provides fetch.

npm install @transdirect/api-sdk

Set your key once on the shared client. The base URL already defaults to https://api.transdirect.com.au.

import { client, postApiV5Quotes } from '@transdirect/api-sdk';

client.setConfig({
  headers: { 'api-key': process.env.TD_API_KEY! },
});

const { data, error, response } = await postApiV5Quotes({
  body: {
    sender: { suburb: 'SYDNEY', postcode: '2000', state: 'NSW', country: 'AU', type: 'business' },
    receiver: { suburb: 'MELBOURNE', postcode: '3000', state: 'VIC', country: 'AU', type: 'residential' },
    items: [{ description: 'Carton', weight: 5, length: 40, width: 30, height: 20, quantity: 1 }],
    declared_value: 0,
  },
});

if (error || !data) {
  console.error(response.status, error);
} else {
  console.log(data.id, Object.keys(data.quotes));
}

Keep the key on your server: the API does not accept browser requests from other websites. See authentication.

Results

Every function returns { data, error, response }. An HTTP error status does not throw; a network failure does.

On success, data holds the parsed body and error is undefined.
On an error status, error holds the parsed error body. The API overview lists the shapes.
response is the raw Response, for the status code and headers. Its body has already been read, so use data or error for the content.

Function names

Each endpoint is one function, named from the HTTP method and the path. Path parameters become By<Name>:

Endpoint	Function
`POST /api/v5/quotes`	`postApiV5Quotes`
`POST /api/v5/bookings/{id}/confirm`	`postApiV5BookingsByIdConfirm`
`GET /api/v5/bookings/{id}`	`getApiV5BookingsById`
`HEAD /api/v5/bookings/{id}/label`	`headApiV5BookingsByIdLabel`
`GET /api/v5/bookings/{id}/label`	`getApiV5BookingsByIdLabel`
`GET /api/v5/tracking/{reference}`	`getApiV5TrackingByReference`
`GET /api/v5/members/payment-methods`	`getApiV5MembersPaymentMethods`
`GET /api/v5/bookings/v4/api_details`	`getApiV5BookingsV4ApiDetails`

Pass path parameters in path, query parameters in query and the JSON body in body:

import { postApiV5BookingsByIdConfirm } from '@transdirect/api-sdk';

await postApiV5BookingsByIdConfirm({
  path: { id: '34512345' },
  body: { courier: 'demo', pickup_date: '2026-10-19', payment_method: 'demo' },
});

The API key configuration endpoints live under /api/v5/bookings/v4/..., so their functions contain V4. Other functions with V4 in the name are older aliases kept for existing code; use the function without V4.

PDFs and other binary responses

Labels, manifests and invoices are PDFs. Ask for the bytes with parseAs:

import { writeFile } from 'node:fs/promises';
import { getApiV5BookingsByIdLabel } from '@transdirect/api-sdk';

const { data, error } = await getApiV5BookingsByIdLabel({
  path: { id: '34512345' },
  parseAs: 'arrayBuffer',
});
if (!error) await writeFile('label.pdf', Buffer.from(data as ArrayBuffer));

Other languages

Any OpenAPI 3 generator can build a client from the spec. For example, with OpenAPI Generator:

npx @openapitools/openapi-generator-cli generate \
  -i https://api.transdirect.com.au/openapi.json \
  -g python \
  -o transdirect-client

Swap python for php, java, csharp, go or another generator. The spec declares the api-key header as its security scheme (ApiKeyAuth), so most generated clients have a setting for the key.

Regenerate when the spec version changes; the changelog says what changed.

For AI agents

Give an agent the spec URL above rather than these pages. For the prose documentation, this site publishes an llms.txt index. Point agents at a key with demo mode switched on, so that test bookings cost nothing.

Versioning

The API version is info.version in the spec, and it follows semantic versioning:

Change	Version bump	Example
Descriptions and documentation only	Patch, such as `5.4.0` to `5.4.1`	A clearer field description
Additive: a new endpoint, or a new optional field	Minor, such as `5.3.0` to `5.4.0`	`customer_reference` on bookings
Breaking: a removed or renamed field, a changed type or stricter validation	Major, with a new path prefix such as `/api/v6`	None so far

The path only changes on a major version. Everything in v5 stays under /api/v5.
Within v5, new fields can appear in responses at any time. Ignore fields you do not recognise rather than failing on them.
The SDK is versioned to match the spec it was generated from.
To see the version that is live, read info.version from /openapi.json.