Skip to main content
FromNine
Menu

Engineering

Integrations that keep data flowing and show you when it stops.

We link CRM, ERP, case systems and Government platforms through clear contracts, events and sound identity. Data moves reliably, errors are in plain sight, and new capabilities, AI among them, can be connected without risk.

For suppliers invoicing Government, public entities connecting to Malta e-ID and groups linking Maltese systems with those abroad.

Start a conversationView the platforms we integrate
Integrations & APIs: the layers we buildFour layers shown one behind the other. Top to bottom: the consumers, such as portals, apps and agents; the API gateway together with identity; the event backbone; and beneath them the systems of record.01Apps, portals and agents02Identity and API gateway03Backbone for events04Systems of record
  1. 01APIs designed contract first in OpenAPI and AsyncAPI, with versions and documentation
  2. 02Events with ordering, idempotency, dead-letter queues and replay
  3. 03Each flow monitored from start to finish, with error queues owned by named teams

01 Common problems

Integration problems organisations bring to us

  1. 01

    Direct links no one wants to touch

    Dozens of one-to-one connections between CRM, ERP and bespoke systems. A change to a single field means retesting ten interfaces.

  2. 02

    Duplicate records and failures nobody notices

    A retry produces a second order. A failed message vanishes. Your staff hear about it from clients.

  3. 03

    Each new channel brings fresh integration work

    The portal, the mobile app and now an AI assistant need the same data, and every one of them gets its own extract.

  4. 04

    Connecting to Government is a project every time

    Linking to Malta e-ID or sending e-invoices to a Government buyer takes weeks of onboarding, security and testing work on each occasion.

02 Delivery scope

Our delivery scope

  1. 01 API strategy and API management

    Design that puts the API first, with contracts in OpenAPI and AsyncAPI, a policy for versions, a gateway that applies it and a developer portal where teams find and reuse what is already there.

    Our work

    • A map of the API landscape and who owns each API
    • Design guidelines with a review process
    • Gateway policies for security, quotas and versions
    • A developer portal with an API catalogue

    What you get

    • API guidelines your teams have adopted
    • Gateway configuration held as code
    • A catalogue of documented APIs

  2. 02 Integration driven by events

    Brokers, change data capture and the outbox pattern, together with the details that make or break them: ordering, idempotent consumers, dead-letter queues and replay.

    Our work

    • An event model with naming conventions
    • Outbox and CDC on the source systems
    • Idempotent consumers and guaranteed ordering
    • Dead-letter queues with tools to replay

    What you get

    • An event backbone running in production
    • A schema registry with compatibility rules
    • A runbook for replay and recovery

  3. 03 Integration platforms, chosen flow by flow

    SAP Integration Suite, MuleSoft and the integration services of the cloud providers each suit certain cases. We say when an iPaaS is better than custom code and when it is not.

    Our work

    • Review of the middleware you already run
    • Choice of platform based on total cost of ownership
    • Mappings and connectors that can be reused
    • Migration away from legacy middleware

    What you get

    • A recorded decision on the integration platform
    • A library of integration patterns
    • A plan for migrating current interfaces

  4. 04 Identity and trust between systems

    OAuth 2.0 and OpenID Connect, mutual TLS, identities for services, and sign-in with national eID: Malta e-ID, operated by MITA with the ID card notified at eIDAS level High, as well as schemes in other Member States such as itsme, DigiD and eHerkenning, BundID, FranceConnect, Cl@ve, SPID and CIE.

    Our work

    • Identity architecture for people and services
    • Design of tokens, scopes and consent
    • Support with eID onboarding and certification
    • Readiness for the EU Digital Identity Wallet

    What you get

    • An identity design with its threat model
    • eID sign-in live in production
    • Service identities and secret rotation in operation

  5. 05 Connecting to Government and public platforms

    Links to Maltese Government services, such as Malta e-ID and e-invoices in EN 16931 sent over Peppol to ministries, departments, entities and local councils; to national exchanges in other Member States, such as MAGDA in Belgium, Digikoppeling in the Netherlands, FIT-Connect in Germany, PDND in Italy and API Entreprise in France; and to the EU Once-Only Technical System.

    Our work

    • Onboarding together with the platform operator
    • Mapping to national data standards and EN 16931
    • Meeting the security and logging rules of each exchange
    • Designing the exchange of once-only evidence

    What you get

    • A tested connection to the exchange or network
    • Documentation of the mappings
    • Operating procedures agreed with the operator

  6. 06 Visibility for the business

    Monitoring of flows in terms your staff understand, reconciliation between systems, and error queues that a named person owns and clears.

    Our work

    • Monitoring of flows at business level
    • Reconciliation reports across systems
    • Classifying and routing errors
    • Alerts sent to the owner of each flow

    What you get

    • An integration dashboard per business process
    • Reconciliation checks running in production
    • A map of who owns each error queue

03 Architecture

A reference architecture, shown for illustration

Two paths lead out of the systems of record. Requests that need an immediate reply pass 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 handle them idempotently.

A message that fails goes to a dead-letter queue from which it can be replayed, not into a log file. A monitoring band presents each flow in business language, so the owner of a process sees at once when it stops.

Layers shown in the diagram

Systems of record
ERP, CRM and case systems stay the authority for their own data.
Request and reply
Versioned system APIs behind a gateway applying OAuth 2.0, mTLS and quotas.
Events
The outbox, the broker, the dead-letter queue and mappings in the integration platform.
Consumers
Portals, apps, agents, partners and Government exchanges, with Malta e-ID where residents sign in.
Illustrative example

  1. Systems of record

    • Case systems, ERP and CRM

  2. Request and reply

    • System APIs
    • API gateway with OAuth 2.0, mTLS and quotas

  3. Events

    • CDC and outbox
    • Broker for events
    • Dead-letter queue with replay
    • Mappings in the integration platform

  4. Consumers

    • Apps, portals and agents
    • Exchanges with partners and Government
    • Identity with OIDC, mTLS and e-ID

  5. Operations

    • Monitoring of flows, reconciliation and owned error queues
APIs and an event backbone running in parallel

Shown for illustration only; this is not a client system.

Read the diagram as text

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

Alongside it, the systems of record publish changes through an outbox and change data capture to an event broker. The broker delivers them to exchanges with partners and Government and to an integration platform that handles mappings. Messages that fail go to a dead-letter queue with replay. Identity services using OAuth, mTLS and eID protect the partner exchanges.

Beneath, a monitoring band shows the status of flows, reconciliation and error queues with owners.

04 Choices and limits

Engineering choices and their limits

  • Exactly-once delivery has to be designed

    Our approach

    We expect messages to arrive twice or in the wrong order, so consumers are idempotent, with keys and ordering rules agreed for each type of event.

    Limits and what we rely on

    Certain legacy systems cannot take idempotency keys or tell us what they have processed. For those we add reconciliation instead of pretending the problem is solved.

  • An iPaaS does not suit every flow

    Our approach

    A platform is stronger for many standard connectors and mappings. Custom services are stronger for complex logic, large volumes or tight latency. We record the choice for every integration.

    Limits and what we rely on

    Licence models change over time. A platform that costs little now can become the biggest item in your integration budget, so we model the cost over several years.

  • Government platforms work to their own timetable

    Our approach

    We prepare onboarding documents, security evidence and test plans early, and we work with the platform operator, for example MITA for Malta e-ID, from week one.

    Limits and what we rely on

    The operator decides how long certification and onboarding take, not FromNine. We plan around those timelines and show you where they fall on the critical path.

  • AI consumers need narrow APIs

    Our approach

    Assistants and agents receive their own APIs, scoped and limited and with an audit log, never the wide access that internal services have.

    Limits and what we rely on

    Opening an API to an agent increases risk. We review every such API with your security staff before it goes into production.

05 Our method

Our method

We untangle what exists before building anything new, and every flow ends up with an owner.

  1. 01

    Chart the flows

    Each interface, with its volume, its history of failures and the person in the business who owns it.

    ResultAn integration landscape ranked by risk

  2. 02

    Agree the rules

    API guidelines, conventions for events, the identity model and the choice of platform.

    ResultIntegration guidelines with decision records

  3. 03

    Migrate one flow at a time

    The riskiest flows go first, with reconciliation running next to the old interface until the figures agree.

    ResultMigrated flows with reconciliation evidence

  4. 04

    Run in plain sight

    Dashboards for each business process, and error queues with named owners.

    ResultDashboards and a map of flow owners

06 People in control

Where people keep the decision

Integration runs without anyone watching. Responsibility for what fails still has to sit with a person.

  • Each error queue has an owner

    A failed message goes to an accountable team, with its context and a replay button, never to a shared log.

  • Changes to contracts are reviewed

    Any breaking change to an API or event is reviewed with its consumers before publication.

  • Replays are intentional

    Sending messages again into a system of record requires authorisation, and the log records who did it and for what reason.

07 Technologies

Technologies in our toolset

Integration platforms
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • Integration services on AWS and Google Cloud
Events and streaming
  • Apache Kafka
  • RabbitMQ
  • Event brokers from the cloud providers
  • Debezium for change data capture
APIs
  • AsyncAPI and OpenAPI
  • Developer portals and API gateways
  • GraphQL where it suits
  • Contract tests
Identity
  • OpenID Connect and OAuth 2.0
  • Mutual TLS
  • Keycloak and identity services of the cloud providers
  • National eID schemes, Malta e-ID included

We list a technology because our engineers have worked with it. The list does not mean that its vendor partners with or endorses FromNine.

08 Illustrative case

An illustrative case

Illustrative example

E-invoices from a supplier’s ERP to Government buyers

01Starting point
A Maltese distributor supplies several ministries, public entities and local councils. Invoices go out as PDF attachments by email, a new call for tenders requires e-invoices, and payment queries take staff hours each week.
02The system we would put in place
An integration that turns ERP invoices into EN 16931 e-invoices in Peppol BIS Billing 3.0, sends them through the distributor’s chosen Peppol access point and posts delivery and rejection messages back into the ERP.
03Where staff decide
The finance team approves each new buyer set-up and any invoice the validation step rejects; corrections are never resent automatically.
04How we would judge success
Share of Government invoices sent as e-invoices, rejections per hundred invoices, and days from invoice to payment.

09 By sector

Sector by sector

  • Government & Public Entities

    Ministries, departments and public entities exchanging data once only, residents signing in with Malta e-ID, and the logging that Government platforms ask for. Read more on Government & Public Entities.

  • Manufacturing & Industry

    ERP, MES and supplier portals at Maltese plants linked through events, so that planning, production and service work from the same picture.

  • Financial Services

    Core banking or policy systems, CRM and partner APIs linked with strong identity, audit logs and reconciliation that the finance function can trust.

Malta

Government platforms and EU interoperability

In Malta, much public integration runs through shared Government platforms. Malta e-ID is the national digital identity, operated by MITA, and servizz.gov brings online services together. For invoices, Government chose the Peppol network and must accept EN 16931 e-invoices on contracts above EU thresholds, while suppliers are not legally obliged to send them unless a call for tenders asks for it.

At EU level, the Interoperable Europe Act asks public bodies to assess cross-border interoperability, and eIDAS 2 requires every Member State to offer an EU Digital Identity Wallet by 24 December 2026. We build integration layers in which Malta e-ID, Peppol and foreign exchanges are adapters behind stable internal contracts, so a new connection means a new adapter and its onboarding, not a rework of the systems behind it.

Common questions on integrations and APIs

Is an integration platform better than custom integration?

Each suits different flows. A platform is the better fit for standard connectors, mappings and onboarding partners. Flows with large volumes, tight latency or a lot of logic often suit custom services. We choose flow by flow and write down the reasons.

Do you connect Odoo, SAP and Salesforce?

Often, both to one another and to bespoke and Government systems. FromNine is a partner of all three (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), so our integration engineers work side by side with platform specialists. Read about our SAP integration work.

Is event-driven integration necessary for us?

Events help when several systems must react to one change, or when teams need to release independently. Between two systems with a simple request and reply, an API usually suffices. Most organisations end up with both.

Can you connect our service to Malta e-ID and send e-invoices to Government?

Yes. We integrate Malta e-ID and other national eID schemes, and we design for the EU Digital Identity Wallets that Member States must offer by 24 December 2026 under eIDAS 2. For e-invoicing, Government accepts EN 16931 invoices in Peppol BIS Billing 3.0 on contracts above EU thresholds; suppliers are not legally required to send them, although some calls for tenders do ask for it. We connect your ERP to the Peppol access point of your choice.

Must we replace our legacy middleware?

Not in one go. We chart what runs on it, migrate the riskiest or costliest flows first, and keep reconciliation running until each migrated flow has proved itself.

Show us the interface that breaks most often

We will explain how we would make it visible, idempotent and owned, and what doing the same for the others would involve.

Start a conversationExplore service assistance