Skip to main content
FromNine
Menu

Engineering

Interfaces that move data reliably and report when they fail.

We connect ERP, CRM, core banking and public platforms such as the Invoice Registration Portal through versioned contracts, events and sound identity. Records flow dependably, failures surface at once, and new consumers, AI among them, can be added safely.

For Indian enterprises linking ERP, banking and customer systems with GST e-invoicing, public platforms and customers in the European Union.

Share your requirementsPlatforms we integrate
Integrations & APIs: the four layersFour layers drawn one behind the other. Top: the consumers, such as portals, mobile apps and agents. Second: the API gateway with identity. Third: the event backbone. Bottom: the systems of record.01Portals, mobile apps, agents02API gateway and identity03Event backbone04Systems of record
  1. 01APIs designed contract first in OpenAPI and AsyncAPI, with versions and documentation
  2. 02Events with ordering, duplicate protection, a dead-letter queue and replay
  3. 03Each flow monitored from start to finish, and each error queue assigned to a named team

01 Challenges

Integration issues we are asked to resolve

  1. 01

    Direct links no developer wants to touch

    Dozens of point-to-point connections tie the ERP, CRM and in-house systems together. Changing a single field means retesting ten interfaces.

  2. 02

    Duplicate postings and failures nobody notices

    A retry books the same sales order twice. A rejected message vanishes. The business hears about it from a customer or at the GST return.

  3. 03

    Each new channel triggers a new interface

    The customer portal, the mobile app and now an AI assistant need the same records, and each one is given a separate extract.

  4. 04

    E-invoicing bolted on outside the ERP

    Invoices are uploaded to the IRP through a separate utility, IRNs are copied back by hand, and finance cannot say which invoices are still unregistered.

02 Scope of work

Scope of the practice

  1. 01 API design and management

    APIs designed from OpenAPI and AsyncAPI contracts, a versioning policy that a gateway enforces, and a developer portal where teams can find and reuse existing interfaces.

    Scope of work

    • Inventory of APIs and their owners
    • Design guidelines and a review procedure
    • Gateway policies for security, quotas and versions
    • Developer portal and API catalogue

    Deliverables

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

  2. 02 Integration through events

    Message brokers, change data capture and the outbox pattern, together with the details that make or break them: ordering, consumers that tolerate duplicates, dead-letter handling and replay.

    Scope of work

    • Event model and naming rules
    • Outbox pattern and CDC on source systems
    • Duplicate-safe consumers and ordering guarantees
    • Dead-letter queues with tools for replay

    Deliverables

    • Event backbone running in production
    • Schema registry with compatibility rules
    • Runbook for replay and recovery

  3. 03 Integration platforms, selected flow by flow

    SAP Integration Suite, MuleSoft and the integration services of each cloud all have a role. We will say when an iPaaS is better than custom code, and when it is not.

    Scope of work

    • Review of the middleware you run today
    • Platform selection on total cost of ownership
    • Reusable mappings and connectors
    • Migration away from ageing middleware

    Deliverables

    • Recorded decision on the integration platform
    • Library of integration patterns
    • Plan to migrate existing interfaces

  4. 04 Identity and trust between systems

    OAuth 2.0 and OpenID Connect, mutual TLS and identities for each service. For services in India, Aadhaar-based authentication and DigiLocker document fetch as design elements for organisations that use them; for users in the EU, national eID schemes and the EU Digital Identity Wallet.

    Scope of work

    • Identity architecture for people and for services
    • Token design, scopes and consent records
    • Onboarding and security reviews for each identity scheme
    • Readiness for EU Digital Identity Wallets where you serve EU users

    Deliverables

    • Identity design with a threat model
    • Identity integration running in production
    • Service identities and secret rotation in place

  5. 05 Links to public digital platforms

    Connections to the GST Invoice Registration Portal (IRP), which returns an Invoice Reference Number (IRN) for each reported invoice, and to APIs published through API Setu, the NeGD platform for government APIs. For invoices to EU customers, a Peppol access point using Peppol BIS Billing 3.0 on EN 16931.

    Scope of work

    • Onboarding and test runs with the platform or its provider
    • Mapping to the schemas each platform prescribes
    • Security and logging requirements of each platform
    • Handling of rejections, cancellations and late reporting

    Deliverables

    • Tested connection to each platform
    • Mapping documentation
    • Operating procedures agreed with your finance and IT teams

  6. 06 Flow status that business users can read

    Monitoring expressed in business terms, reconciliation between systems, and error queues that a team owns and clears.

    Scope of work

    • Flow monitoring at business process level
    • Reconciliation reports between systems, such as ERP invoices against IRNs
    • Classification and routing of errors
    • Alerts addressed to each flow owner

    Deliverables

    • Integration dashboard for each business process
    • Reconciliation checks running in production
    • Owner named for every error queue

03 Architecture

Reference architecture (illustrative)

The systems of record have two outlets. Synchronous calls pass through system APIs and a gateway that checks identity, scopes and quotas. Changes are published as events by way of an outbox or change data capture, and consumers handle them without creating duplicates.

A failed message 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 immediately when it halts.

Layers shown

Systems of record
ERP, CRM, core banking and case systems remain the authority for their own data.
Synchronous APIs
Versioned system APIs behind a gateway applying OAuth 2.0, mutual TLS and quotas.
Events
Outbox, broker, dead-letter queue and the mappings on the integration platform.
Consumers
Portals, apps, agents, partners and public platforms, with Aadhaar-based authentication or eID where individuals sign in.
Illustrative example

  1. Systems of record

    • ERP, CRM, core banking

  2. Synchronous APIs

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

  3. Events

    • Outbox and CDC
    • Event broker
    • Dead-letter queue and replay
    • Mappings on the integration platform

  4. Consumers

    • Portals, mobile apps, agents
    • Partners, IRP and public APIs
    • Identity: OIDC, mTLS, Aadhaar, eID

  5. Operations

    • Flow status, reconciliation, error queues with owners
APIs and an event backbone in parallel

An illustration only; not drawn from any client system.

Read the diagram as text

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

Alongside it, the systems of record publish changes through an outbox and change data capture to an event broker. The broker passes them to partner and public platforms, such as the IRP, and to an integration platform for mappings. Failed messages go to a dead-letter queue with replay. Identity services using OAuth, mutual TLS and national identity schemes protect the partner connections.

A monitoring band at the base shows the status of each flow, reconciliation results and error queues with owners.

04 Trade-offs and limits

Design trade-offs and limits

  • Exactly once must be designed in

    How we address it

    We expect each message to arrive twice or out of sequence, and we build consumers that tolerate this, with keys and ordering rules agreed for every event type.

    Limits and prerequisites

    Some older systems cannot take idempotency keys or tell us what they have processed. Around those we add reconciliation instead of assuming correctness.

  • An iPaaS is one option among several

    How we address it

    A platform is the better choice for many standard connectors and mappings. Custom services are better for complex logic, heavy volumes or tight latency. We record the reasoning for each integration.

    Limits and prerequisites

    Licensing terms change. A platform that costs little today can become the biggest item in your integration budget, so we project costs over several years.

  • Public platforms set their own timetable

    How we address it

    We prepare onboarding documents, security evidence and test plans early, and work with the platform operator or its authorised provider from the first week.

    Limits and prerequisites

    Onboarding, schema changes and timelines are decided by the platform, not by us. We plan around them and show you where they fall on the critical path.

  • AI consumers get narrow APIs

    How we address it

    Agents and assistants receive dedicated APIs with limited scope, quotas and audit logs, never the broad access that internal services may have.

    Limits and prerequisites

    Opening an API to an agent increases risk. Each such API is reviewed with your information security team before go-live.

05 Delivery steps

Delivery steps

We untangle the existing interfaces before building new ones, and every flow ends up with an owner.

  1. 01

    Map every flow

    Each interface with its volume, its failure record and its business owner.

    OutcomeIntegration landscape ranked by risk

  2. 02

    Agree the rules

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

    OutcomeIntegration guidelines and recorded decisions

  3. 03

    Migrate one flow at a time

    The riskiest flows go first, with reconciliation against the old interface until the figures agree.

    OutcomeMigrated flows with reconciliation evidence

  4. 04

    Run in the open

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

    OutcomeFlow ownership map and dashboards

06 Approvals

Who approves what

Interfaces run without supervision. Responsibility for failures still rests with people.

  • Each error queue has an owner

    A failed message reaches an accountable team together with its context and a replay option, rather than a shared log.

  • Contract changes are reviewed

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

  • A replay is an authorised act

    Replaying messages into a system of record needs authorisation and is logged with the name of the person and the reason.

07 Technology

Technology we use

Integration platforms
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • Integration services on AWS and Google Cloud
Events and streaming
  • Apache Kafka
  • RabbitMQ
  • Managed cloud event brokers
  • Debezium for change data capture
APIs
  • OpenAPI and AsyncAPI
  • API gateways and developer portals
  • GraphQL where suitable
  • Contract tests
Identity
  • OAuth 2.0 and OpenID Connect
  • Mutual TLS
  • Keycloak and cloud identity services
  • Aadhaar-based authentication and national eID

A product listed here reflects our engineering experience with it, not a partnership with or endorsement by its vendor.

08 Scenario

Illustrative scenario

Illustrative example

One ERP reporting to the IRP and invoicing EU customers through Peppol

01Starting point
A manufacturer registered for GST uploads e-invoices to the IRP through a standalone utility and keys the IRNs back into the ERP. Its EU customers now ask for Peppol invoices, and finance cannot tell which invoices are registered, rejected or still pending.
02What we would set up
An integration layer in which the ERP reports invoices to the IRP and stores the IRN and QR code it receives, and sends invoices for EU customers through a Peppol access point, with rejections routed to an owned error queue.
03Where an officer decides
The finance controller approves the mapping rules and decides on every cancellation or correction; the accounts team clears the error queue each day.
04How success would be measured
Invoices awaiting an IRN at day end, invoices rejected for late reporting, and time from dispatch to a Peppol invoice accepted by the EU customer.

09 By industry

By industry

  • Government & Public Sector

    Services built on Aadhaar-based authentication, DigiLocker and APIs from API Setu, with the logs that public platforms expect. More on Government & public sector.

  • Manufacturing & Industry

    ERP, MES, vendor portals and GST e-invoicing linked through events, so planning, production, dispatch and finance work from one view.

  • Banking & Financial Services

    Core banking, loan origination, CRM and partner APIs connected with strong identity, audit logs and reconciliation your finance and audit teams accept.

India

GST e-invoicing at home, Peppol and eIDAS for Europe

GST-registered businesses above the turnover threshold report B2B and export invoices to the Invoice Registration Portal, which returns an IRN, and since 1 April 2025 larger taxpayers can no longer report invoices older than 30 days. Public services can build on Aadhaar-based authentication, DigiLocker and APIs published through API Setu, all run under MeitY.

An Indian exporter invoicing EU customers meets different systems: buyers may ask for invoices over Peppol, using Peppol BIS Billing 3.0 on EN 16931, and users in the Union will sign in with EU Digital Identity Wallets under eIDAS 2. We design integration layers in which each platform is an adapter behind stable internal contracts, so adding the IRP, a Peppol access point or a new identity scheme does not mean reworking the systems behind them.

FAQs on integrations and APIs

Integration platform or custom-built integrations?

Each has its place. Standard connectors, mappings and onboarding of trading partners suit a platform. Flows with high volume, strict latency or heavy logic often suit custom services. We choose per flow and write down the reason.

Can you connect Salesforce, SAP and Odoo to the IRP and to our other systems?

Yes. We connect them to one another and to custom applications, and can link them to public platforms such as the IRP. FromNine is a partner of all three vendors (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), so our integration engineers work next to platform specialists. Further reading: Our SAP practice.

When does event-driven integration make sense?

When several systems must respond to the same change, such as an invoice registered with the IRP, or when teams need independent release cycles. For a simple request and reply between two systems, an API usually suffices. Most landscapes need both.

Can you build in Aadhaar-based authentication and DigiLocker?

We can design them into a service for organisations that use them, alongside national eID schemes and the EU Digital Identity Wallets that Member States are introducing under eIDAS 2 for your EU users. Onboarding and security requirements differ for each scheme, so we plan for them from the outset.

Must our old middleware be replaced?

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

Bring the interface that breaks most often

We will show how to make it observable, duplicate-safe and owned, and what the same treatment would take for the remaining flows.

Share your requirementsView service assistance