We use some essential cookies to make this website work.
We’d like to set additional cookies to understand how you use GOV.UK, remember your settings and improve government services.
You can change your cookie settings at any time.
Hackney Council built an API platform for developers to use to create APIs.
Hackney Council built an API platform for developers to use to create APIs. The platform includes a set of API service standards and template code.
Hackney Council wanted to build a public API platform using modern software development processes. This platform would be for developers and contain all the Hackney Council APIs, supported by a robust set of API standards. Widespread use of this platform would result in reduced development costs, better return on investment, and would enable services to develop a loosely coupled microservices architecture. That is, changes to one service would not affect other services.
Hackney Council provides services such as council tax and rent payment, repair reporting and bulk waste collection to residents of the London Borough of Hackney. The Corporate Information and Communications Technology (ICT) team works with the service users and residents to identify their user needs and build effective solutions to those needs.
Although Hackney Council’s Corporate ICT team had full management support for this project, they recognised that they did not yet have the skills and knowledge to start building the platform. To start with, they spoke to HMRC about how to successfully implement a large-scale API platform in government. HMRC shared their knowledge on:
The council team also collaborated with various digital agency partners to research those partners’ API-first strategies and standards. From this, the council team realised that they needed to understand how to build APIs from both a user needs and data needs perspective. The team also researched the technology code of practice to learn about applicable best practice. Once this research was complete, the team was ready to start choosing technology before building the platform.
From the start, Hackney Council’s Corporate ICT team took an iterative approach to choosing the technology to build the API platform depending on the user and data needs. They looked at each solution’s benefits and drawbacks and changed their approach as necessary.
For example, after evaluating both Google Cloud and AWS cloud platforms, the team chose AWS. Hackney Council felt AWS suited their needs more, as it is very developer-friendly due to the variety of services provided. Additionally, the pre-existing relationship with HMRC helped, as the HMRC delivery manager was able to set up meetings between the council team and AWS to answer questions. For example, the council team spoke with the AWS Solution Architecture team to make sure the council team were following the 5 pillars of the AWS Well-Architected Framework.
The team also made technology choices based upon their existing skills. The team of developers already had knowledge of .NET Core programming language skills, so they decided to build the platform using that language.
At the same time, the team learned from their digital agency partners about:
The team was then ready to start building the platform.
Hackney Council’s corporate ICT team started building the API platform. This work included the public API platform and an API implementation guide with a set of API service standards. There were several challenges. The platform had to support:
Additionally, the Corporate ICT team needed to:
The team used an AWS PostgreSQL database architecture to make the APIs highly available, scalable, secure, and loosely coupled. To increase security, the team used token authentication through Google Groups instead of API keys. Additionally, the team built a developer hub to collect all the APIs together to make onboarding of external developers easier.
The API playbook that the team delivered was central to overcoming the challenge of educating users. This playbook:
This playbook was a valuable resource for getting developer buy-in to the API-first strategy as a platform. Developers could see the playbook was a single source of all the information needed to develop and maintain platform APIs. This buy-in was important to embedding the API-first strategy in the service development process.
Throughout the build process, the team led architecture and data meetups, where they asked external digital agencies and internal developers for feedback. This open and collaborative process made sure the:
The team also used these meetups to emphasise to stakeholders that reusing APIs would save on development costs and provide a return of investment on the API platform.
Hackney Council’s API platform went live in January 2019. The council team won an iNetwork award for API services, and the team were finalists at the AWS awards for City on Cloud. This platform brought both tangible and intangible benefits.
By working in the open and collaborating with multiple digital agencies, the team embedded an API-first strategy within service development, which saved time and money in the development process.
Since the platform went live, developers have been able to create APIs much more quickly and consistently by:
Additionally, the wider developer community (including both Hackney Council and external developers) now recognises the value of working in the open, of collaboration, and of having defined API standards.
The developer community also has regular data and architecture meetups to build the community of practice for robust and secure platforms. Hackney Council iterates their API playbook once a year, and they released a new version in May 2021. In future, the API playbook will have a distribution list to alert users when the team publishes a new playbook.
Don’t include personal or financial information like your National Insurance number or credit card details.
To help us improve GOV.UK, we’d like to know more about your visit today. We’ll send you a link to a feedback form. It will take only 2 minutes to fill in. Don’t worry we won’t send you spam or share your email address with anyone.
Open Government Licence
All content is available under the Open Government Licence v3.0, except where otherwise stated
We use some essential cookies to make this website work.