Hobfolk
Logistics · case study

The first live label,
forty-five minutes, owner watching.

The first real label purchase on a new shipping platform found four things no documentation mentioned — live, in one session, with the person paying for it watching the screen. All four are now automated away.

Start a conversationSee the whole crew
You go home. It doesn't.Every promise gets a row and a due dateAnswered the same day, not the next working dayA drawing before the quoteUnverifiable is never a passNine desks, one address eachNothing is sent that a human cannot read backThe folder exists before you price itYou go home. It doesn't.Every promise gets a row and a due dateAnswered the same day, not the next working dayA drawing before the quoteUnverifiable is never a passNine desks, one address eachNothing is sent that a human cannot read backThe folder exists before you price it
The story

Four undocumented traps in one shipping platform, found live

The screen looking like it worked and a label actually existing are two different claims. Only one of them can be trusted.

Buying the first real label on a shipping platform new to the business turned up four things its documentation never mentioned. There is no label-purchase endpoint on the public interface at all — only the on-screen flow can actually buy one. A new shipment silently defaults to the cheapest, slowest courier available rather than the one that had actually been quoted, unless something explicitly overrides it. A confirmation control that looks identical to every other button on the page does not respond the same way to an automated click as it does to a real one. And the only reliable proof a label was actually bought is a specific state appearing on the record afterwards — not the screen appearing to have succeeded.

None of those four are rare edge cases. They are the kind of thing that only surfaces the first time a real payment goes through a real interface, which is exactly why they were found live rather than caught in advance — and exactly why the fix was to automate the workaround immediately, rather than treat the first parcel as a one-off manual exception.

A courier default that never announces itself
A courier default that never announces itself

Sourced from Hobfolk's own operational record, dated and on file — see the other four. Client identity is never named; the numbers and the root cause are not softened.

What changed

The permanent fix, not just the patch

01

The courier default is checked, not trusted

Every new shipment's assigned courier is checked against what was actually quoted before a label is bought — the platform's own silent default is never allowed to stand.
02

Success is verified at the record, not the screen

The only accepted proof a label exists is the specific state the platform itself records afterwards — a screen that looks finished is not evidence.
03

The one control that behaves differently is worked around

A UI quirk specific to this platform's confirmation step is handled permanently in the automation, not re-discovered on the next shipment.
04

Every dispatch runs through the same script

No shipment is booked by hand through a process that was already automated once — consistency comes from using the one path, every time.
05

The lesson is written down before the next integration

So the next new courier platform starts from what was already learned here, not from zero.
06

The whole first session was timed and logged

Forty-five minutes, start to a verified label, with every trap named — the log this case study is drawn from.
How it unfolded

The sequence, in order

  1. The first real shipment needs a label

    A new shipping platform, no prior live purchase on the account.

  2. The API has no purchase endpoint

    Only the on-screen flow can actually buy a label — the first trap, found by trying the obvious route first.

  3. The courier silently defaults

    The cheapest, slowest option is pre-selected rather than the one actually quoted.

  4. A confirmation click doesn't behave as expected

    The control that looks like every other button does not respond identically to an automated click.

  5. The screen looks done — it isn't proof

    The only real confirmation is a specific state on the record afterwards, checked separately.

  6. All four are automated the same day

    One command now runs the whole sequence, correctly, from courier check through to verified proof of purchase.

Said plainly

What this desk still won't do

A case study is not a claim of no limits. The same boundary applies here as on the department page this one came from.

Where this desk stops

  • It does not release goods that have not been paid for. Where that is your rule, it is enforced without exception and only you can waive it.
  • It does not accept a liability on your behalf — carrier terms, insured values and special conditions come back to you.
  • It is not a customs broker of record where your trade requires one; it prepares and instructs.
Questions

Asked before, answered here

Why not just use the platform's own interface every time?
Because the interface itself defaults quietly to the wrong courier and gives no reliable signal of success — using it by hand every time just means re-discovering the same four traps on every shipment instead of once.
How do you know a label was actually bought, not just that the screen said so?
By checking the specific state the platform's own record shows afterwards, separately from whatever the screen displayed during the purchase — the same “acceptance is not delivery” discipline this desk runs everywhere else.
Does this only apply to this one shipping platform?
The specific traps are platform-specific. The pattern — new API integrations hiding silent defaults and unreliable success signals until the first real transaction goes through — is not, and is checked for on every new courier integration since.
What happens if a courier's interface changes and breaks the automation?
It gets caught by the same verification step that checks the record after every purchase — a change that breaks the flow shows up as a failed verification, not a silently wrong label.

How do you actually know your last label purchase went through?

Tell us which platform you're on, and we'll tell you plainly what it isn't telling you.

Start a conversation Read the method