Integrating applications without creating a web of dependencies

As a product portfolio grows, integration can become either a force multiplier or a permanent source of coupling. The difference is whether applications compose through stable capabilities or connect through a growing web of private APIs, shared tables, and copied credentials.

Ireti treats integration as a portfolio of bounded responsibilities rather than one middleware box.

Start with ownership

Every shared fact and operation needs one authoritative writer.

Before connecting two applications, ask:

1. Which product owns the business fact?
2. Which system is allowed to change it?
3. Which consumers need a projection or capability?
4. What scope and permission constrain that access?
5. How is the connection provisioned, revoked, and reconciled?
6. Which system records the authoritative audit?

If two systems can independently mutate the same fact, the integration has already created a conflict-resolution problem.

Middleware is a portfolio

Different integration problems require different boundaries.

Identity integration

Identity federation, login, MFA, recovery, and session protocols belong to the identity authority. Product applications consume stable identity context; they do not exchange administrative identity credentials.

Application provisioning

Provisioning adapters connect a Platform workspace to an exact product resource. They handle idempotency, retries, reconciliation, and opaque resource references without moving product data into the Platform.

Cross-application composition

Composition runtimes coordinate events and capabilities across products. They preserve source ownership and invoke only approved operations. They are not a new system of record.

External ecosystem connectors

External providers have their own credentials, API limits, lifecycle, and failure modes. A connector owns that provider-specific complexity and exposes a bounded platform contract.

Event and reconciliation infrastructure

Events communicate that something happened. Reconciliation confirms whether the intended state still exists after delays, retries, outages, or manual changes. Event delivery alone is not proof that current authorization or product state remains valid.

Connect capabilities, not databases

The default integration contract should be:

consumer
  -> approved capability or event
  -> authoritative provider
  -> scoped result or reference

It should not be:

consumer
  -> provider's private database

Direct database access bypasses domain validation, couples schemas, weakens audit, and makes independent deployment harder. Copying provider records into another product creates a second source of truth unless the copy is explicitly defined as a read-only projection with reconciliation.

Use stable references

Integrations should exchange stable identifiers and bounded metadata:

• organization and workspace IDs;
• application and provider IDs;
• opaque product-resource references;
• capability and operation identifiers;
• event IDs and correlation IDs;
• versioned schemas; and
• secret references rather than secret values.

Display names, URLs, list positions, and mutable aliases are not safe relationship keys.

Composition still requires authorization

An event does not grant the recipient permission to read the source record. A workflow trigger does not grant the target application a seat. A connector installation does not activate every capability.

At execution time, each participant must validate the permissions relevant to its own boundary:

• Ireti Identity validates the principal or workload identity.
• Ireti Platform validates current workspace and application authority.
• The capability provider validates product-domain rules.
• The connector validates provider-specific policy and resource binding.

This creates an intersection of authority rather than a transitive grant.

A conferencing example

Imagine a meeting capability used by several products.

The conferencing provider owns the meeting, recording, and provider lifecycle. A CRM may own the customer relationship. Notes may own preparation and summary documents. A workflow product may own follow-up automation.

A composed flow can:

1. create a meeting through the approved conferencing capability;
2. publish a meeting-created event containing stable references;
3. let authorized products attach their own records;
4. receive completion or recording-ready events;
5. trigger summaries and follow-up workflows; and
6. revoke the connector without corrupting CRM or Notes records.

No product needs the conferencing provider's administrative credentials, and no product needs write access to another product's database.

Billing and seats remain separate

Integration does not erase commercial boundaries. A product may require a subscription, entitlement, seat, usage allowance, provider connection, or some combination. Those facts remain independently managed.

A customer who can launch one application does not automatically inherit every connected product. A background integration does not automatically become a billable human seat. Each product declares and enforces the commercial model appropriate to its role.

Guardrails against integration sprawl

Ireti uses several practical guardrails:

• one authoritative writer per shared fact;
• no peer-product database writes;
• no credentials copied between products;
• stable, versioned contracts;
• explicit tenant and workspace scope;
• idempotent provisioning and mutation;
• current-state authorization at execution;
• durable correlation and audit;
• bounded retries and dead-letter handling; and
• reconciliation for drift and partial failure.

These constraints make product composition additive. A new application can subscribe to approved events or provide a capability without requiring every existing product to change.

The goal is not to remove integration. It is to make integration preserve ownership.