Engineering
API-first integration for agencies that own a dozen vendor systems
How to connect commercial platforms without building a fragile web of point-to-point links.
A typical city runs a permitting system, a utility billing system, a finance system, an asset management system, a GIS, a records system, and a dispatch system, from as many vendors. Each pair that needs to share data has, over the years, acquired a custom link: a nightly file transfer, a database trigger, a script someone wrote in 2014. Nobody has a complete map.
The problem with point-to-point
Each link is bespoke. When one system is upgraded, every link to it may break. Errors are discovered by the staff who notice missing data. The person who built the link has left.
The alternative
Inventory first. Document every existing interface: source, target, data, frequency, mechanism, owner. This alone is valuable.
Prefer APIs. Modern versions of most platforms expose APIs. Use them instead of database access or file drops wherever possible.
Introduce an integration layer. Whether it is a lightweight integration platform or a small set of well-structured services, route integrations through a layer that handles authentication, transformation, retries, and logging in one place.
Define canonical records. Agree on what a "parcel," an "address," or a "customer" looks like across systems, and transform to and from that shape at the edges.
Monitor everything. Every integration reports success, failure, and volume. Failures alert a human.
Where to start
Pick the integration that causes the most manual work or the most errors today. Rebuild it through the new layer with monitoring. Then the next one. Within a year the map is complete and the fragile links are gone.
A note on vendors
Some platforms make integration hard, by design or by neglect. Contract language that requires documented APIs and reasonable data access is the long-term fix. We help agencies write that language during procurement.