The hard part was not connecting one API. It was making several different supplier contracts behave like one stable process without hiding the differences that mattered operationally.
The operating problem
Each supplier exposed a different combination of purchase orders, invoices, product data, cartons, and shipment notifications. Some used the industry-standard PromoStandards SOAP/XML services, another used a modern REST/JSON API, and legacy flows still depended on XML over HTTP or FTP files.
What we built
We built supplier-specific adapters in Python, then normalized their output into a shared order and shipment model. A MySQL operational layer stored staging records, product equivalences, duplicate controls, shipment events, and delivery logs.
The integration refreshed product mappings from Finale Inventory, assembled eligible orders and cartons, and wrote controlled updates through the Finale Inventory API. A web interface exposed pending work, shipments, picking activity, and mapping exceptions so operators could see what automation could not safely resolve on its own.
The shared model standardized routine processing while preserving supplier-specific rules at the adapter boundary.
The result
Operators gained one visible process for supplier activity that previously arrived through incompatible channels. Staging and duplicate controls made retries safer, while exception screens kept unresolved mappings from becoming silent inventory errors.
Reusable pattern: isolate external protocols in adapters, normalize before touching the ERP, and give operators a visible exception path.