Automated Shipping Labels via Poste Delivery Business

An e-commerce operation was generating shipping labels the manual way: an operator re-typing every order into Poste Delivery Business's own web portal, one shipment at a time. I was brought in to replace that with a single button in the existing admin panel — click, and the label and tracking code are ready.

Poste Delivery Business's own API doesn't make that a single call. Creating a shipment requires an authentication step and a separate shipment-creation step, both rate-limited, with a token that expires and a label link that goes stale in hours. My job was to build the internal service that absorbs all of that complexity and gives the rest of the system one clean contract.

Three constraints shaped the design from day one:

• A two-step, token-based handshake with a shared rate limit of 100 calls/minute across the whole business — re-authenticating per shipment wastes that budget for nothing.
• A label URL with a ~12-hour expiring token and no "re-download" endpoint: call the API twice for the same order and you don't get the label again, you create a second real, billable shipment.
• Real order data, not a demo payload — recipient details, computed package weight from what was actually purchased, and international shipments that don't map cleanly onto a single "shipping product."

A Python/FastAPI microservice with one external contract: send order details, get back a barcode and a label link. Internally it handles:

• Token caching with a safety margin, so the credential is reused across requests instead of re-fetched on every shipment.
• Retry logic for the one carrier error code that behaves as a transient fault rather than a real rejection, with capped exponential backoff.
• Error classification that turns the carrier's own "200 OK with an error object inside" contract into HTTP statuses a caller can actually branch on — a bad postcode and a carrier outage are not the same failure.
• A separate order-mapping layer that turns a live order into a compliant shipment request: computed weight/dimensions, and country handling that goes beyond plain ISO codes — carriers commonly use their own proprietary country identifiers, with outlying territories requiring their own resolution logic.

Every call to this service creates a real, billable shipment — there's no dry-run mode on the carrier side. An unauthorized or accidental call isn't a logged error, it's money spent. That made access control a design constraint from the start, not an afterthought bolted on before go-live.

Two separate questions had to be answered, and conflating them was the risk to avoid:

• Who is allowed to trigger a shipment? That's an authorization decision, and it already had a correct owner: the existing admin panel's permission system, which every other feature in that panel already relies on. Rebuilding that logic here would have meant a second, divergent source of truth for the same permission.
• Is this request really coming from the admin backend, and not from anything else that can reach this service? That's authentication between two systems, a different problem entirely.

The admin backend's session cookie was the obvious shortcut — until I checked it and found it opaque, with no readable role or permission claims. Reading a role out of it would have meant reaching into the admin backend's session storage directly, coupling two systems that have no other reason to share state.

Instead: the admin backend verifies the calling user's permission itself, exactly as it does for every other action in the panel, and only then calls this service with a shared secret in a request header. This service checks that one secret with a constant-time comparison and nothing else — it has no concept of users, roles, or permissions, by design. Authorization stays where it already lived; authentication between the two services is a single, narrow check that doesn't need to know why the call is allowed, only that it's genuinely coming from the system that already decided it is.

Before trusting the integration, I tested it against 74 real historical orders — one per distinct destination country. The first pass: 53 passed, 21 failed. Triaging the failures surfaced three unrelated issues: sandbox-only flakiness, a sandbox coverage gap (orders that worked fine in production), and a genuine bug — an undocumented limit on how many customs line items an international shipment can declare, found by bisecting a failing order's item list rather than guessing at the payload. After fixing the real bug and excluding two destinations the carrier itself confirmed aren't served by that shipment type, the batch passed at 72/74 (97%). Full technical writeup: Wrapping a Legacy Shipping Carrier API in One Endpoint.

A one-click shipping flow replacing a fully manual process, verified end-to-end in production for both domestic and international shipments, with the operational handoff (deployment constraints, secret management, environment switching) documented for the team taking the service forward.