Overview#
The Municipal Integration Hub gives a local authority one place to register, configure, test, and operate every external system its services depend on, scoped entirely to that authority's own tenant.
Most councils run a sprawl of separate platforms: a geographic information system here, a finance and payments stack there, a directory service for staff accounts, an open-data portal for citizens, and a public-transit feed for journey planners. Wiring these together one pair at a time produces brittle point-to-point glue that nobody fully understands and that breaks quietly when an endpoint or credential changes. The Hub replaces that sprawl with a single managed connector layer. Each connection is a named connector with its own endpoint, credentials, field-mapping rules, and schedule, and the platform probes each one with the right protocol for that system, writes a structured log of every run, and rolls all of it up into one health view.
The payoff for municipal IT teams and platform integrators is operational clarity. Instead of chasing bespoke scripts, a team registers a connector, confirms connectivity before going live, runs data movement on demand or on a schedule, and reads per-run audit detail and aggregate health from the same managed surface. Because every connector is bound to the authority's tenant, there is no path for one council's data or credentials to reach another.
Key Features#
-
Twenty system categories, one connector model: A single connector definition covers ArcGIS and Mapbox mapping, Microsoft Dynamics and bespoke CRM, Azure Active Directory and LDAP directories, Stripe and bespoke payment gateways, SAP and bespoke ERP, SharePoint document libraries, Exchange and SMTP email, Twilio messaging, CKAN open-data portals, Irish postal and Eircode geocoding, weather services, GTFS transit feeds, and inbound or outbound webhooks. Adding a new system is configuration, not custom code.
-
Protocol-aware connectivity checks: Each connector is probed with logic suited to its system rather than a one-size-fits-all ping. The Hub performs OAuth 2.0 client-credentials token exchange for ArcGIS, bearer-token Microsoft Graph calls for directory and document systems, an EHLO, STARTTLS, and NOOP round-trip for email relays, an Eircode geocode lookup for postal connectors, and standard REST GET or POST exchanges with bearer, API-key, or basic authentication for everything else.
-
Field mapping and transformation rules: Every connector stores mapping rules that translate between a source entity and the council's internal schema, with optional transform rules layered on top, so the data that lands is shaped the way downstream services expect.
-
Scheduled and on-demand runs: Connectors carry a cron-style schedule plus retry settings, and a run can also be started by hand at any moment, giving teams both unattended automation and immediate control when they need to refresh data right now.
-
Structured run logs: Each data movement writes an audit entry recording how many records were processed, created, updated, and failed, along with start time, completion time, duration, and any error detail, producing a defensible record of exactly what moved and when.
-
Aggregate health dashboard: A tenant-wide view counts total, healthy, and errored connectors at a glance, so a team can spot a failing connection before a citizen-facing service notices the gap.
-
Connection testing before go-live: A dedicated test run validates endpoint reachability, authentication, and a sample payload, returning a response time and example data so teams confirm a connector works before depending on it.
-
Built-in protection against internal-target abuse: Every HTTP and email connector refuses to connect to private, loopback, or link-local addresses, closing the door on attempts to point a connector at internal infrastructure or cloud metadata services.
Use Cases#
Local authorities and municipal governments#
A council connects its ArcGIS mapping service, a GTFS public-transit feed, a CKAN open-data portal, its Azure Active Directory staff directory, an SAP finance system, and a Stripe payments portal. Each connection is registered once, tested before going live, and then run on a schedule or on demand. The team reads per-run audit detail and a single aggregate health figure, all bound to its own tenant with no cross-tenant leakage.
Citizen-facing data services#
The GTFS and CKAN connector types unlock public data without custom development. A council exposes real-time transit schedules to a journey-planning service and publishes open budget and spending data straight from its open-data portal, turning standards-based feeds into citizen value with configuration alone.
Platform integrators and shared-service organisations#
An integrator running services for several authorities gives each its own isolated connector registry. Repeatable connector templates replace bespoke per-client glue, and the health dashboard makes the state of every client's connections legible from one place.
Staff directory and document operations#
Directory connectors keep staff records aligned with Azure Active Directory or an LDAP service, while SharePoint connectors pull document-library content for downstream processing, both authenticated through standard token flows.
Integration#
Every capability is reached through one unified GraphQL API. Read-side fields cover fetching a single connector, listing connectors with filters, listing run logs, listing data mappings, and reading the tenant health dashboard. Write-side operations cover creating, updating, and soft-deleting connectors, testing and running them, and creating field-mapping configurations. Because the whole layer sits behind one schema, a customer integrates once and gains every connector type, rather than learning a different API per system.
Authentication into the platform uses OAuth2 with JWT bearer tokens, and every field and operation is permission-gated and tenant-scoped. Outward connections support the authentication style each target expects: bearer and OAuth 2.0 tokens, API-key headers, and HTTP basic credentials, with credentials stored per connector. Inbound and outbound webhook connector types let a council push events into the Hub or have the Hub deliver events outward, complementing the scheduled and on-demand REST and email exchanges. Field-mapping and transform rules give integrators a normalised model so data from disparate systems arrives in a consistent shape, which means less downstream reconciliation and faster delivery of new services.
Open Standards#
- GTFS (General Transit Feed Specification): The transit connector type consumes the MobilityData open GTFS standard, letting a council bring public-transit schedule and route data into its services without bespoke parsing.
- CKAN open data API: The open-data connector type interoperates with the open CKAN Data Management System API, the format used across many government open-data portals for budgets, spending, and public datasets.
- OAuth 2.0 (RFC 6749): Client-credentials and bearer-token flows authenticate ArcGIS token exchange and Microsoft Graph directory and document calls, the standard authorisation framework for system-to-system access.
- LDAPv3 (RFC 4510): The directory connector type interoperates with LDAPv3 directory services, the open protocol for querying enterprise staff and identity directories.
- SMTP (RFC 5321): The email connector type speaks standard SMTP for message relay, performing an EHLO and NOOP round-trip to validate a relay before depending on it.
- STARTTLS (RFC 2487) and SMTPS: Email connectors upgrade plaintext SMTP to an encrypted channel via STARTTLS, or connect over implicit TLS using SMTPS, so credentials and message content are protected in transit.
- Eircode geocoding: The postal connector type resolves Irish Eircode postal codes to geographic coordinates and region detail, grounding address data in the national postal standard.
Security & Compliance#
Strict tenant isolation runs through every operation: connectors, run logs, and field mappings are filtered by the calling organisation, so no council can read or affect another's connections, credentials, or data. Every HTTP and email connector validates its target against blocked private, loopback, and link-local address ranges before connecting, which prevents a connector from being pointed at internal infrastructure or cloud metadata endpoints. All access requires an authenticated, permission-checked session, and every run produces a structured, timestamped audit record of records processed, created, updated, and failed, giving a clear and defensible trail of external data movement.
Last Reviewed: 2026-05-26 Last Updated: 2026-06-02