Skip to main content

QR / labelless return labels from Shipping Platforms

Written by Support team

The core concept: the Shipping Identifier controls everything

In Claimlane, whether you get a QR / labelless flow is not a toggle you can turn on/off in Claimlane.

It’s determined by the Shipping Identifier you enter for the shipping integration. If we don’t know the correct identifier format, we must look it up in the shipping platform’s documentation.

Quick concept: what ::: means in Claimlane

Claimlane’s Shipping Identifier is a single text field, but some shipping platforms require multiple pieces of information (e.g. carrier + agreement + service, or carrier ID + service ID). When that’s the case, we combine (“pack”) those values into the one field by separating them with

:::

So the identifier can look like:

part1:::part2:::part3

What each “part” means (and the order) is defined by the shipping platform’s documentation.

1) Homerunner: when you need :::

Symptom
You set a Homerunner return agreement (e.g. GLS) and still only get a normal label.

Cause
Homerunner can require multiple values in the shipping identifier (Carrier / Agreement / Service). Since Claimlane uses one field, we separate the parts using :::

Fix (GLS labelless return)
Use: gls:::business:::return_labelless

Homerunner expects three different values: carrier, agreement, and service... and in Claimlane we represent this as a single string separated by :::

Note (other Homerunner agreements)
Most other Homerunner agreements only need a single value, e.g.:
​gls_business_return

2) ShipStation: when you need ::: (carrier ID + service ID)

Symptom
Wrong label type, wrong service, or failure to generate the expected QR/label behavior.

Cause
ShipStation requires:

  • Carrier ID

  • Service ID

Fix
Put both values into the Claimlane Shipping Identifier field, separated by ::: <carrierId>:::<serviceId>

(Exact values depend on your ShipStation configuration.)

3) Shipmondo: labelless/QR is encoded in the identifier

Example (labelless with QR_CODE)
A Shipmondo labelless setup can look like:

GLSDK_SR::::::QR_CODE

So instead of :::, Shipmondo may use a different “compound identifier” format (including multiple separators) to express service + functionality such as QR/labelless.

If you’re unsure, verify the exact format in Shipmondo docs / configuration.

4) Webshipper: simple service ID + QR must be enabled

Symptom
You only get a normal label, not QR.

Cause
In Webshipper:

  • The shipping identifier is typically a single service ID

  • QR code must be toggled on in Webshipper (this is Webshipper-side configuration)

Fix

  1. Ensure the Shipping Identifier is the correct Webshipper service ID.

  2. Enable the QR-code option in Webshipper (if supported by that carrier/service).

5) How Claimlane displays the QR/label on the receipt

What the customer sees depends on what the shipping platform returns:

  • If we get the QR code as an image → we can show it directly on the receipt page.

  • If we get the QR as a PDF (or label PDF) → we provide it as a download.

So “QR” doesn’t always mean “no PDF”—some platforms deliver the QR inside a PDF.

Quick checklist (when a customer says “I still get a label”)

  1. Confirm the shipping platform (Homerunner / Shipmondo / Webshipper / ShipStation).

  2. Confirm whether that platform expects a compound identifier.

  3. If compound identifier is required:

    • Use ::: to separate parts when that platform expects it (e.g. Homerunner, ShipStation).

  4. If Webshipper: verify the QR toggle is enabled in Webshipper.

  5. Validate what the platform returns:

    • Image QR vs PDF (download)

Did this answer your question?