British cities should buy APIs alongside roads and buildings

British cities should buy usable digital interfaces alongside new infrastructure whenever sharing its data would improve a defined public service. Construction, transport and utility suppliers should prepare to price and maintain that capability. Japan’s smart-city architecture already treats standardised APIs as part of shared urban infrastructure. The opportunity for British companies is to make assets easier to operate and integrate, with responsibilities that survive the original installation.

Key pointers

• Ask which operational decision an asset’s data will improve before commissioning an interface.
• Include documentation, maintenance and handover in the supplier’s scope.
• Require a demonstration that another supplier can use the data.
• Separate access to asset information from permission to control equipment.
• Give smaller suppliers a bounded component to deliver, with clear acceptance criteria.
• Price the continuing service and eventual exit alongside installation.

Japan is making the connection part of the design

The significant development in Japan is the attention given to how different urban systems exchange information. The Cabinet Office describes its reference architecture as shared guidance intended to make services work across cities and allow successful approaches to be reused elsewhere. Its national programme also supports local smart-city services and data platforms. Japan’s smart-city programme

An application programming interface, or API, gives software a defined way to request or exchange information. Japan’s geospatial supplement makes that idea concrete. It describes a platform that brings together information from public bodies, businesses, researchers and citizens, then makes it reusable through maps and machine-readable interfaces. Geospatial platform purpose and architecture

For British suppliers, the commercial implication is worth preparing for. A future infrastructure specification could ask for the physical asset, the information describing it and a maintained way of retrieving that information. This is a procurement argument drawn from Japan’s approach, not evidence of an established British requirement.

Consider a hypothetical UK street-lighting replacement. The council could require an asset identifier, location, maintenance history and a documented fault feed. A separate maintenance application could then consume that information without the lighting contractor also having to supply every downstream application.

The tender would need to say who corrects inaccurate records, who supports the feed and what happens when the maintenance contractor changes. Without those commitments, “API included” would be an incomplete deliverable.

British suppliers should prepare for smaller and clearer contracts

My position is that councils should make useful data access part of relevant infrastructure specifications. They should also define it tightly enough that a specialist business can compete for a manageable piece of work.

That could mean a civil engineering contractor partnering with an integration specialist, or a local software company maintaining an interface for several asset owners. Neither arrangement should require the smaller business to assume responsibility for an entire city platform.

The existing technology market provides context, although it does not measure demand for city APIs. For financial year 2024/25, techUK’s Local Digital Index reports SME shares of local-government IT spending of 24.8% in the East of England, 14.8% in the North West and 19.7% in the South East. The figures use Tussell data and cover direct procurement rather than indirect supply-chain spending; spending is mapped using buyer postcodes, which can over-represent some authorities. Regional procurement data and methodology

Those differences do not show that interface requirements would increase SME participation. They do make participation a sensible outcome to measure. A council should ask whether its specification lets a specialist demonstrate a working component, or requires a breadth of delivery that only a large consortium could reasonably offer.

For a small supplier, the useful preparation is a demonstrable service package. Show the data format, a working consumer, support arrangements and a handover procedure. A promise to participate in a future smart-city ecosystem is harder for a buyer to assess.

Separate the data from the applications

Japan’s geospatial supplement offers a practical starting point. Its data layer holds source information; its linkage layer collects, converts and distributes that information; its application layer turns it into services. The same document distinguishes relatively static geographic information from dynamic context such as sensor readings and events. Layers and complementary technologies

For the hypothetical lighting project, I would translate that into separate responsibilities.

The asset owner would approve identifiers and information-sharing rules. The contractor would maintain the agreed records and fault information. An integration operator would run the interface, while application providers would use it to support maintenance work.

Acceptance should include a deliberately ordinary test. Give a developer who did not build the interface its documentation and authorised access, then ask them to retrieve an asset’s location and latest reported condition. Record where they need undocumented assistance.

Keep equipment control outside that initial test. Reading a fault record and issuing a command to street equipment should have separately defined permissions and operational responsibilities. A useful information service does not require unrestricted remote control.

Price the years after installation

The supplied evidence establishes architectural choices, but provides no comparable UK quotations for delivering them. A defensible cost model therefore starts with work packages rather than an invented price per connected asset.

| Cost component | What a buyer should request |

| --- | --- |

| Data preparation | Scope for identifying assets, correcting locations and reconciling existing records |

| Interface development | Supported data formats, documentation, examples and acceptance tests |

| Hosting and connectivity | Charging units, expected traffic and responsibility for connection failures |

| Ongoing operation | Monitoring, incident response, security updates and data-quality ownership |

| Changes | Prices and notice periods for new fields, integrations and incompatible updates |

| Exit | Export formats, documentation handover, transition assistance and termination charges |

Ask bidders to separate installation costs from recurring charges and state VAT treatment, exclusions and their assumed service period. Compare offers over the same period, including council staff time, training and eventual transition.

Japan’s recommendation of static hosting for map tiles is relevant here because it identifies a simpler delivery option for suitable data. It does not establish the full cost of an operational city service. Map distribution guidance

A maintained file export may be sufficient where information changes infrequently. Buyers should require a more elaborate interface only when the use case justifies its continuing cost.

Compare components and delivery responsibilities

The evidence supports a comparison of architectural components, rather than a current commercial supplier ranking. Japan’s supplement identifies several open-source options with different jobs. They should be assessed for their role in the service, not treated as interchangeable city platforms. Listed systems and libraries

| Option identified in the supplement | Stated role | Buyer question |

| --- | --- | --- |

| CKAN | A data catalogue in the source-data layer | Who maintains the records and checks their accuracy? |

| FIWARE Orion or Orion-LD | Management of dynamic context information | Does the service need changing sensor or event information? |

| MapLibre GL JS | Rendering vector tiles as visual maps | Who supplies the underlying data and maintains the application? |

| deck.gl | Three-dimensional data visualisation | Does a three-dimensional view help users make a better decision? |

British buyers could seek delivery from an asset supplier, an independent integrator or a managed-service provider. My recommendation is to compare their responsibilities explicitly.

An asset supplier should demonstrate that another application can consume its information. An independent integrator should explain how it will handle upstream changes. A managed-service provider should identify its dependencies, escalation responsibilities and exit support. An internally operated open-source system needs named staff and a maintenance budget.

The procurement decision concerns who can sustain the required service. The software name answers only part of that question.

The strongest objection is another expensive system to maintain

The strongest objection is practical. A council could commission interfaces, dashboards and data stores that consume money without improving maintenance, transport or residents’ access to services. Each connection would then become another obligation for an already busy operational team.

Japan’s own guidance supports taking that concern seriously. Its April 2021 Smart City Guidebook says regions can start with what they can achieve rather than attempting every part of the ideal process. Guidebook introduction The University of Tokyo’s governance recommendations similarly put human benefit ahead of collecting data to justify a technology. Service-first governance

The answer is a purchasing boundary. Require an interface when there is a named consumer, a defined operational decision and an owner who will fund its upkeep. Start with a limited asset group and measure whether the information improves the intended task.

For the lighting example, that might mean checking whether maintenance staff can locate faults and prepare visits more reliably. If they cannot, the project should correct the data or reconsider the design before expanding.

Residents should also be able to understand what information is being collected and why. A maintenance use case should not become a pretext for adding unrelated personal-data collection.

Editorial analysis

British infrastructure suppliers should treat documented data access as a capability to develop now. The most credible offer will combine domain knowledge with a modest, supportable interface and a clear account of who maintains it.

Buyers have an equally important job. They should test whether the interface remains usable after the original supplier leaves. If that cannot be demonstrated, the procurement has not yet secured the independence it was meant to provide.

The next useful step is to take an upcoming asset renewal and identify one operational task that another team or supplier needs to perform. Specify the information that task requires, then test the handover before accepting the wider installation.

FAQ

Are British councils already required to buy APIs with infrastructure?

The evidence supplied does not establish a general British requirement. This article argues for including maintained interfaces in relevant procurements where a defined service benefits from shared information.

Does a machine-readable city need a complete digital twin?

A limited information service can be specified without commissioning a complete city model. Japan’s geospatial supplement describes maps, data interfaces and applications as separable components, while its wider Society 5.0 policy sets out a broader digital-twin vision. Geospatial architecture Society 5.0 vision

Can a small British supplier compete for this work?

A sensible entry point would be a bounded service such as preparing asset records, implementing an interface or maintaining a specific integration. Buyers would need to make those responsibilities separately assessable; the evidence does not establish that such contracts are currently available.

What should a buyer require before accepting an interface?

Require documentation, an agreed data format and a successful test by a separate application or developer. Also agree ownership of inaccurate data, support, changes and exit assistance. Japan’s supplement explicitly calls for documentation, sample code and usage guidance, providing a useful starting point for that specification. API documentation requirements

Sources

• Cabinet Office, Japan — Smart-city programme and reference architecture register, including the fifth-edition update dated 11 March 2026.
• Cabinet Office, Japan — Society 5.0, policy overview.
• Cabinet Office, Japan — Geospatial Data Interoperability Platform, second edition, dated 23 May 2025.
• Japanese government and Smart City Public-Private Partnership Platform Secretariat — Smart City Guidebook, April 2021, version 1.01.
• University of Tokyo, Institute for Future Initiatives — Smart City Data Governance Guidelines, policy recommendation published March 2023.
• techUK — Local Digital Index procurement data, financial year 2024/25, using Tussell datasets downloaded in August 2025.