EDI and API integration for fashion wholesale orders: a comparison

Fashion wholesalers stand at a technology crossroads. On one side, Electronic Data Interchange has structured order flows for three decades, with standardised message types such as ORDERS, ORDRSP and DESADV ensuring that purchase orders, confirmations and dispatch notices move between systems without manual rekeying. On the other, REST APIs promise lighter integration, faster deployment and the flexibility to adapt quickly as business needs shift.

The choice is rarely binary. Large fashion brands and retailers typically support both protocols, routing high-volume, structured transactions through EDI whilst reserving APIs for new digital channels, custom workflows or smaller trading partners. Understanding when each approach fits, what each costs and how long deployment takes has become essential knowledge for wholesale directors, IT managers and supply chain leaders.

The stakes are rising. Retailers press suppliers to automate order acknowledgements and shipping notices, seeking to cut lead times and inventory errors. Meanwhile, wholesale teams must balance the cost and complexity of maintaining dual integration infrastructure against the risk of losing business from partners who demand one protocol or the other.

What is EDI and how does it work for fashion wholesale orders?

Electronic Data Interchange is a set of standardised message formats that allow computer systems to exchange business documents, replacing paper purchase orders, invoices and shipping notices. In fashion wholesale, three EDI message types dominate. ORDERS carries the purchase order from buyer to supplier, specifying product codes, quantities, sizes, colours, delivery dates and shipping addresses. ORDRSP returns an order response, confirming whether the supplier accepts the order as written or proposing changes to quantities or delivery dates. DESADV, the despatch advice, notifies the buyer that goods have shipped, listing carton contents, tracking numbers and expected arrival times.

EDI messages travel over networks known as value-added networks or via AS2, a secure internet protocol. The messages themselves follow either UN/EDIFACT, the international standard widely used in Europe, or ANSI X12, common in North America. Both frameworks define fixed field positions and mandatory data elements, ensuring that any system capable of reading EDIFACT ORDERS can parse a purchase order regardless of which company sent it.

This standardisation brings predictability. A fashion brand that implements EDIFACT ORDERS once can exchange orders with hundreds of suppliers using the same message structure. Retailers enforce compliance by publishing implementation guides that specify which fields are mandatory, which codes to use for size scales and how to handle backorders. The rigidity that makes EDI robust also makes it slow to adapt when new data points, such as sustainability attributes or batch traceability codes, need to travel alongside the order.

What are REST APIs and why are fashion companies adopting them?

Representational State Transfer APIs offer a different model. Instead of fixed message formats, REST APIs expose business functions as web endpoints. A supplier's system sends an HTTP request to a buyer's order endpoint, typically transmitting data in JSON format, and receives a response confirming receipt or flagging validation errors. The API provider publishes documentation describing the available endpoints, required fields and authentication methods.

Fashion companies adopt REST APIs for several reasons. Implementation is faster because developers use familiar web technologies and standard libraries rather than specialised EDI translation software. APIs support real-time queries, allowing a brand's order management system to check inventory availability at a supplier before finalising the purchase order. They also accommodate richer data structures, such as nested product attributes or links to design files, without the constraints of fixed EDI field lengths.

The trade-off is fragmentation. Each retailer's API uses a different data model, endpoint structure and authentication scheme. A supplier integrating with ten retail partners via API must build and maintain ten distinct connections, whereas a single EDIFACT implementation can serve all ten if they follow the standard. This has led some technology providers to offer middleware that translates between EDI and REST, allowing suppliers to receive orders in one format whilst responding to partners in another.

How do costs compare between EDI and API integration?

EDI's cost structure is front-loaded. Initial implementation typically requires purchasing or licensing EDI translation software, which parses and generates EDI messages, and subscribing to a value-added network or configuring AS2 connections. For a mid-sized fashion supplier, software licensing can range from several thousand to tens of thousands of pounds annually, depending on transaction volumes and the number of trading partners. Value-added network charges are usually transaction-based, costing pence per document exchanged. Some large retailers insist on specific networks, adding switching costs if a supplier already uses a different provider.

Consulting and integration services form the largest upfront expense. Mapping internal order data to EDI message fields, handling size and colour code translation and building error-handling logic often require specialist consultants. Implementation projects commonly run to tens of thousands of pounds for a supplier connecting to a major retail partner. Ongoing costs are lower, consisting mainly of software maintenance, network fees and occasional updates when a trading partner changes its implementation guide.

REST API costs lean towards development time rather than licensing. Open-source libraries for JSON parsing and HTTP communication eliminate some software expenses. However, each API integration is bespoke, requiring developers to read documentation, write custom code for authentication, field mapping and error handling, and test against the partner's sandbox environment. A supplier integrating with multiple retailers must multiply this effort. Maintenance costs rise in proportion to the number of distinct API connections, because updates to one partner's API require retesting and potential code changes.

For suppliers serving a handful of large retail accounts, EDI's standardisation can lower total cost of ownership over several years. For brands launching direct-to-consumer wholesale programmes with many small boutiques, the absence of VAN fees and the ability to reuse internal development resources can make REST APIs more economical. The calculation shifts when hybrid models enter, such as using an integration platform that abstracts both EDI and API connections behind a single interface.

How long does implementation take for each approach?

EDI implementation timelines stretch from three to six months for a typical fashion wholesale connection. The first phase involves procuring software and establishing network connectivity, which can take four to eight weeks depending on vendor lead times and IT approval cycles. Mapping and translation work follows, during which the supplier's developers define how internal product codes, size scales and order statuses correspond to EDI code lists and message fields. This phase often uncovers data quality issues, such as missing or inconsistent product identifiers, that must be resolved before testing.

Testing consumes the most time. Trading partners conduct interchange testing, exchanging sample ORDERS, ORDRSP and DESADV messages and validating that each field populates correctly. Retailers frequently reject initial test messages for code mismatches or missing mandatory fields, triggering revision cycles. Only after both parties certify that messages meet the implementation guide do they proceed to a pilot phase, processing a small number of live orders under close monitoring. Finally, the connection goes into production, though issues often surface in the first few weeks as edge cases arise.

REST API implementations can go live in as little as two to four weeks if documentation is comprehensive and the supplier already has experienced API developers. The absence of certification bodies and rigid interchange testing accelerates the process. A developer reads the API specification, writes integration code, authenticates against the partner's test environment and begins exchanging sample orders. Many API providers offer interactive documentation and sandbox environments that allow real-time testing, shortening the feedback loop when errors occur.

However, API timelines vary widely. Poorly documented APIs, incomplete error messages or frequent breaking changes can extend implementation to three months or more. Unlike EDI, where the standard constrains both parties, REST APIs place more responsibility on the API provider to maintain stable, well-documented endpoints. Suppliers report frustration when retail partners update API versions without notice or when authentication schemes change mid-project. The faster best-case scenario for APIs comes with higher variance and less predictability.

What do retailers require from their wholesale suppliers?

Retailer mandates shape the integration landscape. Large fashion retailers with legacy enterprise resource planning systems typically require EDI for wholesale orders. Their procurement and warehouse management systems were built to send and receive EDIFACT or X12 messages, and retrofitting them to consume REST APIs would demand costly upgrades. Supplier contracts often specify EDI as a condition of doing business, listing the exact message types, code lists and response times expected.

Smaller retailers and digitally native brands lean towards APIs. Without the burden of decades-old ERP infrastructure, they build order management systems on modern web platforms that expose REST endpoints by default. Some provide libraries or SDKs in common programming languages to simplify supplier integration. A growing cohort of multi-brand boutiques use cloud-based wholesale platforms that aggregate orders from various channels and present a single API to suppliers, abstracting the underlying complexity.

The middle market is fragmented. Regional department store chains may require EDI for apparel orders but accept manual CSV uploads for accessories or seasonal collections. Fast-growing e-commerce retailers sometimes start with email purchase orders, migrate to API integrations as volumes rise, then consider EDI only when their transaction count justifies the investment. Suppliers serving diverse retail segments often maintain three parallel processes: EDI for major accounts, API for digital-first partners and manual entry for the long tail.

Compliance requirements add another layer. Retailers specify turnaround times for order acknowledgements, often demanding ORDRSP within 24 hours of receiving ORDERS. They expect DESADV messages before goods arrive at the distribution centre, allowing warehouse staff to prepare receiving bays and cross-dock shipments. Missing or late EDI messages can trigger chargebacks or deductions from supplier invoices. API-based integrations set similar expectations through service-level agreements, but enforcement mechanisms vary and some retailers monitor API response times in real time, flagging latency issues immediately.

Which approach fits different types of fashion businesses?

Enterprise fashion brands supplying major department stores and supermarket chains have little choice but to implement EDI. The volume of orders, the need for automated warehouse processes and retailer mandates all point towards EDIFACT or X12. These brands typically invest in robust EDI infrastructure, often managed by dedicated integration teams or outsourced to third-party service providers. The fixed costs are justified by the transaction volumes and the penalty costs of manual errors.

Mid-sized brands serving a mix of large and small retailers benefit from hybrid models. Core wholesale orders flow through EDI to satisfy major partners, whilst API connections handle newer digital channels and speciality boutiques. Some brands use integration platforms that present a unified interface internally, translating outbound data into either EDI or JSON depending on the recipient. This approach requires investment in middleware but avoids forcing every sales operations user to understand protocol nuances.

Emerging designers and small-batch producers often start with APIs or even manual processes. When wholesale order volumes number in the tens rather than thousands per month, the overhead of EDI certification and VAN fees is hard to justify. REST APIs align with the web development skills these businesses already employ for e-commerce. As they scale and add larger retail accounts, they face pressure to adopt EDI, sometimes relying on integration partners or software-as-a-service platforms that bundle EDI translation with order management.

Vertical integrators, brands that design, manufacture and retail their own products, may avoid wholesale data exchange protocols altogether. However, even vertically integrated companies operate franchise or concession partnerships where order data must flow between systems. In those cases, the choice between EDI and API depends on the legacy systems in place and the technical sophistication of franchise partners. A franchisor with hundreds of small operators may provide a simple API or web portal rather than requiring each franchisee to implement EDI.

What did Levi Strauss do to modernise wholesale order integration?

Levi Strauss offers a concrete example of how a heritage brand has navigated integration modernisation. In 2025, Levi Strauss reported that it had expanded its digital and API-based integration capabilities to streamline wholesale order processing with retail partners, according to the company's investor presentations. The initiative aimed to reduce order-to-acknowledgement cycle times and improve inventory visibility across its wholesale channel, which remains a significant revenue stream alongside direct-to-consumer sales.

The approach combined maintaining existing EDI connections for legacy retail partners with launching new REST API endpoints for digitally native accounts. Levi Strauss indicated that API integrations cut order confirmation times from 24 hours to under one hour for participating retailers, enabling faster replenishment cycles. The company invested in middleware that translates between internal order formats and both EDI and JSON, allowing its customer service and supply chain teams to work from a single interface regardless of how a retail partner connects.

The project took approximately 18 months from planning to full deployment across priority wholesale accounts. Early results included a reduction in order entry errors and faster resolution of discrepancies, as real-time API callbacks allowed immediate validation of product codes and delivery addresses. Levi Strauss has continued to support EDI for the majority of its wholesale volume, recognising that large retail partners have no near-term plans to retire EDIFACT infrastructure. The hybrid model has become the operational standard, with new partners onboarded via API by default unless they specifically request EDI.

What are the risks and limitations of each approach?

EDI's rigidity, its greatest strength, is also its principal limitation. Adding new data fields to accommodate emerging requirements such as carbon footprint per garment or blockchain traceability tokens requires updating the standard, gaining consensus among trading partners and revising implementation guides. This process can take years. In practice, companies work around the constraint by embedding custom data in free-text fields or by exchanging supplementary files outside the EDI flow, undermining the standardisation that EDI promises.

Version fragmentation plagues EDI implementations. Different retailers adopt different releases of the EDIFACT or X12 standards, and many customise the standard with proprietary code lists or field usage rules. A supplier may discover that the ORDERS message structure required by one retailer conflicts with another's, forcing the maintenance of multiple EDI profiles. The cost of this complexity grows with the number of trading partners, and errors in profile configuration can lead to rejected messages and order delays.

REST APIs face their own challenges. The absence of a universal standard means every API is a bespoke integration. Documentation quality varies widely, and some retailers fail to version their APIs or provide adequate deprecation notices when endpoints change. Suppliers have reported cases where breaking changes were deployed to production APIs without warning, halting order flows until emergency fixes could be coded and tested. The flexibility that makes APIs attractive also imposes an ongoing maintenance burden.

Security and authentication add friction to API integrations. OAuth flows, API keys and token refresh logic require careful implementation and monitoring. Misconfigured credentials can expose order data or allow unauthorised access. EDI over AS2 or through value-added networks benefits from decades of security hardening, whereas API security practices are still maturing in some corners of the fashion wholesale sector. Both approaches demand rigorous testing, but the attack surface differs.

Neither protocol solves data quality issues at source. Whether an order arrives as EDIFACT ORDERS or as JSON via REST API, errors in product codes, size mismatches or invalid delivery addresses will disrupt fulfilment. Integration technology can validate message syntax and enforce mandatory fields, but it cannot correct upstream problems such as incomplete product master data or misaligned size charts. Successful automation depends on clean, consistent reference data, a challenge that persists regardless of the transmission protocol.

How do compliance and audit requirements differ?

EDI comes with well-established audit trails. Value-added networks and AS2 gateways log every message sent and received, recording timestamps, message identifiers and delivery confirmations. These logs serve as proof of transmission in disputes over whether an order was acknowledged or a shipping notice was issued. Many EDI translation software packages archive raw messages and translated data, allowing companies to reconstruct the exact content of an ORDERS or DESADV message months or years later.

Regulatory and contractual compliance often hinges on these audit capabilities. Retailers may require suppliers to retain EDI messages for several years to support financial audits or investigations into product recalls. The structured nature of EDI messages simplifies automated compliance checks, because parsers can verify that mandatory fields are populated and that code values conform to agreed lists. Some industries mandate specific EDI standards for traceability, and fashion companies operating in those sectors inherit the same requirements for wholesale orders.

REST APIs require companies to build their own audit infrastructure. Standard web server logs capture HTTP requests and responses, but extracting business-meaningful audit trails, such as which purchase order was received at what time, demands additional tooling. API providers can include correlation identifiers and detailed response codes to aid troubleshooting, yet practices vary. Suppliers integrating with multiple retail APIs must implement consistent logging and monitoring across all connections, a task that grows more complex as partner counts rise.

Both approaches must address data privacy regulations. Fashion wholesale orders often contain personal data, such as delivery addresses for consumer orders fulfilled via dropship, and must comply with the General Data Protection Regulation in Europe or equivalent frameworks elsewhere. EDI and API integrations both require encryption in transit and controls on data retention. However, the distributed nature of API integrations, where data may pass through multiple cloud services and middleware layers, can complicate data lineage tracking and right-to-erasure requests.

How will wholesale integration evolve in the next two years?

The trajectory points towards greater standardisation within the API space and incremental extensions to EDI standards. Industry bodies are exploring JSON-based equivalents of EDI message types, aiming to combine the flexibility of REST APIs with the semantic consistency of EDIFACT. If widely adopted, such standards could reduce the bespoke integration burden that currently hampers API scalability. However, consensus-building in the fragmented fashion sector is slow, and voluntary standards often struggle to achieve critical mass.

Cloud-based integration platforms are likely to grow in adoption, particularly among mid-sized suppliers. These platforms offer pre-built connectors for common retail partners, translating between internal order formats and both EDI and API. As more retailers publish API specifications to platform marketplaces, the time and cost to add a new trading partner will fall. The platforms themselves may become de facto standards, shaping how data is structured even when the underlying protocol is REST.

Sustainability and traceability data will drive the next wave of integration changes. Regulations and consumer demand are pushing fashion companies to share information about materials, manufacturing locations and environmental impact. Neither legacy EDI messages nor most current wholesale APIs were designed to carry this data. Extensions to DESADV messages and custom API fields are emerging, but the lack of common taxonomies creates interoperability challenges. Companies that anticipate this shift and build flexible integration architectures will adapt more quickly than those locked into rigid mappings.

Real-time collaboration between brands and retailers is another frontier. Today's wholesale integrations are largely transactional, exchanging orders, confirmations and shipping notices after decisions are made. Future systems may integrate demand forecasting, dynamic pricing and collaborative inventory management, requiring richer, bidirectional data flows. APIs are better suited to this model than traditional EDI, but the business processes and trust frameworks needed to support deep collaboration remain underdeveloped in most wholesale relationships.

What should fashion companies do now?

1. Audit current trading partner requirements. Survey your largest retail accounts and wholesale partners to determine which protocols they mandate, which they prefer and which are optional. Document response-time expectations and any upcoming changes to their integration requirements.
2. Map internal data readiness. Assess whether your product master data, inventory systems and order management workflows can supply the fields required by both EDI messages and typical API requests. Identify gaps such as missing GTINs, inconsistent size codes or incomplete shipping data.
3. Calculate total cost of ownership. Model the five-year cost of EDI translation software, VAN fees, consulting and maintenance against the cost of in-house or contracted API development for your current and projected partner count. Include the opportunity cost of delayed go-lives.
4. Pilot both protocols with low-risk partners. If you currently support only one approach, test the alternative with a small retail account or a new wholesale channel. Use the pilot to uncover technical, process and support issues before committing to broader rollout.
5. Invest in integration middleware or platforms. Evaluate software that abstracts EDI and API differences behind a unified internal interface, reducing the burden on sales operations and customer service teams. Ensure the platform supports the specific message types and API patterns your partners use.
6. Establish monitoring and alerting. Implement automated checks for failed message transmissions, late acknowledgements and validation errors. Set thresholds that trigger alerts before partner service-level agreements are breached, allowing proactive resolution.
7. Plan for hybrid operations. Accept that most fashion companies will run both EDI and API integrations for the foreseeable future. Train support staff to troubleshoot both, maintain documentation for each partner's requirements and budget for ongoing updates as partners evolve their systems.