Skip to content

Open Platform

Your landscape stays yours. Omnetic joins it.

Replacing eight systems is the ambition, not the precondition. What belongs outside — an OEM portal, a group data warehouse, a national accounting package — connects through documented APIs and events, and keeps working the day after go-live.

Open Platform · One governed boundary

Best fit
Dealer groups · OEM and brand operations · Teams with systems that must stay
Operational job
Connect the systems that stay outside to one governed record through documented APIs and events, under your permissions and audit trail.
What you get
Data exchanges with external systems, governed by permissions and an audit trail.
Integration architectureIllustrative architecture

Inbound · systems that feed the record

  • OEM & brand systemsOrders, registrations, campaigns, warranty rules
  • Classifieds & marketplacesEnquiries, listing status, price feedback
  • Market & vehicle dataComparable listings, VIN decoding, history sources
  • IdentitySSO for your staff, group directory, role mapping

Omnetic · native

One record · vehicle, customer, work, money

Twenty modules read and write here. Nothing between them is an integration.

  • Commerce & retail
  • Acquisition & pricing
  • Service & operations
  • Intelligence & platform

Event bus · REST · webhooks

Every boundary crossing uses the same interfaces our modules use, no private back door.

Outbound · systems the record feeds

  • Banking, finance & insuranceQuotes, contracts, payouts, portfolio reporting
  • Accounting & statutory exportPostings in the local ledger's format where it stays outside
  • Data warehouse & BIEvent stream or scheduled extract into your own model
  • CommunicationsTelephony, email, messaging, logged back onto the record

Integration architecture, what is native, what is connected. The systems that feed the record, the record with its twenty modules, and the systems the record feeds; every crossing uses the same interfaces the modules use.

Illustrative architecture. Categories, not named partners; endpoint names, payload shapes and rate limits live in the developer documentation issued with your environment.

API & event model

Read what you need, react to what changes

Two mechanisms cover almost every case: a REST interface over the platform objects, and webhooks that fire when something happens. Bulk extracts exist for warehouses that prefer a schedule.

Objects

Read and write

Vehicle, customer, opportunity, work order, invoice, stock movement, the same objects the modules use.

Events

Subscribe

Deal signed, price changed, vehicle received, work order closed, invoice posted. Delivered with retry and replay.

Bulk

Extract

Scheduled exports for BI and statutory archives, in the format the receiving system expects.

Access

Scoped credentials

Every credential carries a role, a site scope and an expiry. Every call is logged against it.

Endpoint names, payload shapes and rate limits live in the developer documentation issued with your environment. This page deliberately publishes no endpoint list until documentation is public.

Integration directory

Categories now, named partners as agreements allow

Nothing here is invented. Where a partner cannot be named yet, the category card says what the connection does and which markets it applies to.

Per brand

OEM order & registration

Order status, registration data and campaign eligibility onto the vehicle record.

Per brand

Warranty & claims

Claims raised from the work order, decisions returned to the same job.

Example below

Classifieds publishing

Publish, sync price and status, capture enquiries back onto the record.

Partner

Finance & leasing quotes

Quote and contract inside the deal instead of a second portal.

Partner

Insurance

Policy attached to the vehicle and the customer, renewal tracked.

Standard

Single sign-on

Your directory, your password policy, roles mapped to Omnetic scopes.

Per market

Local ledger export

Where accounting stays outside, postings leave in its own format.

Standard

Warehouse & BI feed

Event stream or scheduled extract into your own group model.

Partner

Telephony & messaging

Calls and messages logged to the customer with transcripts where allowed.

System relationship

Open Platform in the connected product system

Open Platform

Native
Yours to extend
Connected
Reversible

Security & permissions

An integration is a role, not a hole in the wall

Every connection runs as a scoped identity with the same permission model your people have. Nothing bypasses the audit trail, and no partner sees a rooftop it was not granted.

Security & Trust

Scope

Credentials are issued per integration, per site and per object type, with an expiry date and a named owner on your side.

Audit

Every call and event delivery is logged with the credential, payload reference and result. You can answer who changed a price six months later.

Residency

EU-hosted, with transfers to a partner governed by the same agreement that governs your data.

Failure behaviour

Retries with backoff, replay of missed events, and a visible integration health view, a silent failure is the one thing an integration must not do.

Sandbox & implementation

Build against a copy before you touch production

Every customer environment comes with a sandbox holding realistic but non-personal data, credentials issued with the environment, and event replay so you can test without waiting for a real sale. Your developers, or ours, work there until the integration behaves; promotion to production is a credential change, not a rewrite.

  1. 1

    Scope

    Which objects, which direction, which sites and markets, who owns it on both sides. One page, agreed before anyone writes code.

  2. 2

    Build in sandbox

    Credentials, sample payloads and replayable events. Mapping of your taxonomy happens once and is versioned.

  3. 3

    Verify on ten vehicles

    A short live pilot on a named set of records, checked by the site that will use it every day.

  4. 4

    Operate

    Health view, alerting on failures, and a named contact when the other side changes something.

Missing something?

Missing something you need connected?

Tell us the system and what should flow. You get one of three honest answers: it exists, it is planned, or it needs building and here is what that takes, from an integration architect, not a form autoresponder.

Request an integration

We use the details you provide to handle this request and contact you about it. Privacy policy.

Answered by an integration architect, not a form autoresponder.

Become a partner

If your product serves dealers in our markets, certification gives you a supported place in the directory.

For developers

Documentation and sandbox access are issued with a customer environment; there is no public developer portal yet.

Contact the platform team

Bring your architecture diagram

We will mark what Omnetic replaces, what it connects to, and what genuinely has to stay where it is.

Talk to an integration architect
  1. The systems

    What must remain in the operating landscape.

  2. The objects

    Which records and events need to cross the boundary.

  3. The scope

    Sites, actions and credentials each connection requires.