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
Scroll sideways to see the whole drawing.
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
- From ERP to Integration platform: Business events, over REST · OData · webhook (primary flow).
- From Integration platform to CRM: Customers and orders, over REST/JSON (primary flow).
- From Integration platform to Logistics and carriers: Shipments booked, over REST/JSON (primary flow).
- From Logistics and carriers to Integration platform: Tracking events, over webhook (asynchronous).
- From Integration platform to E-invoicing and tax platform: Invoices for clearance, over SOAP/XML · REST (primary flow).
- From Integration platform to KYC and identity provider: Identity checks, over REST/JSON (primary flow).
- From KYC and identity provider to Integration platform: Check results, over webhook (asynchronous).
- From Integration platform to Dead-letter queue and alerts: Failed after retries, to a dead-letter queue (exception path).
- 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
- 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.
- 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.
- 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.
- 04
Tracking comes back
The carrier sends tracking and proof-of-delivery events by webhook, and the platform updates the order in the ERP.
- 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.
- 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 questionDo 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 questionCan 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 questionHow 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 questionWhat 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 questionWho 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 questionTell 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