Shipping and fulfilment

The label gets made the moment the order does, not whenever someone opens the panel

An order comes in at half past four. The Sendcloud panel is open on a browser tab somewhere, and the label for it gets printed at the next batch — five o'clock, when someone remembers, or tomorrow morning if they do not. The customer paid for next-day delivery and got an apology instead.

Sendcloud itself does none of that badly. It generates the label, picks the carrier, prints the customs form when there is one. What decides whether an order ships the same day is whether something tells Sendcloud about it the moment it exists, or whether a person has to notice first.

  • REST API with webhooks for status updates
  • Your own carrier contracts or Sendcloud's
  • From €1,700 plus service fees
The tool

What Sendcloud is, and which part of it we connect

Sendcloud is a Dutch multi-carrier shipping platform: one panel and one API in front of PostNL, DHL, DPD, GLS, UPS, bpost and a long list of others, so a shop does not need a separate account and a separate integration for each. It handles label generation, the delivery-options widget shoppers see at checkout, tracking emails, a branded tracking page, and a self-service returns portal customers use instead of emailing you.

Carrier contracts can go either way: you bring your own rates and Sendcloud simply operates them, or you ship on Sendcloud's own bundled contracts and pay per label. Which one you are on changes almost nothing about the connection itself, but it changes the invoice, and it is worth checking which you actually have before assuming the other.

What goes wrong

Three things that go wrong between a shop and Sendcloud

All three come from the same root: Sendcloud reacts to what it is told, and if it is told late, or told the wrong weight, everything downstream inherits the mistake.

Labels get made in a batch, not the moment the order does

Orders trickle in all day, but the panel only gets opened once or twice — after lunch, at the end of the day. An order placed at half past four for next-day delivery ships the following morning instead of that evening, and the courier collection that afternoon leaves without it.

What you see instead

An order creates its Sendcloud shipment the second it is placed, and the label exists before anyone thinks to look for it. The daily collection leaves with everything that was ready, not everything somebody remembered to print.

The wrong weight picks the wrong service, and the surcharge shows up a month later

A product's weight in the shop is whatever somebody typed when it was added, often a round number nobody has checked since. Sendcloud books a service against that number, the carrier weighs the real parcel, and the difference lands as a correction on next month's carrier invoice — a page of small surcharges nobody can trace back to an order.

What you see instead

Real dimensions and weight travel with the order from the product data that actually gets maintained, and a mismatch large enough to matter raises a flag before the label is bought, not after the invoice arrives.

Returns come in by email, and the parcel arrives before the request does

A customer wants to return something, emails, waits for a reply, prints whatever label they are sent, and the parcel arrives at the warehouse days before anyone connected it to an order. Sendcloud has a returns portal built for exactly this and it sits unused because nothing on the site links to it.

What you see instead

The customer opens the returns portal from their order confirmation, picks a reason, gets a label instantly, and the return is already logged against the order before the parcel is anywhere near the warehouse.

The bill for doing it by hand

What manual label printing and reconciling actually costs

Take a shop doing sixty orders a day. If labels are made in two or three manual batch imports rather than automatically, someone spends fifteen to twenty minutes per batch checking what needs shipping — roughly an hour a day, five hours a week, on a task that exists purely because nothing tells Sendcloud about an order automatically.

The surcharge problem is smaller per incident and more corrosive over time: a handful of weight corrections a month at a few euros each is not a number anyone will fight about, right up until someone adds it up over a year and it is several hundred euros nobody budgeted for and nobody can explain.

  • An hour a day of manual batch imports on sixty orders: five hours a week.
  • A handful of weight surcharges a month, invisible until totalled over a year.
  • A returns inbox that duplicates a portal Sendcloud already gives you for free.
What we build

We build the thing on the other end too

For Sendcloud the connection itself is rarely the hard part — their API is good; the work is almost always on the shop side, making sure the order that reaches Sendcloud already carries the right weight, the right address format and the right service choice.

A connection needs two ends. Plenty of agencies will build you the API call and hand you a JSON payload; that is the easy half. The harder half is what the data lands in — a website, a webshop, a portal your customers log into, an internal tool that replaces a spreadsheet. JKC builds both ends, which is why the connections we build tend to keep working: nothing about the receiving side is a black box to us.

API integrations

The connection itself: authentication, field mapping, rate limits, retries and a queue that survives the other system being down for an hour. Built against the documented API where there is one, and against whatever the vendor really offers where there is not.

Websites

WordPress sites that read from your systems instead of repeating them by hand: a careers page fed by your HR system, a team page that follows your payroll, prices and availability that are the real ones.

Webshops

WooCommerce shops where the order is the last time anyone types it: it becomes an invoice in your accounting package, a label at your carrier, a stock mutation in your warehouse, and a line in your CRM, on its own.

Web applications

When the process does not fit any standard product: a customer portal, a quoting tool, a planning board, a dashboard that reads three systems at once. Built on your data, with your systems as the source instead of a copy of them.

What can be connected

What can be connected between your shop and Sendcloud

Sendcloud's API is a genuinely well-documented REST API with webhooks, so most of this is a matter of choosing which fields matter to you rather than fighting the platform.

  • Orders into Sendcloud as a parcel

    Address, weight, dimensions and the chosen carrier service, created the moment the order is placed rather than in a batch. This is the row that fixes the four o'clock problem.

  • Delivery options at checkout

    Sendcloud's own widget showing real service points, delivery days and evening delivery, priced per carrier. Feeding it the right postcode and product weight up front is what keeps the options it shows honest.

  • Tracking status back to the shop and the customer

    Announced, collected, en route, delivered, exception — as a webhook the moment Sendcloud knows it, not a status a customer has to look up on a separate tracking page.

  • Returns through the self-service portal

    A customer starts a return from their own order, gets a label without emailing anyone, and the return status comes back into the shop so a refund can follow the parcel instead of a phone call.

  • Customs data for shipments outside the EU

    HS codes, value and origin per line, generated from product data rather than typed per parcel, because a missing customs form is the single most common reason a parcel sits in a depot.

Rows one and three are close to universal; rows two, four and five depend on whether you sell internationally and how much of the delivery experience you want under your own brand rather than Sendcloud's.

How it works

How a connection gets built at JKC

The same four steps every time, whichever tool it is. Nothing here is a workshop you pay for: step one exists because scoping a connection wrong is the single most expensive thing that can happen to it.

  1. 1. We look at what is actually being retyped

    Not "which fields exist" but "which fields does somebody currently move by hand, how often, and what breaks when they get it wrong". Most projects turn out to need two or three flows, not a full two-way sync of everything. That conversation is what keeps the quote where it is.

  2. 2. We pick the route, and say why

    A maintained connector from the vendor, a platform like Make or Zapier, or a custom integration against the API. Cheapest first, not custom first: if a supported plugin does exactly what you need, that is the answer and we will tell you so. Custom is for the cases where the off-the-shelf option would need so much configuring that it becomes the fragile option.

  3. 3. We build it to survive the other system

    Every connection ships with retries, a queue and an idempotency key, so an order that arrives while the other side is down is delivered later rather than lost, and a retry does not create a second invoice. On a test environment first where the vendor offers one, so the first thing your real administration sees is a working connection.

  4. 4. We hand it over with the failure modes written down

    Which alerts you will get, what each one means, what to do about it, and who to call. Plus the credentials in your own name, in your own vault — not in ours. A connection nobody but us can maintain is a connection you do not own.

More about system integrations at JKC

After it goes live

A connection that fails silently is worse than no connection

This is the part most quotes leave out. A connection that stops working without telling anyone is worse than manual work, because with manual work at least somebody notices when it does not get done. Every connection JKC builds is monitored, and the monitoring is not an upsell — it is in the service fee.

An alert per failed message, not a monthly report

A message that does not get through raises an alert the same hour, with the record it was about. Not a dashboard you have to remember to look at.

Replay, not re-enter

Anything that failed sits in a queue and can be sent again once the cause is fixed, in order. Nobody goes back through yesterday to find the four orders that did not land.

We watch the vendor's changes, so you do not have to

APIs get versioned, deprecated and rate-limited. When a vendor announces a change that affects your connection, adjusting to it is part of the service fee, not a new project.

What it costs

From €1,700, and the biggest variable is who built the other end

Sendcloud has an official WooCommerce plugin that covers the ordinary case well, and if that is what you have, custom work usually is not worth it. It earns its cost when you combine multiple sales channels into one shipping flow, need customs data generated automatically, or already have a shop we built where the order data is ready to use.

A connection starts from €1,700 plus a monthly service fee, which covers the monitoring, the queue and keeping up with the vendor's API changes. Work outside a fixed scope is €95 per hour.

What moves the number is not the tool — it is how well the system on the other end is known. If JKC built your website, your webshop or your web application, we already know its data model, its edge cases and where its stock numbers really come from, and a connection into it is mostly configuration and testing. If it is a system we have never opened, we start with a short technical check of both sides and quote after that, so you are not paying hourly for us to work out the basics.

Two more things that move it, in our experience more than anything else: whether the tool has a real API or only a CSV export, and whether the sync has to go both ways. One-way is roughly half the work of two-way, because two-way means deciding, per field, which system wins when they disagree — and that decision is the expensive part, not the code.

Questions

Frequently asked questions about connecting Sendcloud

If the plugin does everything you need — standard carriers, the standard checkout widget, orders created one at a time as they come in — then no, and we will tell you that in the first call rather than quote you anyway.

Custom work earns its place when the plugin's assumptions stop matching your shop: multiple webshops or marketplaces feeding one shipping process, product data that needs enriching before Sendcloud sees it, or a checkout you built yourself that the plugin was never designed to sit inside.

Often next to this one

Tools that often sit next to this one

Almost nobody connects one tool. These are the ones that come up in the same conversation, either because they sit in the same part of the business or because people ask for the two together.

See all integrations

Free, 10 minutes

Not sure where the manual hours actually go?

That is what the Growth Scan is for. Ten minutes, no sales call attached: you get back where the double work sits, which connection would pay for itself first, and which one honestly would not.

Do the free Growth Scan