SDKs & versioning

The Transdirect API ships an official, fully typed TypeScript SDK that is generated from the API’s OpenAPI specification — so the types you code against are always exactly what the API accepts and returns.

Generated, not hand-written

Everything flows from one source of truth: the API’s published OpenAPI specification at https://api.transdirect.com.au/openapi.json. The SDK is generated from that spec, and this developer center (the API Explorer and reference) is built from the same spec — so you never hand-write a request shape, and the docs, the spec and the SDK cannot drift apart. Every release of the SDK matches exactly what the API accepts and returns. And because the spec is public, you can generate a client in other languages from it too — see Other languages.

Using the SDK

pnpm add @transdirect/api-sdk

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

client.setConfig({
  baseUrl: 'https://api.transdirect.com.au',
  headers: { 'Api-Key': process.env.TD_API_KEY! },
});

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

Every endpoint in this reference is available as a typed function. Each call returns { data, error, response } — data on success, data/error holding the parsed body on failure (the Response body is already consumed, so read data/error, not response).

Full runnable examples — quote, create → confirm, labels, tracking, pickup availability, locations, items CRUD, customs and API-key configuration — ship with the end-to-end TypeScript examples that accompany this developer center.

Versioning

The API and SDK are versioned together with semantic versioning, keyed off the OpenAPI spec’s info.version:

Change	Version bump	Example
Docs / description only	patch (5.1.0 → 5.1.1)	Clarify a field description
Additive — new route, new optional field	minor (5.1.0 → 5.2.0)	Add GET …/api_details/full
Breaking — removed/renamed field, changed type, stricter validation	major (5.x → 6.0.0)	Remove a response field

Rules that keep this predictable:

• info.version is the single source of truth. It is published in the spec at /openapi.json and changes with every API release.
• The SDK version mirrors info.version exactly. A given @transdirect/api-sdk release always matches the spec it was generated from.
• The URL path only changes on a major. Today that’s /api/v5. A breaking release would ship under a new /api/v6 prefix and run alongside v5 during a deprecation window — your existing integration keeps working.
• Minor and patch releases are backwards compatible. New fields are additive; pin a minor if you want to opt into new capabilities deliberately.

Tip

Because the SDK is generated, upgrading to a new minor is usually just pnpm up @transdirect/api-sdk — new endpoints and fields appear as new typed functions and properties, and nothing existing changes.

Other languages

The OpenAPI spec is published at /openapi.json. Any OpenAPI generator (openapi-generator, Kiota, Hey API, etc.) can produce a client in your language from it — the same spec that powers the TypeScript SDK and this site.