Define integration metadata once, as code.
Run it as a live integration register.

The integration spec is the deployment manifest.

Developers annotate at source. Integration metadata — source and destination system, protocol, criticality, owner, environment, data model — lives in the OpenShift Deployment as labels and annotations. Versioned, code-reviewed, PR'd alongside the integration code itself. There is no separate document to maintain. The same vocabulary works beyond OpenShift: a Proxmox guest declares the very same metadata in its Notes field and tags, so VM and container estates are discovered the same way.

# part of an OpenShift Deployment manifest
metadata:
  labels:
    ict.example.com/app-type: integration
    ict.example.com/source-system: workday
    ict.example.com/destination-system: personhub
    ict.example.com/environment: production
  annotations:
    ict.example.com/protocol: "REST → AMQP"
    ict.example.com/criticality: high
    ict.example.com/owner: hr-platform
    ict.example.com/data-model: employee.v3

# the same integration on a Proxmox guest — in the Notes field, no prefix
```confida
app-type: integration
source-system: billing-api
destination-system: crm
protocol: "REST → SQL"
criticality: high
environment: production
```

Production is the source of truth.

The collector reads your platforms directly, each one through the same documented collector contract. If something is running, it appears. If it stops running, it ages out. No human intervention required — and no opportunity for documentation to drift away from reality. One register, no matter where a workload lives.

Available now

Red Hat^® OpenShift^®

Kubernetes

VE

On the roadmap

VMware vSphere

Nutanix

oVirt

OpenStack

[ diagram · collector → OpenShift / Proxmox → integrations.json ]

A graph that mirrors what is in production right now.

Filter by environment, criticality and status with AND-logic so the view reflects exactly the slice you need. Click any node for the detail panel — owners, data model, protocol, last-seen timestamp and environment context.

[ screenshot · graph · environment colouring ]

[ screenshot · graph · criticality colouring ]

[ screenshot · detail panel · criticality high ]

[ screenshot · detail panel · system ]

One source. Many targets. Your CMDB reads it directly.

The same register leaves by three routes. Confida Integra pushes it on a schedule — as Markdown, to an Azure DevOps wiki page or into a local docs tree such as MkDocs or a wiki repo — and exposes it as a stable northbound REST API that customer-side systems pull on their own cadence: ServiceNow, Backstage, Grafana annotations, GitOps reconcilers, custom scripts. Confluence export is on the roadmap. Anything needed by hand leaves the dashboard directly: the list as Markdown, CSV or JSON, the graph as PNG, SVG or draw.io.

[ diagram · register → push (ADO wiki, local docs) · pull (/api/v1/) · download (list: MD, CSV, JSON · graph: PNG, SVG, draw.io) ]

Documented, versioned, stable contract.

Confida Integra is the platform layer between your deployments and your existing IT registers. The northbound API is a published contract — your ServiceNow, Backstage or GitOps reconciler reads from it on its own schedule. We do not own your registers; we feed them.

# Read the live integration register from your own systems
curl -H "Authorization: Bearer cnf_v1_..." \
     "https://integra.example.com/api/v1/integrations?env=production&criticality=high"

{
  "data": [
    {
      "id": "a3f1...",
      "source_system": "workday",
      "destination_system": "personhub",
      "protocol": "REST → AMQP",
      "environment": "production",
      "status": "active",
      "extra": { "criticality": "high", "owner": "hr-platform" }
    }
  ],
  "pagination": { "page": 1, "per_page": 100, "total_items": 1, "total_pages": 1 },
  "generated_at": "2026-05-07T10:14:32Z"
}

Your language, without waiting for us.

The interface ships in English and Finnish. Any other language is a JSON file you drop into the configuration volume — it appears in the language menu on the next page load, with no rebuild, no restart and no release from us. Untranslated strings fall back to English, so a partial translation is useful on day one. The in-product documentation works the same way: your own Markdown pages, per language, with the English original served and clearly marked wherever you have not written one.

# Generate a file with every string, translate it, drop it in
python cli/i18n_tool.py template de --label Deutsch
cp de.json /opt/integra/config/i18n/

# What is missing, and what would break the interface
python cli/i18n_tool.py check de
de: 63% (316/502 keys) — placeholder mismatch (1):
    err.auth.rate_limited: expected ['seconds'], found ['sekunden']

Read the contract before you talk to us.

Everything you need to evaluate the integration surface is public, on GitHub, under Apache 2.0 — the OpenAPI 3.1 spec for the northbound API, the JSON Schema for an integration record, the OpenShift label and Proxmox metadata conventions your DevOps teams would annotate with, a Python client SDK and runnable examples. No NDA, no sales call, no private-repo grant. The engine is closed; the contracts are not, and nothing about them needs to be a secret.

The language packs live there too. If you translate the interface into your language, open a pull request — accepted packs ship with the product, credited, to every installation.

Security is documented, not asserted.

Every claim on this page maps to an artefact in the source repository. The gap analysis, the support-period statement, the SBOM and the coordinated-disclosure policy are public — your security architect can read them line by line during procurement. Confida Integra is built for the compliance reality of public-sector and regulated-industry buyers handling personal and confidential data.