SCMS runs entirely on API calls: whatever staff see in the backoffice and in VISION can also be made available programmatically. A municipality can issue access keys for almost every module, so its data flows into third-party systems — and, in the other direction, so SCMS can draw data from systems already in use.
The ERP, the GIS, the open data portal or the application the municipality already uses.
The municipality issues a key for one specific module, with clear limits: what it reads, what it writes, for how long.
The key talks to the same module staff use. One set of data, not a copy.
Data appears where the municipality works, and every action is recorded in SCMS.
An integration is rarely one-way. SCMS is designed to give and to accept data with equal ease.
Whatever a module records can be read by a third-party system with a key: citizen requests in the ERP, documented collections in the finance department, events on the municipal website, indicators in analysis tools. No manual file exports, and no second copy of the same information to keep in step.
SCMS accepts data from systems, databases and sensors already running, and shows it alongside its own: readings from existing installations, requests from the call centre, warnings from national services, registries from other applications. A deployment adds to what the municipality has, instead of demanding that working systems be replaced.
Indicative. The exact data, permissions and frequency are defined per deployment, together with the municipality's technical department.
| Module | Provides | Accepts |
|---|---|---|
| WASTE | Documented collections per bin and vehicle, route history, fill-level indicators. | Fleet, shifts and collection points from the municipality's vehicle management system. |
| MEASURE | Levels and consumption per tank, sudden-change events. | Readings from sensors and systems already present at the installations. |
| GUARDIAN | Status and events per beneficiary, for the social services department. | Beneficiary registry and contact details from social policy systems. |
| ADOPT | Animal registry, adoptions and lost reports. | Records from veterinary and national registries. |
| CLINE | Citizen requests with status, response times and the responsible department. | Requests from the call centre, email or another service platform. |
| PROTECT | Active alerts and zones, for municipal websites and screens. | Warnings from meteorological services and civil protection. |
| PULSE | Poll results in aggregate form. | Questions and audience groups from the municipality's consultation systems. |
| CULTURE | An events calendar in iCal, XML and JSON, for any website or screen. | Events from institutions, theatres and cultural associations. |
| VOLUNPEER | Volunteer registry, participation and hours, for certificates and reporting. | Actions and programmes from partner organisations. |
| Platform · VISION, NOTIFIER, BRAIN | Aggregate indicators and events from across the city. | Data from databases, sensors and external systems, surfaced in VISION. |
An integration should not open more than it needs. SCMS grants access under the same rules that apply to staff.
Each integration gets its own key, for one module and one purpose. It can be revoked without affecting the others.
The key obeys the same role system as staff: it sees and changes only what it is allowed to.
Instead of the third-party system polling, SCMS can notify it the moment something happens, through NOTIFIER.
Every call is recorded: which key, what it asked for, when. Usage is visible in the backoffice.
Where a municipality wants transparency, selected datasets are published publicly, with no key.
An integration does not change who owns the data. The installation remains dedicated to the municipality, under GDPR requirements.
Indicative integration scenarios, based on the modules as they work today. They are not deployments.
Tell us which systems the municipality runs. We can look at which modules integrate, what data is exchanged and how the keys are issued.