Software · Developer and integration
SDKs and client libraries
Typed, documented client libraries that make your API easy to adopt in the languages your users write.
Developers judge an API by their first ten minutes with its SDK. We build client libraries that feel native in each language, with typed models, sensible defaults, pagination helpers and clear errors. Generating them from your OpenAPI spec keeps them in step with the API, and hand-written layers fix the parts generators get wrong.
What we build
- SDKs generated from your OpenAPI spec, then refined by hand for idiomatic use
- Typed request and response models with validation and helpful error classes
- Built-in retries, timeouts, pagination and webhook signature verification
- Mobile SDKs for Android in Kotlin and iOS in Swift, kept small for app bundles
- Reference docs, quick-start guides and runnable examples for each language
- Release pipelines that publish to npm, PyPI, Maven Central and Go modules
DemoInteractive · sample data
Try it live.
A working sample with made-up data. It runs in your browser; nothing is sent anywhere.
import { Tidepost } from "@tidepost/sdk";
const client = new Tidepost({
apiKey: process.env.TIDEPOST_KEY,
maxRetries: 3,
});
const shipment = await client.shipments.create({
from: "BLR-WH1",What it does well
Idiomatic code
Each SDK follows its language’s conventions, from async iterators to context cancellation.
Typed everywhere
Editors autocomplete every field, and mistakes show up before the code runs.
Sensible defaults
Retries with back-off, timeouts and pagination work without extra setup.
Stays in sync
A spec change regenerates every SDK and runs its tests automatically in CI.
Semantic versions
Breaking changes bump the major version and come with a migration guide.
Small footprint
Few dependencies keep install size low and supply-chain exposure small.
Questions
Why not just publish the OpenAPI spec?
A spec lets developers generate their own client, and some will. An official SDK saves every customer that work, handles authentication, retries and pagination consistently, and gives you control over the first experience developers have with your API. It also cuts support questions about the basics.
Which languages should we support first?
Look at who calls your API today. Request logs and user-agent strings show which languages your customers use. Most B2B APIs start with TypeScript and Python, add Go, Java or C# for enterprise users, and add Swift and Kotlin when mobile apps call the API directly.
How do you keep several SDKs consistent?
They share one source of truth, the API spec, and one set of test scenarios that every SDK must pass. A single CI pipeline regenerates code, runs the tests in every language and publishes together, so versions and behaviour do not drift apart.