Shipping and fulfilment

MyParcel already has a plugin for your shop. The gap is usually somewhere else

Most Dutch webshops on WooCommerce already run the official MyParcel plugin, and for a straightforward shop it does the job: a label per order, PostNL or DHL as the carrier, a delivery-options widget at checkout. The plugin was built for the ordinary case, and it is good at it.

What it was not built for is everything that makes a shop not ordinary: a mailbox-parcel flag that depends on real dimensions instead of a guess, an age check that has to reach the carrier and not just the checkout page, or an order flow that comes from somewhere other than a WooCommerce cart.

  • REST API, mostly used through the WooCommerce plugin
  • Mailbox parcels, age checks, insured and signature options
  • From €1,700 plus service fees
The tool

What MyParcel is, and where the plugin stops

MyParcel is a Dutch shipping service built around PostNL, DHL and DPD, aimed squarely at Dutch and Belgian webshops rather than being a global multi-carrier platform. Its strengths are the local details: mailbox parcels (brievenbuspakjes) at a lower rate for anything that fits through a letterbox, evening delivery, pickup points, and delivery-day selection Dutch shoppers have come to expect.

For WooCommerce and Shopify it ships as an official plugin that most shops install and never touch again, which is exactly right for a shop selling one kind of product at one kind of size. The API underneath the plugin is open, so a shop that has outgrown the plugin's defaults — a mix of tiny and bulky products, restricted items, a checkout the plugin was not written for — can be built against directly.

What goes wrong

Three things that go wrong around a MyParcel connection

All three happen because the plugin makes a reasonable default assumption, and a shop's real catalogue does not match it.

Every parcel ships at parcel rate, even the ones that fit through a letterbox

The mailbox-parcel rate needs real dimensions to qualify, and most product catalogues were never measured that precisely — everything just has a weight. So a phone case, a book or a set of earbuds ships as a full parcel at a full parcel price, a few euros more each time, on products shipped by the hundred.

What you see instead

Dimensions are captured once per product and MyParcel decides the rate from the real size, not a guess. On a catalogue of small items this alone often pays for the connection within a season.

The age check happens at checkout and stops mattering after that

A shop selling alcohol or vapes ticks a box at checkout asking the customer to confirm they are eighteen, and treats that as compliance. PostNL and DHL both offer an actual age check at the door, but it only happens if the shipment is flagged for it — and a checkbox on a website does not flag anything by itself.

What you see instead

A product flagged as age-restricted carries that flag all the way into the shipment, so the carrier actually checks ID at the door instead of the website checking a box against nobody.

Orders that do not come from the cart never reach MyParcel at all

A phone order, a marketplace sale, a subscription renewal — anything that is not a normal WooCommerce checkout does not pass through the plugin, so somebody creates that shipment by hand in the MyParcel backend, retyping an address that already exists somewhere.

What you see instead

Any order source that can call an API can create a shipment the same way the plugin does, so the exception stops being a manual job and becomes just another order.

The bill for doing it by hand

What the plugin's blind spots cost, per order

The mailbox-parcel gap is the clearest one to price: the rate difference between a mailbox parcel and a standard parcel is typically a few euros. On a catalogue where half the SKUs would qualify and a thousand orders a month go out at the higher rate by default, that is a genuinely traceable amount lost every month for no reason other than a field that was never filled in.

The manual-order gap is smaller in volume and larger in irritation: every order created by hand in the MyParcel backend takes three to five minutes, and it is exactly the order type — phone, marketplace, subscription — most likely to need a correction afterwards because it was typed once by someone in a hurry.

What we build

We build the thing on the other end too

For most shops on MyParcel the honest first move is checking whether the plugin's settings are simply wrong, not whether a custom connection is needed — a surprising share of the mailbox-parcel losses we find are a configuration fix, not a project.

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 MyParcel

Some of this the plugin already does. We list it anyway, because knowing which rows are plugin territory and which need custom work is the actual question most shops have.

  • Orders into MyParcel as a shipment (out of the tool)

    Address, carrier, weight and dimensions, created per order. Standard territory for the plugin; custom only when the order does not come from the normal checkout.

  • Mailbox-parcel eligibility per product (into the tool)

    Real dimensions decide whether an item qualifies for the lower rate. More often a product-data fix than an integration one, but the two need to be connected for it to matter.

  • Age-restricted flag through to the carrier (out of the tool)

    Passed through to PostNL or DHL's own ID check at the door, for alcohol, vapes and similar products, instead of stopping at a checkbox on the checkout page.

  • Insured value and signature required (into the tool)

    Set per order based on cart value rather than a flat setting applied to everything, so a €15 order and a €900 order are not insured the same way.

  • Tracking status back to the shop (out of the tool)

    Delivery status as a webhook, feeding order status and customer emails without anyone checking a separate tracking page.

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.

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

If your shop is a standard WooCommerce or Shopify catalogue without restricted products, the official plugin is almost certainly cheaper than anything we could build, and we will say so before quoting. Custom work earns its keep on mailbox-parcel accuracy at real volume, age-restricted products, or an order source the plugin does not cover.

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 MyParcel

Usually you would not, and that is the honest first answer. The plugin handles the ordinary shop well; custom work is for the parts it was not designed for.

The two we see most often: a catalogue where mailbox-parcel eligibility is being missed on real volume, and an order source outside the normal cart — phone orders, a marketplace, a subscription tool — that the plugin never sees.

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.