Govlink™ for IT Teams: a platform that integrates, not another system to maintain

A REST API documented with OpenAPI, signed webhooks, identity over OAuth 2.0 / OpenID Connect and a sandbox to test before touching production. All in the cloud, with no new servers for the department to run.

A city’s IT department is the internal vendor for twenty departments that ask for more than a small team can deliver, on top of systems that do not talk to each other and that nobody wants to touch. Govlink™ is built for that team: everything is exposed through an API, it integrates with what already exists, and it runs without infrastructure of your own.

Govlink™, Wai™’s digital government platform, seen from the IT department

What a city IT department deals with every day

If you work in IT for a local government, nobody needs to explain this to you. We list it because it is exactly the problem Govlink™ has to solve for you, or it is not worth your time.

  1. More requests than hands

    Every department wants its own system, its own report and its own form, due yesterday. The backlog grows and the team spends the day putting out fires instead of building.

  2. One system per department, none of them talk

    Tax, records, traffic, health: each with its own database, its own users and its own vendor. Joining data across two is a project; across three, a fantasy.

  3. No API, no documentation, no way out

    Legacy systems expose nothing. To get a piece of data out you have to request a change from the vendor, pay for it and wait. The city does not own its own information.

  4. Servers nobody wants to touch

    Systems running on a physical box in the building, with manual backups and an operating system out of support. Every power outage is a risk.

What is under the hood of Govlink™

What a technical team looks at before saying yes. The full reference lives at govlink.wai.global/desarrolladores.

REST API under /api/v1, with OpenAPI

Procedures, records, service requests, appointments, users and zones are read and written through the API with a key and per-module scopes. The interactive reference (Swagger) is generated from the code on every start: it cannot go stale.

Signed webhooks

Every status change on a procedure, a service request, an appointment or an asset file fires a signed call to your system. No polling, no reading the database.

Govlink ID: OAuth 2.0 / OpenID Connect

A single identity provider for residents and staff. Your applications use it like any other standard IdP; the city stops maintaining a user table per system.

Sandbox with sample data

A test environment with the same routes, the same errors and the same webhooks as production. The integration is built and tested there, with its own key, before requesting the real one.

Public data dictionary

Every entity, field, relationship and encoding of what the API returns and what gets exported, documented and available without a key. The data model is not a vendor secret.

Cloud, multi-agency, no servers of your own

Govlink™ runs as a service. The department does not install, upgrade or back up: it operates. The standards it is built on —ISO/IEC 27001, ISO/IEC 27017, OAuth 2.1, WCAG 2.2 AA, X-Road— are listed on the Govlink™ page.

How it integrates with what you already have

Nobody replaces a whole city at once. Govlink™ comes in module by module and coexists with the systems that stay, integrated or not.

  1. Survey of systems and data

    Which system owns which data, which ones have an API and which do not. That produces the integration map, which belongs to the city and not to the vendor.

  2. Integration through the API, or a bot when there is no API

    Systems with integration capabilities connect through the API or webhooks. For those that expose nothing, Govlink™ can run a bot that accesses them as a person would and extracts the data, so no system is left out for being old.

  3. Unified identity with Govlink ID

    The city’s own applications adopt Govlink ID as their OAuth 2.0 / OpenID Connect provider. One login for staff, one identity for residents.

  4. One module in production, then the next

    Each department comes on board when it is ready, with its data migrated and its people trained. What already works is left alone until something better is running.

What changes for the IT team

  • Department requests are solved by configuring modules, not by building from scratch.
  • The city’s data is queried through a documented API, without asking anyone for anything.
  • Zero new servers: infrastructure, backups and upgrades belong to the service.
  • Security built on reference standards, not on whatever could be done in the time available.
  • A trail of every action, every signature and every movement, to audit without reconstructing anything.
  • The team goes back to designing the city’s architecture instead of holding it together by hand.

Request a technical demo

  • We walk through the API and webhooks with your team, with the OpenAPI reference open.
  • We look at how it integrates with the systems the city runs today, with or without an API.
  • We set up Govlink ID as the identity provider for one of your applications.
  • You get sandbox access to try it on your own.

Govlink™ is not a promise of being "integrable": it is a documented API, a sandbox and a public data model. It can be verified before anything is signed.

Request a technical demo and bring the team: the meeting runs on systems questions, not slides.

Govlink™ administration panel