Pickup Point API Coverage: 8 Networks Measured

Why a locker-count table even needs to exist

Every checkout with a pickup-point API selector in Europe now has to answer the same question: which network, which protocol, which limits. Marketing pages all say "nationwide coverage" or "Europe's largest network." None of them say what their finder API actually returns per call, or whether it's REST or a SOAP envelope from 2012. We pulled the public numbers that exist, as of October 2026, and listed what's missing. If you're scoping a pickup point API or parcel locker API integration this quarter, this is the table to paste into your ticket before anyone estimates a sprint.

Method: what we counted and what we didn't

We collected published point/locker counts, country scope, API protocol, developer-portal existence, and any stated search-radius or result-count cap, directly from vendor docs, changelogs, and (where no primary source existed) third-party network audits. Everything below is dated October 2026. This is not a test-harness benchmark: we did not hit these endpoints with our own sandbox credentials this round, so latency, auth-flow friction, and SLA figures are out of scope here. Where no public figure exists, the cell reads "Not published" rather than an estimate.

The table

What the protocol split actually costs you

Mondial Relay still runs a genuine dual stack. Point search lives on the old SOAP interface, where this method permits to search the 30 nearest Points Relais® from a given location (from a GPS address or by both Zip code/Country), while shipment creation and labels have moved to a separate REST layer (Connect v2). If your team hasn't touched a WSDL since university, budget extra days for this one alone.

GLS is the odd case: the REST and legacy SOAP builds of ShipIT don't agree on their own result caps. The REST findNearestParcelShopForAddress method states plainly that the service is limited to the next 15 parcelshops within 50km of airline distance from the given address. An older SOAP build of the same method, however, documents a looser ceiling: the service is limited to the next 100 parcelshops within 50 km in straight-line distance (parameter "AirlineDistance") from the given address. Same carrier, same method name, different cap depending on which version you're pointed at. Pin your version string before you write a single test case.

DHL's Location Finder is the one genuinely pan-European finder endpoint among the direct carrier APIs we looked at, with DHL stating direct addressing to over 140,000+ access points with the Unified Location Finder. The radius logic has shifted over time too: a 2022 changelog entry notes DHL changed default and maximum radius to 5000m (5km) and 1 000 000m (1000km) respectively, but a separate support article clarifies that in practice you're capped at max 50 locations per request regardless of how wide you set the radius. Everyone else in this table — InPost, DPD, GLS, Bring, Mondial Relay — still operates country-by-country, even where the brand is pan-European.

Direct API vs. aggregator: the trade you're actually making

Aggregators exist precisely because no single carrier finder covers the continent. ParcelSelector advertises 390,000+ pickup points • 23 countries • 8 carriers, and notably isn't a queryable API at all — it states outright that Parcel Selector works 24/7/365 so you can display a map for any country without an API, which is a different integration shape entirely (embed a map widget vs. call an endpoint). PPMatcher takes the API route and claims wider reach: full access to the PPMatcher API — all pickup-point lists across 36+ countries, real-time sync, COD filters, and the checkout widget. Treat both figures as vendor-reported, not independently audited — nobody has cross-checked these counts against carrier-side data. The trade-off engineers actually face isn't really "coverage." It's that label creation and tracking almost always still need the native carrier API no matter which locator powered your checkout search. An aggregator can smooth over search, but you'll still be writing a DHL, GLS, or InPost label integration downstream. That's the exact fragmentation gap that multi-carrier platforms and TMS-side connectivity layers like Cargoson, alongside Sendcloud and nShift, are built to abstract — not just the locker search, but the whole label/track/customs stack sitting behind six different carrier dialects.

Known gaps, stated plainly

• GLS does not publish a total parcelshop count anywhere in the docs we reviewed — not per-country, not Europe-wide.
• Mondial Relay's current web service documentation gives no country list or network size; older point-count figures circulating online predate the InPost tie-up and shouldn't be trusted as current.
• DPD/Geopost's own developer docs don't surface a single Europe-wide point count; the 142,020 figure we cite comes from a third-party last-mile audit, not DPD itself.
• Bring's Pickup Point API docs don't state a search radius or result-count cap for the geolocation endpoint — only that results are sorted by driving time where available.
• Quadient/Parcel Pending didn't surface a public, documented finder-API endpoint with a stated point count or protocol in this round of research — flagging it as an open gap rather than guessing.

If you have direct account access showing current figures that contradict anything above, especially GLS shop counts or Mondial Relay's post-merger network size, we'd genuinely like the correction — that's the whole point of publishing sourced numbers instead of marketing copy.

Checklist before you scope the sprint

• Confirm protocol version string first. A "REST API" label can still hide a SOAP-only search method, as with Mondial Relay.
• Confirm the result cap against your densest urban postcode, not your test address. A 15-result cap within 50km reads fine in a rural test but breaks in central Warsaw or Berlin.
• Confirm whether a coverage number is carrier-reported or aggregator-reported before it goes in a vendor comparison deck internally.
• If you need pan-European search from one direct carrier API without an aggregator, DHL's Unified Location Finder is currently the only one in this table built that way natively.