Travel & Hospitality
Accessibility Information API
A wheelchair user booking a hotel is not looking for an accessibility icon. They are looking for a door width, and almost nobody publishes one.
- OTAs and booking platforms
- Hotel groups
- Destination marketing organisations
- Transport operators
- Public sector tourism bodies
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
The current state of accessibility information in travel is worse than absent, because absent would at least be honest. A booking site shows a wheelchair symbol that the property self-selected during onboarding, with no definition of what it means and no check that it is true. The traveller books on that basis, arrives, and finds a step at the entrance, a bathroom that cannot be entered in a chair, or a lift too small to turn in.
That failure is not a poor user experience. It is a stranded person in an unfamiliar city, at their own expense, sometimes unable to use the room they have paid for. Disabled travellers consequently do not trust accessibility filters, and plan instead by phoning properties directly and asking specific questions — which is slow, repetitive and frequently answered wrongly by whoever picks up the phone.
This means the build is not a coverage problem, it is a verification problem. A database with accessibility claims for fifty thousand properties, sourced from self-declaration, is worse than one with verified measurements for two thousand, because the first invites reliance it cannot support. The useful product records what is known, how it was established, when, and by whom — and says nothing where nothing has been verified.
Who buys this
OTAs and booking platforms, Hotel groups, Destination marketing organisations, Transport operators, Public sector tourism bodies
What the API returns
What comes back
- Structured accessibility attributes with measurements rather than icons
- Verification method, date and source recorded on every individual claim
- Confidence banding per attribute, from measured on site to self-declared
- Explicit unknowns — absence of a claim is returned as unknown, never as absent or compliant
- Route-level accessibility between points, including kerbs, gradients and step-free transfers
- Attribute history so a regression after refurbishment is visible
- Dispute and correction records, including unresolved reports from travellers
- Jurisdiction-specific standard mappings where a legal standard applies
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/places/{id}/accessibility | Accessibility attributes with verification detail |
| POST | /v1/search | Find places meeting specified accessibility requirements |
| POST | /v1/routes/accessibility | Step-free routing and barriers between two points |
| POST | /v1/reports | Submit a traveller correction or dispute for a claim |
| GET | /v1/places/{id}/history | Change history for accessibility attributes |
| GET | /v1/standards/{jurisdiction} | Local standard definitions and attribute mappings |
Request and response
illustrativeRequest
{
"requirements": {
"entrance": "step_free",
"doorway_min_mm": 800,
"bathroom": "roll_in_shower",
"lift_min_internal_mm": [1100, 1400]
},
"area": { "city": "Vienna", "radius_km": 4 },
"min_verification": "operator_documented",
"include_unknowns": false
}Response
{
"query_area": "Vienna",
"min_verification": "operator_documented",
"results": [
{
"place_id": "plc_8841",
"name": "Example City Hotel",
"attributes": {
"entrance": { "value": "step_free", "verification": "site_audit",
"verified_on": "2026-05-14", "by": "accredited_auditor" },
"doorway_width_mm": { "value": 860, "verification": "site_audit",
"verified_on": "2026-05-14" },
"bathroom": { "value": "roll_in_shower", "verification": "operator_documented",
"verified_on": "2026-02-02", "evidence": "floor_plan_and_photos" },
"lift_internal_mm": { "value": [1100, 1400], "verification": "site_audit",
"verified_on": "2026-05-14" },
"hearing_loop_reception": { "value": "unknown", "verification": "none" }
},
"confidence": "high",
"open_disputes": 0
}
],
"excluded": [
{ "place_id": "plc_8902", "reason": "self_declared_only",
"note": "Claims step-free entrance; no supporting evidence on file" }
],
"coverage": { "places_in_area": 412, "with_verified_attributes": 58 }
}Where the data comes from
| Operator-supplied documentation | Floor plans, measurements and photographs from the property, which is evidence rather than a tick box |
| Accredited accessibility audits | On-site surveys by qualified auditors — the strongest source, and the one that costs money and time |
| Disability organisation datasets | Audits and registers compiled by national and local disability organisations, used under agreement |
| Public sector accessibility registers | Municipal and transport authority data, which is often open and reasonably reliable for public infrastructure |
| Open mapping data for routing | Kerb, crossing, surface and gradient attributes from open map data, with completeness varying sharply by city |
| Traveller reports | Structured corrections from users, treated as dispute signals that trigger re-verification rather than as facts in themselves |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Every attribute stored with its own provenance record — method, date, source and evidence — rather than one trust level per property
- A verification hierarchy with explicit tiers, so a caller can require site-audited data and exclude self-declaration entirely
- Unknown treated as a first-class value, because returning absent for unverified is the error that strands people
- Measurements in units, not categories: an 800mm doorway is a number, and wheelchair accessible is not
- Attribute expiry, since a refurbishment can remove step-free access and nobody updates the listing
- Dispute workflow where a traveller report downgrades confidence immediately and queues re-verification, rather than waiting for consensus
- Route accessibility computed from segment attributes with explicit gaps, never interpolated across unmapped stretches
- Validation sampling: a share of operator-documented claims re-audited on site to measure how often self-reporting is wrong, reported openly
What it changes for the business
Trust in the filter
An accessibility filter that only returns verified matches is one disabled travellers can actually use.
Fewer stranded guests
Measured attributes instead of icons removes the failure mode that produces complaints, refunds and real harm.
Compliance evidence
Documented provenance supports accessibility obligations that a self-declared tick box does not.
Defensible coverage growth
Verification tiers let coverage expand without quietly diluting the quality of what is already there.
How it fits into your product
How it embeds
- Search endpoints that filter on required verification level, not just on attributes
- Attribute detail components that surface method and date alongside every claim, so the UI cannot hide provenance
- Operator portal endpoints for submitting documentation and keeping attributes current
- Traveller correction submission from your app, routed into the dispute workflow
- Webhooks on confidence downgrades for places in a user's existing booking
- Localisation of attribute labels and standard terminology per jurisdiction
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Why is coverage so much lower than other travel datasets?
Because verified accessibility data cannot be acquired the way other travel data is. There is no feed to licence. Reliable attributes come from floor plans, measurements and on-site audits, and each of those takes effort per property. We would rather ship fifty properties in a city with audited measurements than five hundred with self-declared icons. The second product does more harm than no product at all.
Can you not just use the accessibility flags properties already provide?
We can ingest them, and we will label them as self-declared and nothing more. Validation sampling consistently finds self-declaration wrong often enough that it cannot be the basis of a booking decision — usually because the person filling the form interpreted wheelchair accessible generously, or because something changed after a refurbishment. The API can return them, but only at the lowest verification tier and only if the caller asks for that tier.
What does the API return when nothing has been verified?
Unknown. Not false, not absent, not compliant. This is the single most important design decision in the build, and it is why the search endpoint defaults to excluding unverified places rather than including them. A traveller who sees unknown will ring the property; a traveller who sees a green tick will book and arrive.
How do you handle a traveller reporting that a claim is wrong?
The report immediately downgrades the confidence on that attribute and queues re-verification, rather than waiting for a second report to agree. The asymmetry is deliberate: a false claim of accessibility causes real harm, and a temporarily cautious listing causes inconvenience. We would also surface open disputes in the response rather than hiding them until resolved.
Is route accessibility reliable?
It is reliable where the underlying map data has kerb, surface and gradient attributes, which in practice means parts of some cities. Elsewhere the API returns the mapped segments and explicit gaps rather than a route that looks complete. Presenting an interpolated step-free route through unmapped streets would be exactly the failure this build exists to avoid.
Related blueprints
Travel Itinerary Generation API
Generates day-by-day itineraries from traveller preferences, with sequenced routing and real opening hours, for booking and planning products.
Destination Intelligence API
Seasonality, traveller-interest signals, event calendars and comparable destination scores, as a data layer for travel products and marketing teams.
Hotel Price Intelligence API
Comparative hotel rates, availability movement and rate-change alerts, delivered as a data layer inside your booking or revenue product.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.