API Integration with Existing Council Systems

Local authorities typically operate dozens of different software systems: council tax, housing benefits, planning, building control, environmental health, and more. PRS enforcement data sits across many of these systems, yet most were never designed to talk to each other. The result is manual data re-entry, information silos, and missed enforcement opportunities. API (Application Programming Interface) integration solves this by allowing systems to exchange data automatically. When a tenant submits a complaint, the enforcement system can instantly pull the property's council tax status, EPC rating, licensing history, and landlord details from other systems. When the PRS Database launches in late 2026, API integration will be the primary way councils access national registration data. This guide explains what API integration involves, what councils need to prepare, and how to approach integration projects practically.

An API is a structured way for one software system to request data from, or send data to, another. In the council context, common API patterns include: REST APIs: The most common pattern. Systems communicate using standard HTTP requests (GET to retrieve data, POST to send data). Data is typically exchanged in JSON format. The EPC register API, Land Registry APIs, and most modern council systems use REST APIs. SOAP APIs: An older pattern still found in some legacy council systems, particularly those built on Microsoft platforms. SOAP uses XML format and is more complex but still functional. File-based exchange: Not technically an API, but many council systems support scheduled CSV or XML file exports and imports. This is a pragmatic starting point where true API integration is not yet possible. For PRS enforcement, the most important integrations are: - Council tax system to enforcement platform (property and occupant data) - EPC register to enforcement platform (energy rating data) - Licensing management to enforcement platform (licence status) - PRS Database to enforcement platform (registration and compliance data) - GIS system to enforcement platform (mapping and spatial analysis)

The PRS Database API specification has not been finalised, but based on DLUHC consultations and the data fields specified in the Renters' Rights Act 2025, councils should prepare for: 1. Authentication: The API will likely use OAuth 2.0 or API keys with role-based access control. Councils will need to register as authorised users and manage credentials securely. 2. Data formats: Expect JSON over REST. The data schema will include landlord details, property details, compliance status, and enforcement history. 3. Query patterns: Councils will likely be able to query by local authority area, UPRN, landlord reference, or compliance status. Bulk data feeds for the whole local authority area may also be available. 4. Update frequency: The API may provide real-time queries or periodic data snapshots. Councils should design their systems to handle either approach. 5. Data storage: Councils will need to store and process PRS Database data locally, subject to GDPR and data retention policies. The most practical preparation step is ensuring your enforcement platform has API integration capability. If your current system cannot consume external APIs, this is a procurement priority.

API integration in a council environment faces several common challenges: Legacy systems: Many council systems were built before APIs were standard. Where true API integration is not possible, middleware solutions (integration platforms like MuleSoft, Dell Boomi, or open-source alternatives like Apache Camel) can bridge the gap. Data quality: APIs exchange structured data, but if the underlying data is inconsistent (e.g., different address formats in different systems), matching fails. Standardising on UPRNs as the primary property reference across all systems is the single most impactful data quality improvement. Security and governance: APIs that exchange personal data must be secured. This means HTTPS encryption, authentication, rate limiting, logging, and compliance with the council's information security policies. The Data Protection Officer should review all API integrations that involve personal data. Budget and skills: API integration requires technical skills that many council IT teams lack. Options include training existing staff, recruiting developers, or procuring integration as a service from vendors. Organisational resistance: System owners may resist integration efforts due to data governance concerns, resource constraints, or institutional inertia. Senior management sponsorship and a clear business case (more effective enforcement, potential civil penalty income) are essential.

For councils starting their API integration journey, a phased approach is recommended: Phase 1 (now): Data audit. Map all systems that hold PRS-relevant data. Identify which have APIs, which can export files, and which are completely siloed. Standardise property references to UPRNs wherever possible. Phase 2 (Q2-Q3 2026): Quick wins. Integrate the EPC register API and Land Registry APIs with your enforcement platform. These are free, well-documented, and provide immediate enforcement value. Phase 3 (Q3-Q4 2026): Internal integration. Establish data feeds between council tax, licensing, and enforcement systems. If APIs are not available, start with scheduled file exports and imports. Phase 4 (Q4 2026 onwards): PRS Database integration. When the API specification is published, implement the connection. Having already completed Phases 1-3, the council will have the infrastructure and skills to integrate quickly. The £18.2 million enforcement fund can support all phases of this roadmap. Councils should frame API integration as enforcement capacity building, not IT infrastructure, to align with funding criteria.