Every flight, hotel, train, or event booking has a parking question attached to it. And the parking question almost always gets answered after the booking — at the barrier, usually under pressure, often at a premium. By the time the question is being asked, the OTA-side opportunity to make the booking better, longer, and more profitable has already passed.
We built ParkAttach because that’s the wrong order. Parking should be a checkout SKU, not a footnote.
The shape of the problem
From an OTA’s perspective: parking is the single most-requested ancillary that nobody sells well. Cars on a trip is a near-universal pattern — even rail and air travellers drive to the station or the airport — and yet the parking inventory at the other end is fragmented across hundreds of independent operators, each with their own platform, contract terms, and integration appetite. Most OTAs solve it by linking out to a third-party parking aggregator, which means the booking decision happens off-platform and the OTA loses the upsell, the data, and the customer relationship for that part of the journey.
From a parking operator’s perspective: OTAs are exactly where their customers decide they need parking. But onboarding into each OTA’s tech stack is a years-long bilateral negotiation that few operators have the bandwidth to pursue. The operators who do tend to be the giants, which entrenches the asymmetry. A regional operator with twenty excellent car parks near hotel clusters is invisible to the OTAs that drive demand to those hotels.
The mismatch is structural, not technical. Both sides want the integration; the cost of every bilateral one is what kills it.
What ParkAttach actually is
A single API, sat in the middle. One bearer-token integration on the OTA side. One connector on the operator side. The platform mediates the bilateral commercial agreement — commission split, pricing rules per channel, cancel windows — and exposes a quote → reserve → commit flow that mirrors the patterns OTAs already use for flights and hotels.
We don’t process payments. The OTA’s checkout already does that, and adding a second payment surface would mean two PCI scopes, two reconciliation flows, and two places for things to go wrong. ParkAttach’s contract is inventory, not money. Settlement between OTA and operator happens on whatever terms the bilateral agreement specifies, on the rails both parties already use.
We don’t pick winners on either side. The agreement framework is generic: any OTA can have an agreement with any operator, on any channel, with any commission shape. We expect each major OTA to run multiple channels — Expedia US, Expedia UK, and Expedia DE are three channels with three different commission structures and tariff overrides — because that’s what the commercial reality already looks like.
What it isn’t (yet)
We’re not a marketplace that mints its own pricing. Tariffs are operator-authored, either through admin in the platform or through a real-time quote request to the operator’s own platform when the connector supports it. The platform’s job is to apply commission to the operator’s price, not to invent the price.
We’re not a directory. Surfacing a car park in an API response doesn’t mean APCOA endorses it commercially — it means there’s an active agreement under which the calling OTA is allowed to sell it. Permission is the agreement, full stop. No separate visibility ACL, no curated “preferred” list, no shadow-banning of operators who haven’t paid enough. The data model is the deal.
We’re not done. The platform is in technical preview with select partners while we shake out the connector contract, the agreement-editing UX, and the cancellation semantics. The architecture is sized for Booking.com- and Expedia-scale traffic from day one because we’d rather start with the assumption that it works at scale than retrofit it later — but the partner roster is deliberately small until we know the contract is right.
The assumptions that shape every decision
A few load-bearing assumptions are worth stating explicitly, because they show up everywhere in the code:
The hot path is read-heavy and bursty. A Booking.com integration doesn’t drip-feed 833 quotes per second uniformly across the day; it pulses, hard, when search traffic spikes. The cache layout is sized for those peaks (50,000 quote requests per minute is the planning headroom), and the agreement filter runs against an in-memory permission tree per process so it doesn’t hit Postgres on every quote.
Analytics is downstream, not synchronous. Every quote, reserve, commit, and cancel emits a Kafka event that downstream consumers — urgency aggregators, look-to-book ratio trackers, coverage analytics — read independently. The OTA’s quote response never waits on any of that. Producer failures don’t fail quotes; consumer outages don’t slow them down.
Operators have asymmetric platform capabilities. Some operator platforms can take live quote traffic at OTA-hot-path rates; many can’t. The connector contract recognises three capability tiers — admin-authored tariffs, cached tariff queries, and live real-time quotes — so an operator can start at the tier their platform actually supports and migrate later. We’d rather an operator be on the platform at the lowest tier than not on the platform at all.
Cancellation is not the inverse of commit. A cancelled booking is a real event; a timed-out reservation is a non-event. The urgency service treats sold-and-then-cancelled as still having happened, because the original sold state happened and a shopper who saw it can’t un-see it. That kind of asymmetric reasoning shows up all over the platform and is mostly invisible until you try to design a layer that ignores it.
Where this goes
The shortest path from here is more partners — both OTAs (initially the big global brands that already have a parking-shaped gap in their checkout) and operators (initially the ones whose car parks are already adjacent to APCOA’s, where the supply gap is most visible). The architecture is well past needing scale before the partner roster catches up; the constraint is contractual and human, not technical.
If you’re an OTA or a parking operator and any of the above resonates, come and talk to us. The platform is in technical preview; the partner conversations are wide open.