How Zigzag Scales Connectors Without Scaling Engineering

Integrations in retail vary widely. Some teams rely on a solutions function to deliver one-off connections. Others treat an integration marketplace as a product surface where connectors can be self-served. In returns, integrations increasingly determine how quickly value shows up after go-live.

ZigZag Global positions returns as a connected post-purchase network, focused on carrier choice, workflow automation, and real-time insights. As retailers treat returns as a new journey rather than the end of one, the integration layer becomes central to implementation, data use, and expansion across retail stacks.

Why integrations matter more in returns than they used to

Returns used to be treated as a closed-loop endpoint. That model has shifted. Retailers now treat returns as one of the richest data events in commerce and expect that data to move into the rest of the stack.

Common outcomes retailers pursue from returns data include:

• Feeding product return learnings back into product improvement
• Enabling faster, more confident refunds
• Automating rules and dispositions across workflows

Retailers typically do not expect a returns platform to rebuild every downstream workflow as native features. The expectation is that the returns platform connects into existing systems and “meets” the retailer where the stack already is.

Where integration becomes a bottleneck in implementation

Getting returns live can be smooth, but value delivery often depends on what happens after onboarding, especially when returns data must sync into other systems.

Retailers frequently operate across many systems and can end up with siloed processes. When returns are isolated, inventory and financial data can drift, replenishment can be impacted, and refunds can be delayed. Integration becomes the mechanism that prevents those downstream issues.

Pre-built connectors vs existing iPaaS: what changes the conversation?

Many retailers already have an integration platform in place. The decision to use a returns provider’s integration stack becomes easier when pre-built connectors exist and events are standardised.

The practical differentiators described include:

• A blueprint model with plug-and-play readiness
• Time-to-value measured in hours rather than months
• Reduced friction in onboarding and post-onboarding workflows
• Higher trust in the system because the returns experience reaches end customers

Even organisations with large engineering teams still prefer reduced friction and a trusted integration path when the integration affects customer-facing flows.

Build vs buy: the decision is driven by maintenance and scalability

Engineering teams can write integration code, but the long-term burden includes:

• Maintenance drain on engineering resources
• Hosting and monitoring requirements
• Ongoing changes across a growing e-commerce stack

The buy/partner decision is framed around scalability and “self-heal” characteristics, avoiding a cycle of constant building plus constant maintenance. As retailer stacks grow, the maintenance burden grows with them unless the integration approach is designed to scale.

What “self-healing” means in practice for integrations

A platform approach reduces time, cost, and risk compared to traditional integration projects that can be slow, brittle, and expensive.

The Versori model includes four functional areas:

1. Research and planning
   • Technical architecture support between platforms
   • API documentation gathering
   • Data mapping and specifications
   • Technical best practices
2. Authentication handling
   • Detecting authentication methods (API keys, bearer tokens, basic auth)
   • Configuring authentication parameters
3. Code generation with a runtime SDK
   • Credential management
   • Key-value store
   • Server infrastructure
   • Pagination logic
   • API rate limits
4. Runtime monitoring
   • Real-time performance tracking
   • Continuous health monitoring
   • Alerts before issues become outages
   • Full logs for transparency

This shifts integration work away from repeated custom builds and toward monitored, repeatable deployments.

Case example: why the Brightpearl integration was prioritised

Brightpearl became a priority because multiple retailers entering the sales funnel wanted to connect returns into Brightpearl but lacked clarity on how to do it and what integrations were available.

Early use cases centred on keeping stock and financial data in sync to avoid mismatched inventory and the downstream impact of delayed credits or refunds.

A key workflow requirement was RMA triggers: once specific events occur in the returns flow, the integration can raise sales credits or provide a positive flag that a refund can proceed.

Beyond delivery, pre-built integrations also function as a sales tool, especially in enterprise contexts where a retailer is undertaking a transformation that affects customer experience.

The repeatability problem: “nobody wants the same integration”

A recurring constraint is that every retailer wants a variation. Early attempts to force repeatability without accepting variation led to mistakes.

The shift described is toward:

• Multi-tenanted, multi-threaded connections
• Reuse of boilerplate for authentication and common patterns
• Blueprint reuse with small changes to fit specific use cases
• Delivery without pulling work into a development queue

This enables implementation-level resources to handle work that previously required developer prioritisation.

Build once, deploy many: embedded integrations for multiple tenants

A core requirement is an integration that works across many end tenants while allowing per-tenant differences.

The model described supports:

• Separate credentials per tenant
• Per-tenant configuration and settings
• UI-based configuration variables
• Field mapping and data transformation
• Data structure adjustments (including date formats)
• Environment-specific settings such as tax rates and inventory location IDs

The result is a reusable connector where the core logic remains consistent, but each deployment can be customised without rebuilding from scratch.

2026 direction: a curated integration marketplace inside the retailer hub

The forward strategy described is to embed a curated integration marketplace inside new administration interfaces and returns portal releases.

The intended outcomes include:

• Retailers seeing available off-the-shelf integrations centrally
• Retailers self-serving integrations
• Retailers requesting additional integrations through the same hub

A recurring constraint is that the hardest part is often obtaining the right credentials, even when the connector exists.

Prioritisation and ownership: what stays in-house vs what goes to a partner

A clear split is described:

• Carrier integrations are built and maintained in-house, supported by an existing carrier integration library.
• Post-purchase and post-returns integrations into external systems are routed through a partner workflow to assess feasibility and align on what the retailer wants versus what is possible.

Prioritisation is managed through a defined connector roadmap (roughly 10–15 on top of what exists, with a broader top set of 15–20 targeted in a year), driven by:

• Retention needs for current clients
• Acquisition needs based on what new retailers require
• Complexity and flow analysis once requirements are understood

Human-in-the-loop remains necessary

Automation and tooling reduce the number of people required to deliver integrations at quality and at speed, but the process still benefits from human involvement.

The human contribution described includes:

• Building trust during implementation
• Business analysis to understand what a retailer needs
• Context-aware troubleshooting when errors occur

Errors are often context-driven rather than purely technical, making human understanding important even as tooling improves.

Monetising integrations: when fees make sense

A chargeable model is described as viable, but not universal.

• Basic connectors are often expected as part of the base need, with no extra payment.
• More complex work at scale can support fees, including:
  • Implementation fees
  • Monthly fees to cover volume through platforms
  • Transactional pricing models

Retailer expectations remain high for keeping systems in sync regardless of data quality or stack complexity, but there is openness to paying for complex integration work when the effort is clear.