Skip to main content
FromNine
Menu

Engineering

Integrations that keep data moving, and show when it stops.

We connect CRM, ERP, case systems and government platforms through contracts, events and identity done properly, so data moves reliably, errors are visible and new capabilities, AI included, can plug in safely.

For organisations connecting systems, partners and public platforms in more than one Member State.

Discuss your projectSee the platforms we connect
Integrations & APIs: capability stackFour layers stacked in depth. From top to bottom: the consumers such as portals, apps and agents, the API gateway with identity, the event backbone, and the systems of record underneath.01Portals, apps and agents02API gateway and identity03Event backbone04Systems of record
  1. 01Contract-first APIs with OpenAPI and AsyncAPI, versioned and documented
  2. 02Events with ordering, idempotency, dead-letter handling and replay
  3. 03Flows monitored end to end, error queues owned by named teams

01 Problems

Integration problems we are called in for

  1. 01

    Point-to-point links nobody dares change

    Dozens of direct connections between CRM, ERP and custom systems. Changing one field means testing ten interfaces.

  2. 02

    Duplicates and silent failures

    A retry creates a second order. A failed message disappears. Business users find out from customers.

  3. 03

    Every new channel means new integration work

    The portal, the mobile app and now an AI assistant all need the same data, and each gets its own extract.

  4. 04

    Government exchanges are a project of their own

    Connecting to a national data-exchange platform or eID scheme takes months of security and onboarding work each time.

02 Delivery ledger

What we deliver

  1. 01 API strategy and management

    API-first design with OpenAPI and AsyncAPI contracts, a versioning policy, a gateway that enforces it and a developer portal so teams find and reuse what exists.

    What we do

    • API landscape and ownership map
    • Design guidelines and review process
    • Gateway policies for security, quotas and versioning
    • Developer portal and API catalogue

    What you receive

    • API guidelines adopted by your teams
    • Gateway configuration as code
    • Catalogue of documented APIs

  2. 02 Event-driven integration

    Brokers, change data capture and the outbox pattern, with the details that decide whether it works: ordering, idempotent consumers, dead-letter handling and replay.

    What we do

    • Event model and naming conventions
    • Outbox and CDC on source systems
    • Consumer idempotency and ordering guarantees
    • Dead-letter queues with replay tooling

    What you receive

    • Event backbone in production
    • Schema registry and compatibility rules
    • Replay and recovery runbook

  3. 03 Integration platforms, chosen per flow

    SAP Integration Suite, MuleSoft and cloud-native integration services each have their place. We tell you when an iPaaS beats custom code, and when it does not.

    What we do

    • Assessment of existing middleware
    • Platform choice with total cost of ownership
    • Reusable mappings and connectors
    • Migration from legacy middleware

    What you receive

    • Integration platform decision record
    • Integration patterns library
    • Migration plan for existing interfaces

  4. 04 Identity and trust between systems

    OAuth 2.0 and OpenID Connect, mutual TLS, service-to-service identity, and integration with citizen and business eID: itsme, DigiD and eHerkenning, BundID, FranceConnect, Cl@ve, SPID and CIE.

    What we do

    • Identity architecture for users and services
    • Token design, scopes and consent
    • eID onboarding and certification support
    • Preparation for EU Digital Identity Wallets

    What you receive

    • Identity design and threat model
    • eID integration in production
    • Service identity and secret rotation in place

  5. 05 Government interoperability

    Connections to national data-exchange platforms, such as the Federal Service Bus and MAGDA in Belgium, Digikoppeling and Common Ground in the Netherlands, XÖV standards and FIT-Connect in Germany, PDND in Italy and API Entreprise in France, and to the EU Once-Only Technical System.

    What we do

    • Onboarding with the platform operator
    • Mapping to national data standards
    • Security and logging requirements of each exchange
    • Once-only evidence exchange design

    What you receive

    • Certified connection to the exchange
    • Mapping documentation
    • Operational procedures with the operator

  6. 06 Operational visibility for business users

    Flow monitoring that business users can read, reconciliation between systems, and error queues that someone owns and works through.

    What we do

    • Business-level flow monitoring
    • Reconciliation reports between systems
    • Error classification and routing
    • Alerting per flow owner

    What you receive

    • Integration dashboard per business process
    • Reconciliation checks in production
    • Ownership map for every error queue

03 Architecture

An illustrative reference architecture

Two paths leave the systems of record. Synchronous requests go through system APIs and a gateway that checks identity, scopes and quotas. Changes are published as events through an outbox or change data capture, and consumers process them idempotently.

Failed messages land in a dead-letter queue with replay, not in a log file. A monitoring band shows every flow in business terms, so the people who own a process can see when it stops.

Layers in the drawing

Systems of record
ERP, CRM and case management keep authority over their data.
Synchronous APIs
Versioned system APIs behind a gateway with OAuth 2.0, mTLS and quotas.
Events
Outbox, broker, dead-letter queue and integration platform mappings.
Consumers
Portals, apps, agents, partners and government exchanges, with eID where citizens are involved.
Illustrative example

  1. Systems of record

    • ERP, CRM and case systems

  2. Synchronous APIs

    • System APIs
    • API gateway: OAuth 2.0, mTLS, quotas

  3. Events

    • Outbox and CDC
    • Event broker
    • Dead-letter and replay
    • Integration platform mappings

  4. Consumers

    • Portals, apps and agents
    • Partner and government exchanges
    • Identity: OIDC, mTLS, eID

  5. Operate

    • Flow monitoring, reconciliation, owned error queues
APIs and an event backbone, side by side

Illustrative architecture, not a client system.

Read the diagram as text

The main route runs from systems of record through versioned system APIs and an API gateway to portals, apps and agents.

In parallel, systems of record publish changes through an outbox and change data capture to an event broker, which delivers them to partner and government exchanges and to an integration platform for mappings. Failed messages go to a dead-letter queue with replay. Identity services with OAuth, mTLS and eID secure partner exchanges.

A monitoring band underneath shows flow status, reconciliation and owned error queues.

04 Considerations and limits

Engineering considerations and limits

  • Exactly once is a design, not a setting

    How we handle it

    We assume messages arrive twice or out of order and design consumers to be idempotent, with keys and ordering rules agreed per event type.

    Limits and dependencies

    Some legacy systems cannot accept idempotency keys or report what they processed. Around those, we add reconciliation rather than pretend.

  • An iPaaS is not always the answer

    How we handle it

    Platforms win for many standard connectors and mappings. Custom services win for complex logic, high volumes or strict latency. We document the choice per integration.

    Limits and dependencies

    Licence models change. A platform that is cheap today can become the largest line in your integration budget, so we model costs over several years.

  • Government exchanges set their own pace

    How we handle it

    We prepare onboarding files, security evidence and test plans early and work with the platform operator from the first week.

    Limits and dependencies

    Certification and onboarding timelines are set by the operator, not by us. We plan around them and tell you where they sit on the critical path.

  • AI consumers need narrow APIs

    How we handle it

    Agents and assistants get dedicated, scoped APIs with limits and audit logging, not the same broad access as internal services.

    Limits and dependencies

    Exposing an API to an agent adds risk. We review each one with your security team before it goes live.

05 How we work

How we work

We untangle before we build, and we leave every flow with an owner.

  1. 01

    Map the flows

    Every interface, its volume, its failure history and its business owner.

    OutputIntegration landscape and risk ranking

  2. 02

    Set the rules

    API guidelines, event conventions, identity model and the platform choice.

    OutputIntegration guidelines and decision records

  3. 03

    Move flow by flow

    Highest-risk flows first, with reconciliation running alongside the old interface until the numbers match.

    OutputMigrated flows with reconciliation evidence

  4. 04

    Operate visibly

    Dashboards per business process and error queues with named owners.

    OutputFlow ownership map and dashboards

06 Human control

Where people stay in control

Integration runs unattended. Ownership of what goes wrong cannot.

  • Every error queue has an owner

    Failed messages go to a team that is accountable for them, with context and a replay button, not to a shared log.

  • Contract changes are reviewed

    Breaking API or event changes go through a review with consumers before they are published.

  • Replays are deliberate

    Replaying messages into a system of record is an authorised action, logged with who did it and why.

07 Technologies

Technologies we work with

Integration platforms
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • AWS and Google Cloud integration services
Events and streaming
  • Apache Kafka
  • RabbitMQ
  • Cloud event brokers
  • Debezium for change data capture
APIs
  • OpenAPI and AsyncAPI
  • API gateways and developer portals
  • GraphQL where it fits
  • Contract testing
Identity
  • OAuth 2.0 and OpenID Connect
  • Mutual TLS
  • Keycloak and cloud identity providers
  • National eID schemes

Listing a technology describes our engineering experience. It does not imply a partnership with or endorsement by its vendor.

08 Example

An illustrative example

Illustrative example

A cross-border service that accepts several national eIDs

01Situation
A European agency serves applicants from all Member States. Each country’s eID and evidence format arrives differently, and staff re-key documents by hand.
02What we would build
One identity layer that accepts national eID schemes and the EU Digital Identity Wallet, and an evidence exchange built on the Once-Only Technical System where it is available.
03Where people decide
Caseworkers confirm evidence that arrives outside the automated exchange; identity assurance levels are set by the agency’s security officer.
04What we would measure
Share of applications with evidence received electronically, time from submission to complete file, and identity-related support requests.

09 Sector lens

In your sector

  • Public Sector & Government

    Once-only data exchange with authentic sources, eID for citizens and businesses, and the logging that national platforms require. See our work for the public sector.

  • Manufacturing & Industry

    ERP, MES and supplier portals connected through events, so planning, production and service share one picture.

  • Financial Services

    Core systems, CRM and partner APIs connected with strong identity, audit logging and reconciliation that finance trusts.

International

Interoperability across Member States

Cross-border services meet a different national data exchange, eID scheme and data standard in every country. The Interoperable Europe Act asks public bodies to assess cross-border interoperability, and eIDAS 2 brings EU Digital Identity Wallets that every Member State must offer.

We design integration layers where national exchanges and identity schemes are adapters behind stable internal contracts. Adding a country then means adding an adapter and its onboarding, not reworking the systems behind it.

Questions about integrations and APIs

Should we use an integration platform or build custom integrations?

Both, for different flows. Standard connectors, mappings and partner onboarding favour a platform. High-volume, latency-sensitive or logic-heavy flows often favour custom services. We decide per flow and document why.

Do you integrate Salesforce, SAP and Odoo?

Yes, regularly, with each other and with custom and government systems. FromNine holds partner status with all three (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), so our integration teams work alongside platform specialists. See our SAP integration work.

Do we need event-driven integration?

When several systems need to react to the same change, or when you need to decouple release cycles, events help. For simple request and response between two systems, an API is often enough. Most estates use both.

Can you integrate national eID schemes?

Yes. We integrate citizen and business eID schemes and design for the EU Digital Identity Wallets that Member States are introducing under eIDAS 2. Onboarding requirements differ per scheme and we plan for them early.

We have legacy middleware. Do we have to replace it?

Not all at once. We map what runs on it, move the riskiest or most expensive flows first and keep reconciliation in place until each migrated flow is proven.

Bring the interface that fails most often

We will show how we would make it observable, idempotent and owned, and what it would take to do the same for the rest.

Discuss your projectSee service assistance