The Integration Broker: Add Once, Available to All

The third time a team builds the same KYC integration, nobody calls it engineering anymore.

Watch the pattern play out in any multi-product enterprise. The first integration with a bureau or a KYC provider is legitimate engineering: study the API, negotiate its quirks, design the error handling, map the response into the application. The second time, for a different product, the team copies the first and adjusts. The third time, for a new market or a new workflow, the exercise is pure re-implementation of the team's own past decisions. And now three copies exist, each embedded in a different codebase, each needing its own patch when the provider revises an endpoint, each drifting slightly from the others until the drift itself becomes a bug source.

Integration effort in that world scales with the number of workflows. It should scale with the number of external systems, and the difference between those two curves is most of an integration budget.

Four Declarative Pieces

On Ontoz, external systems are reached through the Integration Broker, a configured bridge rather than a coded one. An integration decomposes into four constructs, each doing one job.

An External System registers the endpoint: base URL, authentication type, credentials. The connection exists once, as configuration, whatever number of operations eventually use it.

An Integration API defines a single operation on that system: method, path, headers, body template, and the expected response shape. A provider offering eight operations is eight Integration APIs on one External System, each individually testable and individually versioned.

Mapper rules handle the translation. An input mapper transforms application data into the request payload; an output mapper transforms the response back into application data. The transformations live as rules in the logic layer, which keeps a critical boundary clean: application code never contains provider-specific reshaping, and provider quirks never leak past the mapper.

An Integration Task binds the operation into a process: a task of type integration, or asynchronous integration, that references the Integration API and its mappers. This is the only piece a workflow author touches. From the process model's point of view, calling a bureau is just another task.

The Reuse Consequence

The four-piece decomposition is what produces the headline property: add once, available to all. When a new flow needs the KYC check, the workflow author references the existing Integration Task pattern; nothing is rebuilt. When a new market needs the same provider with a local variation, the variation lives in configuration, not in a fork. And when the provider changes its API, the fix is made in one place, to one Integration API and its mappers, and every consuming workflow inherits the correction at once.

Transport is a configuration detail rather than an architecture decision. The broker speaks REST, SOAP, direct database, custom script, and asynchronous queues, with a buffer-and-flush pattern handling event-style integrations through callbacks and correlation. Switching a provider from synchronous to async changes the integration's configuration, not the workflows that call it.

Governed Like Everything Else

Because integration calls run through the broker as platform constructs, they inherit the platform's governance for free. Calls are auditable events like any other action. Mapper rules are versioned, hot-reloadable logic with the same change controls as business rules: compiled, activated per flow, rolled back automatically on failure. An AI agent invoking an integration does so through the same audited, permissioned path a workflow does.

The measure of an integration architecture is what the fourth integration costs. When the answer is "a configuration entry and a mapper," the platform is doing the engineering's job of never solving the same problem twice.