How to Get a Royal Mail Click & Drop API Label

If you run a UK e-commerce operation on a Royal Mail Online Business Account and you're tired of someone manually importing a CSV into Click & Drop every afternoon, the Royal Mail Click & Drop API is the tool that removes that person from the loop. This walkthrough takes you from a cold OBA login to a printable PDF label and a submitted end-of-day manifest, using the actual endpoints, field limits and error codes you'll hit along the way — including the one failure mode that catches almost every first integration.

What you need before starting

You need a live Royal Mail OBA, not just a Click & Drop personal account. The Shipping API provides integration with RoyalMail Click & Drop, enabling users with a RoyalMail Click & Drop account linked to their RoyalMail OBA account to leverage this integration. Without that linkage, you can create orders through the API but you will not be able to pull paid labels back out, because the personal tier routes payment through the web UI rather than the API.

• A Royal Mail OBA, already approved and linked to a Click & Drop account
• Access to the Click & Drop dashboard to generate an API key (no OAuth client ID/secret needed for this route)
• The developer reference at api.parcel.royalmail.com open in a second tab
• A sandbox mindset before you touch production — the Click & Drop developer environment includes a sandbox for testing, and all integration development should happen against the sandbox before connecting to your live account, since the sandbox returns realistic responses including label data and tracking numbers

Step by step: from dashboard to API key

This is the part every third-party plugin doc gets right because it's copy-pasted from the same source screens, but it's worth doing once yourself so you understand what the key actually authorises.

1. Log into the Click & Drop dashboard and go to Settings, then Integrations. To begin, log in to your Click & Drop account, and navigate to 'Settings' > 'Integrations'.
2. Add a new integration and choose the API option specifically, not the screen-based Pro Shipping flow. From the list that appears, select 'Click & Drop API'.
3. Set a default trading name on the integration — this is what prints as your return address, and should you wish to import orders with a different trading name or company identity, you will need to specify this information in the call itself.
4. Expand the saved integration row and copy the authorisation key. From the integration settings page within Click & Drop, click your Click & Drop API integration to expand the row, and your authorisation key will be displayed there. Treat it like a password — it's important you keep your API key secret and do not share it publicly.
5. Fire a test call before writing any order logic. The header pattern is fixed: curl --location --request POST 'https://api.parcel.royalmail.com/api/v1/Orders' --header 'Authorization: aaaaaa-bbbb-cccc-dddd-eeeeeeee'. A 401 here means the key is wrong or missing; any API requests made without authorisation will fail.

One scope limit to flag now rather than after you've built against it: the API lets you create orders, retrieve order and label info, reset orders, and mark them despatched, but it cannot retrieve labels and other documents for OLP accounts — OLP being the personal, pay-as-you-go tier rather than OBA. If your test account is OLP, stop and get the OBA linkage sorted first.

Creating the order and pulling the label

Once the key works, order creation is a straightforward POST to the orders endpoint with sender, recipient, service code and package details. The response gives you an order identifier, which is what you use for every subsequent call. You know it worked when that identifier resolves on a GET and a label document comes back on the labels endpoint — the labels API path sits under https://api.parcel.royalmail.com/api/v1, with GET /orders/{orderIdentifiers}/label returning a single PDF file with the generated label and associated documents.

Standard printers get PDF by default. If you're running thermal hardware on a despatch bench, you have another option: the integration can request labels in ZPL format from the Royal Mail API and route them directly to a configured Zebra, Dymo or BIXOLON thermal printer via TCP/IP, which removes the PDF-to-printer-driver hop entirely if you're printing at volume.

Worth knowing before you architect your label-generation flow around "create order → label instantly appears": community reports on the Click & Drop UserVoice forum describe cases where the API requires a manual dashboard visit to generate a label before the label endpoint returns anything, depending on account configuration and whether label generation was requested inline on order creation. Test this against your own account before assuming the happy path. If inline generation isn't returning a label, create the order without it, then call the labels endpoint separately using the returned order identifier.

The manifest step most tutorials skip

OBA accounts are invoiced off the manifest, not off individual label creation, and this is where unattended integrations quietly break. Royal Mail's own invoicing mechanism depends on it, and other carrier guides in this space are blunt about the consequence: Royal Mail requires you to print a Sales Order Summary for your day's shipments, which is how Royal Mail invoices your label fees to your account, and failure to do this can result in extra charges on your bill. A missed manifest doesn't just mean a billing headache either — without it, Royal Mail has no record that day's parcels exist on their system, so collection drivers have nothing to scan against. Automating the manifest call is the entire point of using the API over the manual dashboard: it removes the "did someone remember to close the day" risk completely.

A successful manifest response gives you a document reference you can download; a stalled one typically means the manifest request timed out against Royal Mail's own OBA systems rather than your integration failing outright. Third-party trackers have logged exactly this pattern before — intermittent connection issues with the OBA API have caused manifests from third-party software to occasionally fail to complete, with Royal Mail aware of the issue, and the usual fix is waiting 5–10 minutes and retrying. Build that retry into your manifest job rather than alerting on the first failure.

Failure mode: the auto-manifest cutoff

This is the one that catches almost every team in their first month, usually because a customer cancels an order after close of business. You try to void the label through the API and get back an error you don't recognise.

Error E1233 — "Shipment cannot be cancelled due to its current status" — means the shipment was already auto-manifested on the carrier's side and it's no longer possible to void the label, because auto-manifesting occurs once per week with Royal Mail, for example on Friday at 11pm. From that point, the order is Royal Mail's problem to solve, not yours. The documented remediation is narrow: contact Royal Mail directly to ask if the label can be voided, understanding that the void may or may not be possible.

The lab takeaway: don't let your cancel/void logic rely on Royal Mail rejecting a late request gracefully. Build a pre-manifest cutoff check into your own order state machine — if a cancellation request arrives after your last manifest submission of the cycle, flag it for manual handling immediately instead of firing a void call that will come back as E1233 and leave the order in limbo.

Known API limitations to design around

A handful of constraints aren't obvious until a label request bounces. Design for these up front rather than discovering them in production.

Where this sits in the broader multi-carrier landscape

Most teams don't end up maintaining a bare Click & Drop adapter in isolation for long, because the quirks above — the weekly auto-manifest cutoff, the OBA-only label retrieval, the missing rates endpoint — are exactly the kind of carrier-specific friction that multi-carrier platforms exist to absorb. ShipEngine, Sendcloud, nShift, EasyPost and Cargoson all sit behind Royal Mail (and DHL, DPD, GLS and the rest) with their own normalised order and label objects, so your application code stops needing to know that E1233 is a Royal Mail-specific void error rather than a generic cancellation failure. For shippers managing several carrier contracts at once rather than just Royal Mail, a shipper-side TMS layer like Cargoson is built specifically around that problem: one interface over many carrier APIs, rather than one more bespoke adapter to maintain alongside DB Schenker, DPD or GLS integrations you've already built.

One thing this write-up leaves open: whether Royal Mail's older OAuth2 Pro Shipping API is meaningfully more reliable than Click & Drop's API-key model at higher volume, or whether it just trades one set of quirks for another. That's a benchmark worth running on its own, with both APIs hit from the same test harness over the same week — flag it as untested for now.