Skip to content
XSIS
Talk to an engineer

Integrations

ERP and third parties

ERP to third parties: CRM, logistics, tax and identity

REST, SOAP, webhook and iPaaS connections between your ERP and the services around it, with retries and alerts.

Blueprint

ERP to third parties: one platform, many partnersBusiness events leave the ERP once and the integration platform delivers them to each partner in the format it expects. Callbacks come back the same way. A message that still fails after its retries goes to a dead-letter queue and raises an alert with the payload attached.ERPERPCustomers, orders,invoicesXSISIntegration platformiPaaS or customservices, mapping andretriesThird partyCRMAccounts, contactsand opportunitiesThird partyLogistics andcarriersShipments andtrackingThird partyE-invoicing andtax platformClearance andreportingThird partyKYC and identityproviderVerification andscreeningServiceDead-letter queueand alertsNothing is droppedPeopleSupport team1REST · ODatawebhook2REST/JSON3REST/JSON4webhook5SOAP/XML · REST6REST/JSON7webhook89

ERP to third parties: one platform, many partners

Business events leave the ERP once and the integration platform delivers them to each partner in the format it expects. Callbacks come back the same way. A message that still fails after its retries goes to a dead-letter queue and raises an alert with the payload attached.

  • Primary flow
  • Asynchronous
  • Exception path

The flow, step by step

  1. From ERP to Integration platform: Business events, over REST · OData · webhook (primary flow).
  2. From Integration platform to CRM: Customers and orders, over REST/JSON (primary flow).
  3. From Integration platform to Logistics and carriers: Shipments booked, over REST/JSON (primary flow).
  4. From Logistics and carriers to Integration platform: Tracking events, over webhook (asynchronous).
  5. From Integration platform to E-invoicing and tax platform: Invoices for clearance, over SOAP/XML · REST (primary flow).
  6. From Integration platform to KYC and identity provider: Identity checks, over REST/JSON (primary flow).
  7. From KYC and identity provider to Integration platform: Check results, over webhook (asynchronous).
  8. From Integration platform to Dead-letter queue and alerts: Failed after retries, to a dead-letter queue (exception path).
  9. From Dead-letter queue and alerts to Support team: Alert with the payload and the error (exception path).

Overview

This is the flow between your ERP and the services around it: the CRM, carriers and logistics providers, e-invoicing and tax platforms, and identity and KYC providers. Each partner has its own API, its own format and its own failures, and each one usually arrives as a separate project.

The reference design sends business events out of the ERP once, to an integration platform that delivers them to each partner in the format it expects, over REST, SOAP, webhooks, or EDI over AS2 where trading partners require it. Callbacks, such as tracking events or check results, come back through the same platform.

A partner being down is a normal event, not an emergency. Temporary failures are retried. A message that still fails after its retries goes to a dead-letter queue, and an alert reaches the support team with the payload and the error, so it can be fixed and replayed.

How the flow works

  1. 01

    The ERP publishes an event

    When a customer, order or invoice changes, the ERP publishes one business event to the integration platform, through its API, OData services or webhooks.

  2. 02

    The CRM stays current

    The platform updates accounts, contacts and orders in the CRM, so sales and service teams see what the ERP knows.

  3. 03

    Shipments are booked

    Orders ready to ship are booked with the carrier or logistics provider through its API, and labels and references come back.

  4. 04

    Tracking comes back

    The carrier sends tracking and proof-of-delivery events by webhook, and the platform updates the order in the ERP.

  5. 05

    Invoices are cleared

    Invoices are sent to the e-invoicing or tax platform in the format the authority requires, and the clearance status is stored with the invoice.

  6. 06

    Identities are checked

    New customers or suppliers are sent to the KYC or identity provider, and the result returns by webhook before the account is activated.

When something fails

A partner is temporarily unavailable

The call is retried with increasing delays. An idempotency key on every write means a retry never creates a second shipment or invoice.

A message still fails after its retries

It goes to a dead-letter queue with the payload and the partner’s error, and the support team is alerted. Once fixed, it is replayed from the queue.

A partner changes its API

Contract tests run against each partner’s test environment and catch the change. Announced changes are scheduled and tested before the partner’s deadline.

The data is rejected

A partner that refuses data for a business reason, such as a missing tax number, sends the error back to the ERP record, where the owner can correct it.

Standards and systems

Integration
  • REST
  • SOAP
  • Webhooks
  • OpenAPI
  • EDI (EDIFACT, ANSI X12)
  • AS2
  • MuleSoft
  • Boomi
  • Azure Logic Apps
Identity and access
  • OAuth 2.0

Questions and answers

Which third-party services can you connect?

Any service with a documented API or file interface. Typical examples are CRM platforms, carriers and logistics providers, marketplaces, e-invoicing and tax platforms, payroll, KYC and identity providers, and trading partners who exchange EDI documents over AS2. We review each partner’s API, limits and test environment before we commit to a plan.

Link to this question
Do we need an integration platform for this?

Once several partners are connected to one ERP, a platform such as MuleSoft, Boomi or Azure Logic Apps, or a set of custom services built on a message queue, keeps mapping, retries and monitoring in one place. With one or two partners, direct connections can be enough. We set out the trade-offs, including licence costs, for your case.

Link to this question
Can you connect us to e-invoicing and tax clearance platforms?

Yes. Many countries now require invoices to be issued or cleared through a government or accredited platform in a defined format. We integrate the ERP with the platform your country requires or with an accredited provider, store the clearance status and identifiers with each invoice, and handle rejections. Your tax advisers confirm the rules that apply to you.

Link to this question
How do you secure incoming webhooks?

Every incoming webhook is verified before it is processed: by signature where the partner signs its messages, and by token, source and timestamp checks where it does not. Payloads are validated against the contract, and events are processed once even if the partner sends them more than once.

Link to this question
What happens when a partner has an outage?

The rest of the flows keep running. Messages for that partner are retried and then queued, the support team is alerted, and nothing is lost. When the partner recovers, queued messages are replayed in order. The dashboard shows which partner is affected and how many messages are waiting.

Link to this question
Who owns the connectors you build?

Intellectual property in the work we build for you is yours from the first commit — no assignment step at the end. Connectors are delivered with their source code, tests and documentation, so your team or another supplier can maintain them. Any XSIS tools that existed before stay ours and are licensed to you. Partner APIs and integration-platform licences remain under those vendors’ own terms.

Link to this question

Tell us what you need to build or connect.

Describe the systems, the timeline and the constraints. The right engineers take it from there.

  • Our team will call you within 24 hours during your preferred time slot
  • Our team is available 24/7