Automatic InPost Labels for Allegro and WooCommerce Orders

couriersallegrowoocommerce

Packing dozens of parcels a day has one bottleneck that rarely gets mentioned: retyping the address from the order into the courier panel. The seller opens an order on Allegro or in WooCommerce, copies the recipient’s details, pastes them into the InPost label generator, picks a parcel locker, prints the label — and repeats it for every single shipment. At 20 parcels that’s an annoyance; at 200 it’s real hours of work and recurring mistakes.

This article explains how automatic InPost label generation should work when the data flows from the order rather than from human memory: how to map the delivery method, how the system knows which parcel locker the package should go to, and how to route the tracking number back into the order and to the customer. At the end — how to arrange it in practice.

Why manual labels cost more than they seem

Issuing labels by hand isn’t just about time. It’s three recurring costs:

Address errors — a typo in the postcode or the wrong locker number means a return, a complaint and another shipment at your own expense.
Systems drifting apart — the tracking number generated in the InPost panel doesn’t flow back into the order automatically, so the “shipped” status has to be clicked manually in every channel.
No single queue — you pack orders from Allegro and from WooCommerce in two different places, with no shared “to ship today” list.

The fix is to shift the center of gravity: the label isn’t created from what the packer retypes, but from the structured order data that is already in the system.

How an automatic label works — step by step

The target flow worth aiming for looks like this:

The order lands in a central system (OMS) from Allegro or WooCommerce in a normalized form: recipient, address, delivery method, chosen point.
The system maps the delivery method to a specific InPost service (e.g. “Parcel locker” → the locker service, “InPost courier” → the door-to-door service).
A courier API call creates the shipment from the order data — no manual retyping.
The label comes back as a file (PDF/ZPL) ready to print, and the tracking number is saved on the order.
The order status changes to “shipped”, and the tracking number can go to the customer.

The key point is that the packer doesn’t make the “which service and which address” decision — that data is already in the order. Their role comes down to printing and sticking the label.

Delivery method mapping — the heart of the whole integration

The hardest and most important element is mapping the delivery method from the channel to the courier service. Allegro and WooCommerce name their shipping methods their own way, and InPost has its own catalog of services. Without correct mapping, the parcel ends up on the wrong service or the label doesn’t generate at all.

What to pay attention to:

Allegro — delivery methods arrive as names defined in the seller’s shipping price list (e.g. “InPost parcel lockers”, “InPost courier cash on delivery”). Each has to be assigned to a specific courier service and to the cash-on-delivery or prepaid variant.
WooCommerce — delivery methods are identifiers from the shop’s shipping settings (a locker plugin often adds its own field with the chosen point). You map the method name to a service.
Cash on delivery (COD) — if the order is COD, the amount and how it’s settled must carry over to the label, otherwise the courier won’t collect the money.
A default rule — it’s worth having a fallback: if a method can’t be mapped unambiguously, the system flags the order for a manual decision instead of creating a wrong shipment.

A well-built mapping is set up once, and then it works for every subsequent order from that channel.

Parcel lockers — the pickup point must carry over from order to label

In Poland InPost means, above all, parcel lockers, and they introduce an extra piece of data that door-to-door delivery doesn’t have: the identifier of the chosen point (e.g. KRA010). This value is picked by the customer during checkout and must reach the label intact.

Common pitfalls:

A lost locker code — if the integration pulls the address but not the point-code field, the label is created without a destination or with an error. The pickup point is a separate field, not part of the address.
Locker compartment size — lockers come in A/B/C sizes; it helps if the order carries information about the parcel size or a default size per product.
The customer changing the point — if the buyer updated the locker after placing the order, the system should take the current value, not the original one.

Rule of thumb: treat the locker identifier as first-class data — as important as the address. If it flows correctly, the rest of the label falls into place on its own.

Tracking — the shipment number must return to the order

Generating the label is half the job. The other half is closing the loop: the tracking number should come back from the courier into the order, so that everything is visible in one place and can be automated further.

Properly arranged tracking gives you:

Automatic status change of the order to “shipped” once the label is generated.
The tracking number saved on the order — you don’t hunt for it in the InPost panel, it’s right next to the customer.
A notification to the customer — an email or SMS with the number and a tracking link, sent automatically after dispatch.
Sending status back to the channel — ultimately the shipping status can also return to Allegro or WooCommerce, so the buyer sees current information where they bought.

This is exactly the stage where the automation engine shows its full potential: the event “label generated” triggers the rule “send an SMS with the number and set the status to shipped”.

Best practices for rollout

Before you turn on automatic labels across all your traffic, it’s worth going through a few steps:

Start with one delivery method — most often the InPost parcel locker — and check the full flow on a few test orders.
Verify the mapping against real names of the deliveries from your Allegro and WooCommerce, not against sample ones.
Set a fallback for unmapped methods, so an exception doesn’t block packing.
Print in batches — it helps when the system can generate labels for the whole “to ship today” list at once.
Close the tracking loop — make sure the number returns to the order and triggers a notification before you consider the rollout finished.

We write more about designing “if this, do that” rules themselves in the guide on e-commerce order automation, and about tying the courier to invoices and channels — in the piece on connecting Allegro, WooCommerce, InPost and invoices in one system.

Where Sellaro fits in (honestly about the status)

Sellaro is a central OMS — it gathers orders and products from all connected channels into one normalized view and has an automation engine that reacts to domain events (a new order, a status change) with actions: email, SMS, webhook, a log entry. This is the foundation on which automatic labels make sense — because the order data is already organized in one place.

But we need to be clear about where we are:

Ready today: the store modules PrestaShop, Sylius, WooCommerce (connecting a shop as a channel, READ-ONLY — Sellaro doesn’t write to the shop).
On the roadmap / added on request: Allegro and courier integrations, including InPost (and other couriers), as well as accounting.

In other words: automatic InPost labels for Allegro and WooCommerce orders are the direction we’re heading as a module added to the platform, not a ready “print” button in the panel today. We work by the rule that we add a missing integration free of charge as part of the package — if InPost is your main courier, flag it during onboarding and we’ll set it up as a priority.

Frequently asked questions

Does Sellaro generate InPost labels automatically today?

It’s a roadmap feature, added as a module on request — not a ready button in the panel today. The foundation (normalized orders and an automation engine) is already there, so once we connect InPost, the label is created from the order data without retyping the address. Flag InPost during onboarding and we’ll set it up as a priority.

How does the system know which locker to send the parcel to?

The locker identifier (e.g. KRA010) is picked by the customer at checkout and arrives with the order as a separate field — not as part of the address. A correct integration carries this value all the way to the label; if the customer changed the point, the current choice is used, not the original one.

What about cash-on-delivery (COD) orders?

The COD amount and how it’s settled must carry over from the order to the label, otherwise the courier won’t collect the money. That’s why the delivery method mapping distinguishes the “cash on delivery” variant from “prepaid” — it’s part of a correct configuration, not a detail.

Will the tracking number return to the order and to the customer?

That’s exactly the point of a closed loop: after the label is generated, the tracking number is saved on the order, the status changes to “shipped”, and automation can send the customer an email or SMS with the number and a tracking link.

Summary

Automatic InPost labels aren’t magic, just a correct data flow: an order from Allegro or WooCommerce → a normalized view in the OMS → delivery method mapping → a label from the data → the tracking number back in the order. Whoever arranges this stops retyping addresses and eliminates the most common shipping errors.

At Sellaro we’re building the foundation for this — normalized orders and the automation engine work today, while InPost and Allegro are on the roadmap and we add them on request (a missing integration free of charge as part of the package). Work out your cost in the pricing and tell us which couriers and channels you need — we’ll set them up as a priority.