API and EDI Interfaces

In fulfillment, the quality of system integration determines whether orders flow into the warehouse without manual intervention, inventory is displayed correctly, and customers receive tracking information on time. API interfaces and EDI (Electronic Data Interchange) are the two central technologies through which shop, ERP, WMS, shipping carriers, and 3PL partners communicate. Understanding the differences, use cases, and typical pitfalls helps you make the right integration decision – and avoid costly rework during peak season.

Why interfaces are essential in fulfillment

Every order passes through a chain of digital systems: the customer orders in the shop, the OMS prioritizes and distributes orders, the WMS controls pick and pack, the carrier API generates labels, and the ERP records inventory movements. Without automated interfaces, a manual step remains at every handoff – CSV exports, copy-pasting tracking numbers, or phone calls to the warehouse for stock inquiries.

Typical problems with missing or poor integration:

1. Overselling, because shop inventory lags hours or days behind warehouse stock.
2. Delayed shipping confirmations that violate marketplace SLAs and trigger penalties.
3. Duplicate data entry in shop, WMS, and ERP with an increasing error rate.
4. Lack of traceability when it is unclear during claims which system stored which version of an order.

Fulfillment interface stack

Four horizontal layers from top to bottom – with bidirectional connection lines between all layers (green for real-time API, blue for EDI batch):

For fundamentals on the overall architecture, see the article ERP and Shop Integration.

API and EDI – definition and distinction

What is an API interface?

An Application Programming Interface (API) enables programmatic data exchange between systems in real time or near real time. In e-commerce fulfillment, REST APIs (HTTP requests with JSON payload) dominate, and GraphQL is increasingly used by modern shop systems such as Shopify. Webhooks complement pull-based APIs: as soon as an event occurs (new order, shipping status), the source system pushes the information to the recipient.

Typical API applications in fulfillment:

• Transfer orders from shop to WMS or 3PL
• Report available inventory from warehouse to shop and marketplaces
• Generate shipping labels via carrier APIs
• Send tracking numbers back to shop and customer communication

What is EDI?

EDI (Electronic Data Interchange) is a standardized, often batch-oriented data exchange between companies. Instead of individual JSON structures, partners use fixed message types – frequently based on UN/EDIFACT or industry-specific formats such as ODETTE in the automotive sector. Transmission typically occurs via AS2, SFTP, or VAN services (Value Added Network).

EDI is particularly common for:

• Wholesale and B2B customers with fixed EDI agreements
• Supplier communication (orders, ASN)
• Corporate ERP systems (SAP, Oracle) in enterprise environments
• Retail chains with predefined EDI specifications

API vs. EDI – direct comparison

API vs. EDI use cases

Central data flows via interfaces

Orders (outbound from shop)

As soon as a customer order is paid and released, it must be transmitted to the executing system (own WMS or 3PL). At minimum, the following flows through the interface:

1. Order number and order date
2. Line items with SKU, quantity, and batch information if applicable
3. Delivery address and contact details
4. Shipping method and priority (standard, express)
5. Payment status and invoice reference if applicable

In multi-channel setups, an OMS consolidates orders from various sources before they go to the WMS. Details on shop integration can be found in the multi-channel fulfillment chapter.

Inventory updates (inbound to shop)

The WMS or 3PL partner reports available quantities back. The synchronization frequency is crucial: for fast-moving items, a nightly batch import is not enough. API-based real-time sync or at least hourly updates prevent overselling.

Shipping confirmations and tracking

After packing, the WMS sends shipping data to shop and OMS:

• Tracking number and carrier
• Ship date and estimated delivery
• Package weight and dimensions (for cost control)

This data triggers customer emails and marketplace updates. Delays here are one of the most common causes of poor reviews.

Goods receipt and ASN

For supplier goods, an Advance Shipping Notice (ASN) informs the warehouse in advance about incoming shipments. Depending on the partner, this happens via EDI message type DESADV or via API webhook. This allows the warehouse to plan capacity and accelerate goods receipt.

Order-to-ship via interfaces

Shop systems and their API landscape

The three most common shop platforms in German-speaking markets offer different levels of API maturity. A detailed comparison is available in the article Shopify WooCommerce Shopware.

EDI standards in the fulfillment context

For merchants who supply B2B in addition to D2C, the following EDI message types are relevant:

Technical connection usually occurs via an EDI service provider or middleware that translates EDI messages into API calls for the internal WMS. This reduces direct EDI effort in the WMS while maintaining B2B compliance.

Middleware and iPaaS as integration layer

Instead of programming each system combination individually, many merchants use middleware or iPaaS solutions (Integration Platform as a Service). These platforms offer preconfigured connectors for shop, WMS, ERP, and marketplaces and handle:

• Data mapping between different field structures
• Error handling with retry logic and alerting
• Transformation from EDI to JSON and vice versa
• Monitoring of all integration jobs on one dashboard

Well-known solutions in the DACH region include Billbee, ChannelEngine, Pickware Connect, and Weclapp. When evaluating the technical integration of a 3PL partner, clarify whether middleware is already included in the offer or must be budgeted separately.

Plan integration projects systematically

Phase 1: Requirements analysis

1. Which systems need to be connected (shop, WMS, ERP, carrier, 3PL)?
2. Which data flows are critical (orders, inventory, tracking, returns)?
3. What latency is required from a business perspective (real time vs. batch)?
4. Are there B2B partners with mandatory EDI?
5. What order volumes and peak scenarios are expected?

Phase 2: Technical specification

• Obtain API documentation for all involved systems
• Create field mapping tables (shop SKU ↔ WMS SKU ↔ ERP item number)
• Define error and retry strategy
• Request test environment (sandbox) from all partners

Phase 3: Development and testing

• Unit tests for mapping logic
• End-to-end tests with real test orders
• Load tests before peak seasons (Black Friday, Christmas)
• Parallel operation with manual fallback during transition phase

Phase 4: Go-live and monitoring

Integration project – timeline

Common sources of errors and countermeasures

SKU inconsistencies are the most common integration error. Shop, WMS, and ERP use different item numbers, and mapping breaks with new products or variants. Solution: central master data management in the ERP with a unique SKU as master.

Missing idempotency in API calls leads to duplicate orders when webhooks are triggered multiple times. Every message needs a unique reference ID, and the receiving system must detect duplicates.

No dead-letter handling: failed messages disappear in logs instead of landing in a queue for manual reprocessing.

Underestimated peak load: APIs that run stably at 50 orders/day break down at 2,000 orders/day during Black Week. Load tests are mandatory.

Further integration details can be found in WMS Integration.

Practical checklist: interfaces before go-live

• Field mapping for all item numbers (SKU, EAN, ERP no.) documented and tested
• Test order end-to-end through all systems successful
• Inventory sync frequency defined and tested during peak
• Tracking feedback to shop and marketplaces verified
• Cancellation and partial shipment flows implemented
• Return posting back to shop tested
• Error alerts (email, Slack, monitoring dashboard) active
• Retry logic for temporary API errors configured
• Dead-letter queue for failed messages set up
• API rate limits of all partners documented and considered
• Fallback process for interface outage defined in writing
• Data protection (GDPR) for customer address transfer verified

Security and compliance

Interfaces transfer personal data (customer addresses, email) and business-critical information. Consider:

1. Encryption: HTTPS/TLS for all API connections, AS2 with signature and encryption for EDI
2. Authentication: OAuth 2.0, API keys with minimal permissions, regular key rotation
3. Data processing agreement: conclude DPA with 3PL partners per GDPR
4. Logging: minimize or pseudonymize personal data in logs
5. Access control: enable only required endpoints, IP whitelisting where possible

Typical causes of integration failures

Companies with active monitoring significantly reduce integration failures – the trend shows a decline with consistent alerting and dead-letter handling.

Conclusion: choosing the right interface strategy

For the typical e-commerce merchant with shop, WMS, and carrier integration, REST APIs with webhooks are the standard – flexible, fast, and highly scalable. EDI complements the setup as soon as B2B wholesale customers or enterprise ERP partners impose fixed EDI requirements. In both cases: investment in clean mapping, robust error handling, and continuous monitoring pays off faster than manual workarounds during peak season.

Related topics

• ERP and Shop Integration
• Shopify WooCommerce Shopware
• WMS Integration
• Shop Integration in Multi-Channel
• Technical Integration in 3PL Selection

Last updated: July 7, 2026