Last updated: June 2026.
Most carrier guides treat GLS as a single thing you "connect." That framing is exactly what catches PrestaShop merchants out. GLS is not one carrier with one API, it's a federation of national subsidiaries (GLS Germany, GLS Italy, GLS France, GLS Poland, GLS Spain and the rest) that share a brand, a parcel-tracking backbone and a label standard, but each runs its own web service, its own credentials and its own quirks. The moment you ship from more than one country, that detail stops being trivia and starts deciding how you model carriers, zones and credentials inside PrestaShop. This guide is about that specific problem: getting GLS working across countries in a PrestaShop store without ending up with a tangle of half-configured carriers that quote the wrong price at checkout.
If you only ship domestically from one warehouse, much of the multi-origin complexity below won't apply to you. The single-country setup is genuinely straightforward, and the general mechanics of adding any carrier module are covered in setting up carrier modules in PrestaShop. Come back here when you add a second shipping origin.
Why "multi-country GLS" is a different problem from "add a carrier"
In PrestaShop, a carrier is one row in the Carrier table. A delivery option a customer can pick, with its own zones, weight/price ranges and tax rule. A GLS integration module, whatever its origin, ultimately has to map GLS's services onto these carrier rows and generate a label against the right national API when you process an order.
With a single origin that mapping is one-to-one. With multiple origins it isn't, because two things diverge per country:
- The API you authenticate against. GLS Germany historically exposes its shipping service as ShipIT (a REST/SOAP web service); other subsidiaries use their own endpoints and credential schemes. So "your GLS API key" is really one set of credentials per country you ship from, a customer ID, contact/consignor ID and endpoint URL that only work for that subsidiary.
- The services on offer. ParcelShop delivery, FlexDelivery redirection, express tiers and the available add-ons aren't identical across subsidiaries. A service you sell as a carrier in one origin country may not exist in another.
What doesn't diverge, and this is the part that makes GLS workable, is the customer-facing side. The label format and the tracking infrastructure are standardised across the group, so a parcel shipped from your German origin and one from your Italian origin both track through the same GLS tracking backbone and look the same to the buyer. Your job is to hide the back-end fragmentation, not the front end.
The credential map: write it down before you touch PrestaShop
Before configuring anything, get a flat list of what each shipping origin needs. You'll request these from GLS in each country you ship from, GLS typically gates API access behind a business account and a minimum monthly volume commitment, and issues separate test-environment credentials you should insist on:
| Per origin country you need… | Why it matters in PrestaShop |
|---|---|
| API username / password | Authenticates label calls; stored in the module config, scoped per origin in multistore |
| Customer ID + contact/consignor ID | Identifies who's shipping; wrong ID = labels generate against the wrong account or fail |
| Country API endpoint URL | Routes the call to the correct subsidiary (e.g. the ShipIT endpoint for DE) |
| Test endpoint + credentials | Lets you generate throwaway labels before going live, never debug against production |
| The exact service codes you're entitled to | Determines which carrier rows you can actually fulfil (ParcelShop, Express, etc.) |
So what? If you skip this and just "install the module," you discover the gaps at the worst possible moment, when a real order won't print a label because the Italian origin was configured with the German contact ID. Ten minutes with a table up front saves a fulfilment fire-drill later.
Modelling GLS carriers and zones the right way
This is the part you build in Shipping → Carriers. That's where services, weight/price ranges and zone assignments live, and where most multi-country setups quietly go wrong. (Shipping → Preferences is a separate screen for global handling charges and free-shipping thresholds, not for modelling the GLS services themselves.) The mechanics of carriers, zones and ranges are the same for every carrier, if they're new to you, the complete PrestaShop shipping configuration guide is the reference; below is only what's GLS- and multi-country-specific.
One carrier per service, not per country
It's tempting to create "GLS Germany," "GLS Italy," "GLS Spain" as separate carriers. Resist it. The customer doesn't care which of your warehouses ships their parcel. They care whether it goes to their door or a ParcelShop, and how fast. Model carriers around the service the customer chooses:
- GLS Standard, door-to-door
- GLS ParcelShop. Delivery to a pickup point (this one needs the map-based finder; see below)
- GLS Express, only in zones where your relevant subsidiary actually offers it
The "which API generates the label" decision is the module's job at fulfilment time, driven by the order's shipping origin. It should not be something the customer sees or picks. Keeping the origin logic out of the carrier list is what stops your checkout from showing four near-identical GLS options.
Zones grouped by transit reality, not by continent
The classic mistake is a single "Europe" zone with one flat rate. GLS transit times and your own costs vary enormously across Europe, so a flat rate either overcharges nearby customers (lost conversions) or undercharges distant ones (eroded margin). Group countries into zones that reflect GLS's actual service bands from your origin, typically DACH, Benelux, Southern Europe, Eastern Europe, Nordics, and attach weight/price ranges per zone.
The deeper "what should I actually charge, real cost, flat, or free" question is its own decision and we won't rehash it here: see free vs flat rate vs calculated shipping, and if you're a smaller store weighing cost against speed, shipping strategy for small stores.
Multistore and multi-origin: where the credentials live
If you run a PrestaShop multistore with a different shipping origin per store, the split is clean: carrier definitions can be shared across stores (same services, same customer-facing options), but API credentials and the origin address must be set per store. Configure the carrier shape once at the global level, then scope each origin's GLS account at the individual store context. If you instead ship from multiple warehouses within a single store, that's a sourcing question covered in multi-warehouse management in PrestaShop, the GLS credential per origin still applies, the module just needs to pick the right one based on which warehouse fulfils the order.
The ParcelShop finder: the one feature worth being fussy about
GLS's competitive edge over door-only carriers is its ParcelShop network, and offering pickup-point delivery genuinely reduces failed deliveries. A redelivery attempt is pure cost to you. But it only works if the customer can choose a specific ParcelShop at checkout, and that selection has to be persisted on the order, in whatever way the module supports, so it gets passed to the label API and your label generates against the right point.
A weak integration shows ParcelShop as a flat dropdown or, worse, lets the customer pick "ParcelShop" with no actual point attached. A proper one:
- Renders a map widget (the GLS ParcelShop finder API takes a postal code or GPS coordinates and returns nearby points)
- Lets the customer search by postcode or use their location, and shows opening hours per point
- Persists the chosen ParcelShop on the order in the way the module supports, structured carrier/order metadata that's passed to the label API, not just a note in a comment field
If a module offers GLS but only as a plain carrier with no map-based point selection, you don't really have ParcelShop delivery. You have a carrier name. For a network whose whole value is the pickup points, that's the feature to verify before anything else.
Tracking and notifications across subsidiaries
Because the tracking backbone is unified, this is the easy win of multi-country GLS. Once a label is generated, the module should write the tracking number back onto the PrestaShop order automatically (into the order's shipping/tracking field), and your Shipped order-status email should carry the GLS tracking link so customers self-serve instead of emailing you. The same tracking URL pattern works regardless of which subsidiary produced the label, one notification template covers every origin.
Tracking-and-notification practice deserves more than a paragraph, and it's not GLS-specific, so for the full treatment, what to send, when, and how it cuts "where's my order?" tickets, see tracking numbers and delivery notifications. The same goes for setting honest arrival promises on your product and checkout pages: estimated delivery dates: setting realistic expectations.
Returns: keep it simple, link out for strategy
GLS supports both proactive returns (a pre-printed label in the outbound parcel) and on-demand returns (you generate a label when the customer requests one). How the on-demand path is wired depends on the module: some hook into PrestaShop's native Customer Service → Merchandise Returns flow, while others handle returns entirely in their own back-office screens. Either way, a well-built module can call the relevant national GLS API and email the return label when you approve the return. Note the per-country credential rule applies here too, a return for a parcel shipped from your Italian origin must be generated against the Italian subsidiary.
Whether proactive or on-demand is right for you is a margin-and-return-rate decision rather than a GLS one, so we won't prescribe it here.
Common multi-country pitfalls
- One contact ID used everywhere. The single most common failure: configuring the right endpoint but the wrong (German) contact ID for a non-German origin. Labels either fail or post against the wrong account. Verify every origin against its own test credentials before going live.
- Missing product weights and dimensions. GLS enforces weight limits that vary by country and service. International parcels are commonly capped at 31.5 kg, ParcelShop drop-off lower still (often around 20 kg), with some domestic services allowing more, plus size constraints. If your catalogue products have no weight set, the module either falls back to a default that triggers reweigh surcharges, or the API rejects the label. Fill in weights in Catalog → Products → Shipping before you scale volume.
- Address formatting strictness. GLS APIs are fussier than some carriers about street-number placement and postal-code formats per country. A module that validates the address before the API call saves you from cryptic fulfilment-time errors.
- Selling a service an origin can't fulfil. If "GLS Express" appears as a carrier in a zone served by a subsidiary that doesn't offer it from your origin, customers buy a service you can't deliver. Tie each service-carrier to the zones your relevant subsidiary actually covers.
Where mypresta.rocks fits
We build PrestaShop modules with the same obsession we'd want for our own stores, clean integration with the carrier and order flow, and no theme surgery to maintain. Carrier-API work like GLS is most valuable when the rest of your delivery experience isn't leaking customers: a confusing pile of shipping options at checkout undoes a good carrier setup. If the delivery-selection step in your checkout is where customers stall, our checkout-optimization modules tackle that part directly, fewer, clearer options and a total that's honest from the first screen. Which is a different problem from the carrier integration itself, and a worthwhile one to fix alongside it.
The short version
GLS rewards European stores that get the multi-country plumbing right, and punishes the ones that treat it as a single carrier. Hold three things in your head: credentials and endpoints are per origin country, so map them before you configure anything; model carriers around the service the customer chooses, not the warehouse that ships it, and let the module pick the API at fulfilment time; and be uncompromising about a real map-based ParcelShop finder, because that network is the whole reason to choose GLS. Get those right and the standardised label and tracking layer makes the rest feel like one carrier. Which, to your customer, it should.
If you also ship with the bigger door carriers, the parallel setup for those is in DHL, DPD and UPS for PrestaShop, and for relay-point-first markets see Mondial Relay relay-point delivery and InPost Paczkomaty for Poland.
Frequently asked questions
Is GLS one carrier or several?
For configuration purposes, several. GLS is a federation of national subsidiaries, GLS Germany, Italy, France, Poland, Spain and the rest, that share a brand, a label standard and one tracking backbone, but each runs its own web service, credentials and quirks. That's why "your GLS API key" is really one set of credentials per country you ship from: a customer ID, contact/consignor ID and endpoint URL that only work for that subsidiary. The customer-facing side (labels, tracking) is standardised across the group, so your job is to hide the back-end fragmentation, not the front end.
Should I create a separate carrier per country in PrestaShop?
No, model carriers around the service the customer chooses, not the warehouse that ships it. Create GLS Standard (door-to-door), GLS ParcelShop (pickup point) and GLS Express (only in zones your subsidiary actually offers it), and let the module decide which national API generates the label at fulfilment time based on the order's origin. Creating "GLS Germany / GLS Italy / GLS Spain" as separate carriers just shows the customer four near-identical options they don't care about and clutters your checkout.
Why won't my label print for an order from a second country?
The most common cause is one contact ID used everywhere, configuring the correct endpoint but the wrong (usually German) customer/contact ID for a non-German origin. The label either fails or posts against the wrong account. Each origin needs its own credentials: API username/password, customer ID, contact/consignor ID and the country endpoint URL. Verify every origin against its own test credentials before going live, and in a multistore set credentials and the origin address per store while sharing the carrier definitions.
What weight limits does GLS enforce?
They vary by country and service, plus size constraints. International parcels are commonly capped around 31.5 kg, ParcelShop drop-off is usually lower (often around 20 kg), and some domestic services allow more. If your products have no weight set, the module either falls back to a default that triggers reweigh surcharges or the API rejects the label outright. Fill in weights (and dimensions) under Catalog → Products → Shipping before you scale volume. GLS APIs are also fussier than some carriers about street-number and postal-code formatting, so a module that validates the address before the call saves you cryptic fulfilment-time errors.
What makes a real ParcelShop integration versus a fake one?
A real one renders a map widget (the GLS ParcelShop finder API takes a postal code or GPS coordinates and returns nearby points), lets the customer search by postcode or location with opening hours shown, and persists the chosen point on the order as structured carrier/order metadata that's passed to the label API, not a note in a comment field. A weak integration offers "ParcelShop" as a flat dropdown, or worse, lets the customer pick it with no actual point attached. For a network whose whole value is the pickup points, that's the feature to verify before anything else.
Do I need a different tracking template per GLS country?
No. That's the easy win. Because the tracking backbone is unified across the group, the same tracking URL pattern works regardless of which subsidiary produced the label, so one Shipped-status notification template covers every origin. Once a label is generated, the module should write the tracking number back onto the PrestaShop order automatically, and your shipped-status email should carry the GLS tracking link so customers self-serve instead of emailing "where's my order?"