Skip to content
Open APIs in the Telecoms IndustryContents

Contents

Close

Potential open APIs for the telecoms sector

Prototyping for the 3 scenarios shown in this report allowed us to understand the APIs that would need to exist if they were to be built.

Potential APIs

Account creation

AutoSwap and Bills Box both require APIs for creating new accounts with a provider.

Before companies take on new customers they typically check their identity and credit rating.

Account closure

Creating a world in which people can easily move between providers also requires API access to close an account.

As well as being convenient, this is an opportunity to improve people’s data protection. Companies are already obliged to delete data when it’s no longer needed, and storing personal information is becoming increasingly risky for companies.

An API for closing an account should:

Creation, updates and deletion of account holders

We found in our research that adding people to bills is time-consuming and awkward, but that not doing so can lead to difficulties.

Bills Box allowed people to easily add new account holders to their household bills: this would require new APIs to implement.

There are some considerations for implementing this API:

Access to service-specific usage data

As people use telecoms companies, they generate a lot of data that’s typically locked inside the company. The company is able to mine that data for its own benefit while the person that generated the data has little access.

AutoSwap demonstrated the power of combining a person’s location history with signal data. However, people should know what information is held about them and this should be made visible through APIs for transparency. For example:

Deletion of usage data

People have the right to delete data held about them (except where it’s legally required to be retained), but the process for exercising this right can be cumbersome.

Bills Box hinted at how API access could make it easier for people to delete information they don’t want to be stored about them.

Machine-readable policies

Company policies like ‘terms and conditions’ are often locked away inside PDFs and are impenetrable to ordinary people.

AutoSwap demonstrated giving people choice about a company based on their privacy policy and social responsibility. This allowed more meaningful scrutiny and comparison, allowing people to choose a company based on their behaviour and not just price. To enable this, policies should be available as data and published through standardised APIs.

Many types of policy could be available through APIs:

When policies are updated they should be version-controlled, with each version being available indefinitely.

Enabling people to subscribe to policy updates through an API could give a better user experience than the familiar "our terms and conditions have been updated" letters in use today.

Access to anonymised bulk data

The air quality prototype demonstrated that bulk data held by companies can provide public benefit, if used carefully.

This data could be made available through APIs with a built-in capability for minimising and anonymising data before handing it over.

By removing personally identifiable information before the data is handed over, risk-averse public bodies would be in a better position to use it without fear of invading people’s privacy.

We imagine bulk data APIs would have similarities to planning applications, with public notices, public scrutiny and the power for citizens being the object.

Opt out of bulk data collection

Bulk data collection should be private by design, but should also allow people a convenient method to opt out. In the prototypes, we imagined building on existing infrastructure like the SMS Cell Broadcast and a shortcode opt-out mechanism.

Further considerations

Making these APIs available isn’t enough on its own. Real consideration needs to be given to designing access control and permissions systems that are both secure and legible to the people using them.

This requires investment in further research to understand what works, especially in areas where there are limited examples of what good design patterns look like, for example for multiple account holders and when there’s shared access to data.