We Just Shipped Official SDKs for Node.js, Python, and PHP

I have been watching our API logs for the past year. You know what I see? A lot of hand-rolled HTTP clients. Manually constructed payloads. Raw requests with JSON dumps. And yes, in 2025, some truly creative approaches in PHP that I will not describe in detail.

It works. Sure. But it is not great. No autocomplete in your editor. No type safety. No built-in error handling for the carrier-specific edge cases that will inevitably bite you at the worst possible time.

So we built the thing you have been asking for. Today we are releasing official Uniship SDKs for Node.js, Python, and PHP.

Why SDKs matter more than you think

I will be honest - we should have done this sooner. I have personally responded to too many support tickets that boiled down to a missing content type header or a malformed JSON payload. SDKs eliminate an entire class of integration bugs. Just gone. You do not have to think about HTTP headers or JSON serialization or remembering the exact endpoint path.

We set ourselves a design goal when building these. Creating a shipment should take just a few lines. You import the SDK, initialize it with your API key, and call the create method with your shipment details. The SDK returns a typed response with your tracking number and label URL. That is it.

For the Node.js SDK you install the package from npm and you get full TypeScript types included out of the box. Every carrier option, every shipment field, every webhook event - fully typed. Your IDE will actually help you instead of just sitting there.

The Python SDK works with Python 3.9 and above. It includes async support for teams running FastAPI or similar frameworks. And it uses Pydantic models for request and response validation which means you catch problems before they hit the network.

For PHP the SDK requires version 8.1 or later and is compatible with PSR-18 HTTP clients. So it works with Guzzle, Symfony HTTP Client, or whatever you are already using. No need to rip out your existing HTTP setup.

What the SDKs cover

All three SDKs cover the full Uniship API surface. Everything. The Shipment API for creating and canceling shipments, getting rates, and generating labels. The Tracking API for tracking shipments and managing webhook subscriptions. The Printing API for batch label generation in multiple formats. The PUDO Map for searching pickup and drop-off points by location. And the Address API for validating and autocompleting addresses across European countries.

Beyond the core API coverage, each SDK also includes automatic retries with exponential backoff for transient errors like server errors and timeouts. Rate limit handling that backs off automatically when you hit limits. Built-in support for idempotency keys so you do not accidentally create duplicate shipments. And detailed error objects - not just HTTP status codes but structured errors with carrier-specific context.

That last one matters more than you might think. When DHL rejects a shipment because the street name exceeds 35 characters, you want to know it is a carrier validation error pointing to the recipient street field. Not a generic "bad request." I cannot tell you how many hours I have personally spent helping developers decode vague error responses from carrier APIs. These SDKs give you the context you need to fix problems immediately.

The speed difference is real

We noticed during development that developers using well-typed SDKs integrate three to four times faster than those working with raw HTTP. That is not a marketing number. We measured it. Our median time from API key creation to first successful shipment dropped from 2.3 hours to about 35 minutes during the beta period.

Part of that is just removing the boilerplate. No more manually constructing headers. No more remembering to stringify payloads. No more hunting through documentation for the exact endpoint URL. The SDK knows all of this already.

But a bigger part is the developer experience. When your editor can autocomplete field names and show you the expected types, you spend your time thinking about your business logic instead of fighting with an HTTP client.

Migrating from raw API calls

If you are already using Uniship through raw HTTP calls, switching to an SDK is straightforward. The request and response structures are identical. We did not invent new abstractions or rename fields. The SDK is a thin typed wrapper around the same REST API you are already using. Same payload, less boilerplate, better error handling.

I helped a team in Berlin migrate their existing integration last month. They had about 40 places in their codebase where they called our API directly. The migration took them a single afternoon and they immediately caught two subtle bugs that their raw implementation had been silently ignoring.

What is coming next

We are already working on a few things. A Go SDK is targeting later this year - Go is our third most requested language after Python and PHP. Webhook signature verification helpers will be built into each SDK so you do not have to manually verify signatures yourself. And we are working on a command-line tool for quick testing and label generation right from your terminal.

All three SDKs are open source on our GitHub. Issues and pull requests are welcome. If you run into anything weird our community channels are the fastest way to get help.