Skip to content

Platform Overview

DIBOP is an integration and orchestration platform designed for automotive enterprises and any organisation that needs to connect multiple business systems, transform data between them, and maintain full visibility over every transaction.

What Problem Does DIBOP Solve?

Modern enterprises run dozens of systems: a DMS (Dealer Management System), OEM portals, CRM platforms, finance providers, telematics systems, parts catalogues, and more. Each system has its own API, its own data format, and its own authentication method.

Without a platform like DIBOP, connecting these systems means:

  • Writing custom point-to-point integrations for every pair of systems
  • Maintaining dozens of bespoke data transformations
  • Having no centralised view of what data moved where, or when something failed
  • Rebuilding integrations every time a vendor changes their API

DIBOP eliminates these problems by providing:

  1. A connector catalogue with pre-built adapters for common systems
  2. A canonical data model that normalises data across all systems
  3. An orchestration engine that chains API calls and transforms into workflows
  4. Full observability over every execution, every API call, and every error

Key Concepts

Connections

A connection is a configured link between DIBOP and one of your external systems. You browse the connector catalogue, select the system you want to connect, provide your credentials, test the connection, and activate it.

Once a connection is active, DIBOP can make API calls to that system on your behalf -- reading data, writing data, or both.

See Available Connectors to browse the catalogue.

Orchestrations

An orchestration is a multi-step workflow. Each step can:

  • Call an API on a connected system
  • Transform or filter data
  • Branch based on conditions
  • Handle errors gracefully

Orchestrations are the core of DIBOP's value: they automate the data flows that would otherwise require manual work or custom code.

See What is an Orchestration? for a detailed explanation.

Canonical Data Model (CDM)

The Canonical Data Model is DIBOP's universal data schema. Instead of mapping every system directly to every other system (an N-to-N problem), each connector maps its data to and from the CDM. This means:

  • Adding a new system only requires mapping it to the CDM once
  • All orchestrations can work with a consistent set of fields
  • PII (personally identifiable information) is classified at the field level

The CDM covers 22 domains, from Vehicle and Customer to Workshop Job and Finance Agreement.

See What is the CDM? for the full explanation.

Monitoring and Observability

DIBOP records every orchestration execution and every API call it makes. You can:

  • View execution logs with full step-by-step traces
  • Monitor SLA compliance (success rates, latency)
  • Set up alert rules to be notified of failures
  • Drill into individual API calls to debug issues

See Observability to explore the monitoring tools.

How DIBOP Works (High Level)

Your Systems          DIBOP                    Your Other Systems
-----------          -----                    ------------------

  OEM Portal  ─────>  Connector  ─────>  Canonical   ─────>  Connector  ─────>  DMS
                                          Data Model
  CRM         ─────>  Connector  ─────>  (Vehicle,   ─────>  Connector  ─────>  Finance
                                          Customer,
  Telematics  ─────>  Connector  ─────>  Order, ...)  ─────>  Connector  ─────>  Reporting
  1. Inbound: Data arrives from a source system via its connector
  2. Transform: DIBOP maps the data to the Canonical Data Model
  3. Orchestrate: Your workflow applies business logic, enrichment, or routing
  4. Outbound: Data is mapped from the CDM to the target system's format and delivered

Every step is logged, timed, and available for review in the monitoring dashboard.

Multi-Tenant Architecture

DIBOP is a multi-tenant platform. Each enterprise operates in complete isolation:

  • Your data is never visible to other enterprises
  • Your credentials are encrypted and stored in a dedicated key vault
  • Your orchestrations run in your own execution context
  • Your users only see resources belonging to your enterprise

This means your platform administrator can configure the platform for multiple enterprises, and each enterprise sees only its own data.

Enterprise Isolation

Even platform administrators cannot view the credentials stored for a specific enterprise. Credentials are encrypted at rest and only decrypted at the moment an API call is made.

Who Uses DIBOP?

DIBOP serves two primary audiences:

Role What They Do
Enterprise Admin (Tenant Admin) Configures connections, builds orchestrations, manages users, monitors operations. This documentation is primarily written for this role.
Platform Admin Manages the connector catalogue, configures quotas, monitors cross-tenant health. See Platform vs Tenant Admin.

Next Steps