ERP integration platform for carrier APIs

A sales document is created in the ERP, and the shipping label in the logistics operator's system. Without integration, the user has to manually find the shipment, download the PDF, find the right document and connect the two. I built a .NET 8 platform running on the internal network that performs this process cyclically and leaves an audit trail.

• 01The sales document and the label were created in different systems.
• 02Each operator had its own integration contract and way of communicating.
• 03An external API can be temporarily unavailable or return a valid business state that does not yet allow the label to be downloaded.
• 04The manual process hindered auditing: there was no consistent information on when and how a label was linked to a document.
• 05The solution had to support new carriers without rebuilding the core.

The integration platform runs on the organization's side and connects the ERP with the logistics operators' APIs. The process has four steps.

• 01Detection: cyclic polling of the operator's API and reading document references on the ERP side.
• 02Label download: the PDF is fetched from the carrier's system and stored in the application repository.
• 03Matching: the shipment number is linked to the right sales document.
• 04Saving in the ERP: the attachment and the reference are saved through the ERP vendor's official API.

• 01The carrier adapter as a system boundary. The core knows no details of a specific operator. Each provider implements a common contract.
• 02Writes to the ERP only through the official interface. Reads may use read-only queries, but operations that modify documents go through the ERP vendor's API.
• 03Integration contracts follow the specification. Message structures are built from documented contracts.
• 04A technical error and a business state are not the same. The system distinguishes a transient API outage from a valid response saying the shipment is not ready yet.

• 01A web application and background services in .NET 8.
• 02Integration with the domain directory.
• 03SQL Server as the data layer.
• 04Carrier adapters behind a common interface.
• 05Retry/circuit breaker and controlled query limits.
• 06Structured logging and source availability monitoring.
• 07Architectural decisions documented in the repository.
• 08Automated tests protecting the contracts and the business logic.

• 01The standard process runs automatically, and the user returns to it mainly for exceptions that require a decision.
• 02Linking a label to a document leaves a trail of the time, the source and the result of the operation.
• 03New sender accounts and service scopes can be added through configuration.
• 04The adapter layer allows the integration to grow with new operators without rebuilding the core.
• 05The solution runs in production and is designed to survive application restarts and transient external API outages without losing process state.