Supply chain software in the pandemic: warehouse network integrations

By Marco Lopes · December 16, 2021 · Business & Culture

The pandemic has made a familiar supply chain problem harder to ignore: goods move through networks, but the software supporting them often behaves like a collection of islands. An order may begin in an online store, pass through an enterprise resource planning system, reach a third-party warehouse, and leave through a carrier whose status updates arrive somewhere else entirely.

When demand shifts, staffing changes, or deliveries slip, those gaps become operational problems. People compensate with spreadsheets, phone calls, and repeated data entry. We see warehouse integration as more than connecting APIs. It is the work of making shared information dependable enough for people to act on it.

At Kordspace, we approach that work as a remote collaborative software, AI, Web3, hardware, and design studio. Our starting point is not a technology stack. It is the operational decision an integration needs to support.

Think in networks, not individual connectors

A warehouse rarely operates alone. Suppliers, purchasing teams, fulfillment partners, carriers, customer service, and finance all depend on different views of the same physical activity.

A connector can successfully transfer a file while the business process still fails. A warehouse might acknowledge an order without reserving stock. A carrier label might exist before a parcel leaves the building. A returned item might be received but remain unavailable for resale.

We therefore begin by identifying business milestones rather than endpoints. What does “accepted” mean? When is inventory committed? Which event confirms dispatch? Who can correct a receiving discrepancy?

These definitions matter especially when adding warehouses or changing fulfillment partners. Without them, each new connection introduces another interpretation of the business. With them, we can create partner-specific adapters around a shared operational model.

Map one journey before designing the platform

We recommend following one order from purchase through fulfillment, including what happens when something goes wrong. Alongside the happy path, we map cancellations, partial shipments, damaged goods, substitutions, and returns.

For each step, we record the system responsible, the identifier used, the expected response time, and the person who owns an exception. We also look for manual work that is useful rather than automatically treating it as waste. An experienced warehouse operator may be resolving ambiguity that the existing software cannot represent.

Our first deliverable should be understandable to operations and engineering alike: a process map with clear handoffs. If we cannot explain where an order is waiting without opening several systems, we have already found a valuable integration requirement.

Establish ownership before synchronizing data

Connecting everything to everything sounds flexible, but it often creates circular updates and disputed records. We prefer explicit ownership by data domain.

The ERP might own purchasing and financial records. The warehouse management system might own physical stock movements. A commerce platform might own the customer-facing order, while an order management service decides fulfillment allocation. Those responsibilities vary, so we document them rather than assume them.

Inventory needs particular care. On-hand, reserved, available, damaged, and in-transit quantities are not interchangeable. We agree on the calculation behind each figure and identify which system can change its inputs.

We also create mappings for SKUs, warehouse locations, units of measure, and partner identifiers. A case of products and an individual item must never become equivalent merely because two fields share the name “quantity.”

Build around the interfaces partners actually have

Some partners offer modern APIs and webhooks. Others exchange EDI documents or scheduled files over SFTP. During the pandemic, replacing a partner’s software may be neither realistic nor necessary.

We favor an integration layer that accommodates those differences. Each adapter validates incoming information, translates it into an agreed internal format, and preserves the original message for investigation where appropriate.

On Google Cloud, our preferred cloud platform, Cloud Run can host adapters, Pub/Sub can decouple event producers from consumers, and Cloud Storage can hold incoming files and controlled archives. We choose a transactional data store according to consistency and query requirements, rather than treating the message bus as the business record.

AWS or Azure can support the same architectural principles when an organization’s infrastructure or procurement requirements favor them. We prioritize operability and team knowledge over forcing a cloud migration into an integration project.

Assume messages can be late, repeated, or missing

A network integration must tolerate imperfect delivery. Connections fail, partners retry requests, and events can arrive out of order. We design for these conditions instead of treating them as rare exceptions.

Every significant operation should have an idempotency strategy. If a warehouse sends the same shipment confirmation twice, we should not create two shipments or charge a customer twice. Stable business identifiers and recorded processing outcomes help us recognize repetition.

We use bounded retries with backoff for temporary failures, then route unresolved messages to a visible exception queue. A queue without an owner is simply another place for work to disappear.

We also distinguish message receipt from business acceptance. An HTTP success response can mean that a message reached the integration layer, not that the warehouse accepted the order. Those states should remain separate in both software and reporting.

Make inventory freshness visible

“Real time” is not a useful promise unless we define it. A stock feed updated every few minutes may be sufficient for one product category and unacceptable for another.

We ask how stale information affects a decision. Can a customer purchase the last available item? Can purchasing rely on the expected receipt? Can a transfer leave one warehouse before another is ready to receive it?

The answers guide event frequency, reconciliation schedules, and safety buffers. We expose when inventory was last updated and flag feeds that have stopped progressing. Silently displaying an old number as current is worse than admitting uncertainty.

Even with event-driven updates, we retain reconciliation. Periodic comparisons between warehouse records and downstream systems can uncover missed movements, mapping errors, and mistakes made outside the integration. Reconciliation complements events; it does not replace them.

Include the warehouse floor in the architecture

Integration diagrams often stop at the warehouse management system. Physical work continues through scanners, label printers, handheld devices, loading bays, and unreliable wireless coverage.

Our hardware and design perspective helps us ask practical questions early. What happens when a scanner loses connectivity? Can operators distinguish a successful scan from a queued action? Does a reprint create a duplicate tracking record? Can a damaged barcode be entered manually without bypassing validation?

We avoid assuming that delayed synchronization is safe for every operation. Recording a count offline may be manageable; allocating scarce stock from disconnected devices may create conflicts. We define the allowed offline behavior and make recovery understandable to the people using it.

Design security around partner boundaries

Warehouse integrations exchange commercially sensitive information and sometimes personal data. We share only what each participant needs to perform its role.

We use separate credentials for partners and environments, store secrets in a managed service, and restrict permissions to required operations. Credential rotation and access removal should be documented procedures, not emergency improvisations.

Logs need equal attention. They should help us trace an order without unnecessarily exposing addresses, credentials, or complete payloads. We agree on retention and access rules before accumulating archives.

Where partners offer limited security capabilities, we make the residual risk explicit and consider compensating controls. A legacy interface does not justify an invisible exception to the security model.

Measure business outcomes, not just uptime

A healthy server does not guarantee a healthy fulfillment process. We want visibility into how long orders wait for acknowledgment, how old inventory updates are, and which exceptions require human intervention.

We carry correlation identifiers across systems so that support teams can follow a transaction without searching unrelated logs manually. Dashboards should separate technical failures from business rejections: an invalid SKU requires a different response from an unavailable endpoint.

Alerts must also reflect responsibility. Engineering may own a failed adapter, while operations owns an unresolved quantity discrepancy. We agree on escalation paths and provide a replay or correction workflow with safeguards.

The objective is not to eliminate every exception. It is to make exceptions visible, explainable, and recoverable before they become customer surprises.

Roll out with a controlled operational boundary

We prefer a narrow first release: one warehouse, one partner, or one clearly defined order flow. The boundary should be small enough to support carefully but meaningful enough to test the business process.

Before production, we test duplicate events, partial files, unexpected units, cancellations after picking, partner downtime, and recovery after an outage. Partner sandboxes help, but they may not reproduce every production behavior.

Where feasible, we compare a new integration’s calculated results with the current process before allowing it to trigger physical actions. We avoid uncontrolled parallel execution that could send duplicate fulfillment instructions.

A rollout plan should include cutover ownership, reconciliation, rollback criteria, and communication with warehouse staff. Deployment is a technical event; operational acceptance is a separate milestone.

Treat collaboration as infrastructure

Remote work makes explicit communication particularly valuable. We cannot rely on an engineer overhearing a warehouse conversation or an operations manager noticing a problem on someone else’s screen.

We maintain a shared glossary, short decision records, and accessible runbooks. We involve warehouse operators, customer service, and finance in reviews, not just IT and procurement. Their questions often reveal missing states and responsibilities before code makes those omissions expensive.

We also plan changes around warehouse realities. Peak picking periods are poor moments for disruptive releases, and shift handovers need clear instructions. A technically elegant integration that increases uncertainty for operators is not a successful delivery.

Use advanced technology only where it earns its place

AI can support anomaly detection or demand planning, but unreliable identifiers and incomplete movement records undermine those applications. We establish trustworthy data flows and measurable baselines first, then evaluate whether a model improves a specific decision.

Similarly, Web3 or shared-ledger approaches deserve consideration only when multiple organizations have a concrete need for shared verification and workable governance. They do not automatically make physical inventory accurate or remove integration work.

Our broader capabilities help us choose among options, not prescribe all of them. Often, a reliable adapter, a clear exception screen, and a reconciliation process deliver the most immediate value.

A short readiness checklist

Before starting, we confirm that we can answer these questions:

• Have we mapped the order journey and its important exceptions?
• Does each data domain have a clear owner?
• Are identifiers, units, and inventory states consistently defined?
• Can we handle duplicate, delayed, and failed messages safely?
• Are reconciliation, monitoring, and exception ownership in place?
• Have warehouse staff reviewed the workflows and recovery steps?
• Do we have a controlled rollout and rollback plan?

Pandemic conditions make dependable coordination more valuable, but rushed connections can add fragility. We believe the strongest warehouse integrations combine clear business rules, resilient software, and respect for the people moving goods. If we can help connect your warehouse network or untangle an existing integration, start a project with Kordspace. To explore our approach across software, cloud, hardware, and design, read our related services pages.