When a Simple Label-Printing Automation Becomes an Operations Problem

#When a Simple Label-Printing Automation Becomes an Operations Problem

A case study in building a multi-carrier fulfilment pipeline with n8n

At first glance, the requirement sounded simple:

When an order arrives, create a shipping label.

That kind of automation can look like a short workflow: receive an order, call a carrier API, save the label, and move on.

The reality was different. Orders were coming from a multi-channel ecommerce operation, while shipping was handled through several carrier services with different rules, payload formats, authentication flows, and response structures.

The difficult part was not making one API call. It was creating a dependable operational path for every order, including the awkward ones.

#The problem behind the label

A marketplace order does not always arrive in the shape a carrier expects.

An order may contain several line items. Weight may need to be calculated from quantity and product data. Dimensions may be missing or zero. A large order may need to be split into multiple shipments. Different destinations may require different services. Some shipping methods may trigger surcharge logic.

Then there is the carrier layer.

Amazon Shipping, Royal Mail, and Evri/Hermes each have their own integration requirements. One flow may involve requesting rates before selecting a shipment service. Another may expect a direct order payload. A third may require XML construction and response parsing.

If all of that logic is placed directly into one large workflow, the system quickly becomes difficult to understand and even harder to recover when something goes wrong.

#The approach: one common pipeline, carrier-specific edges

We used n8n as an orchestration layer around the existing order operation.

The core design was to keep common fulfilment logic in the middle and move carrier-specific complexity to the edges.

Order sources\n    ↓\nNormalize orders and line items\n    ↓\nCalculate package data\n    ↓\nApply fulfilment rules\n    ↓\nChoose carrier path\n    ↓\nCreate and store label\n    ↓\nRecord LABELLED or FAILED

This meant the workflow could make common decisions once, without forcing every carrier integration to understand the original marketplace payload.

#Step 1: normalize the incoming orders

The workflow retrieves unshipped orders on a schedule and maintains pagination state so it can work through larger result sets.

Each order is separated from its line items and transformed into a consistent internal structure. Orders and items are then stored centrally through idempotent upserts. If the same order is encountered again, the system can update the existing record instead of blindly creating a duplicate.

That central model becomes the contract between order intake and fulfilment.

It contains the information needed later for routing and label creation: customer delivery data, marketplace, SKU, quantity, shipping method, weight, dimensions, processing state, and label information.

#Step 2: calculate the parcel before calling a carrier

The carrier cannot generate a reliable label without usable parcel data.

A custom transformation calculates total package weight from item quantity and unit weight. It also derives package dimensions using the configured packing heuristic. The workflow checks whether the resulting values are missing or zero before continuing.

This validation is important because a technically successful API request can still represent a bad operational result. A label generated from incomplete parcel information may be rejected later, charged incorrectly, or require manual correction.

#Step 3: route according to fulfilment rules

The workflow branches according to the characteristics of each shipment.

Some of the decisions include:

• Whether the order belongs to Amazon or another channel
• Whether the destination is domestic or international
• Whether a marketplace-specific path is required
• Whether the parcel exceeds a weight threshold
• Whether an order needs to be broken into multiple shipments
• Whether surcharge conditions apply
• Which shipping method and postcode rules are relevant

These rules are what turn the automation into an operational system. Without them, the workflow would only be moving data from one API to another.

#Step 4: use the right carrier integration

Once the route is selected, the workflow uses the appropriate carrier-specific branch.

For Amazon Shipping, the process includes access-token handling, rate retrieval, rate selection, and shipment creation.

For Royal Mail, the workflow builds the carrier order payload and submits it through the parcel API.

For Evri/Hermes, the workflow constructs the required XML request, sends the pre-advice and label request, parses the response, and extracts the useful label information.

The common pipeline stays consistent, while the integration details remain isolated to each carrier path.

#Step 5: make the outcome explicit

A fulfilment system should never leave an order in an ambiguous state.

When a label is created, the label and tracking data are written back to the central data layer and the order is marked LABELLED.

When validation or carrier processing fails, the order is routed through a failure path and marked FAILED.

That distinction creates a usable exception queue. Operators can investigate failed orders without searching through multiple carrier portals or guessing whether an order was already processed.

The workflow also uses batching, controlled loops, and wait steps where processing volume or external API behaviour requires pacing.

#What made the project valuable

The value was not the novelty of printing a label through an API. The value was fitting several carrier processes around an existing ecommerce operation without replacing the order platform.

The automation created one controlled fulfilment path while preserving the differences that mattered at the carrier boundary.

The final design can be summarized in one sentence:

Keep the order logic common, keep the carrier logic isolated, and make every outcome visible.

That is the point where a simple label-printing request becomes an operations problem. The label is only the final artifact. The real system is the set of decisions, validations, integrations, retries, records, and exception states that make the label trustworthy.

Technologies: n8n, REST APIs, Amazon Shipping, Royal Mail, Evri/Hermes, PostgreSQL, Supabase, JavaScript, JSON, XML

Portfolio note: This case study intentionally omits client-identifying information, credentials, customer data, internal IDs, and unsupported performance claims.