Open Source Initiative
OpenReturn
An open protocol for the e-commerce return lifecycle.
A machine-readable standard any e-commerce platform, headless commerce tool, or AI agent can integrate with: free, open, and self-hostable.
What OpenReturn is
OpenReturn is an open standard that defines how e-commerce returns work programmatically. It covers the full return lifecycle: reason capture, exchange selection, carrier handoff, tracking, notification events, and multiple resolution types (refund, exchange, store credit, or forwarding to another consumer).
It is not a product you pay for. It is a specification anyone can implement, a reference portal anyone can host, and an MCP server that lets AI agents manage returns on behalf of consumers. Licensed Apache 2.0.
Protocol specification
Open standard with REST API. Full OpenAPI 3.1 spec. Discovery via /.well-known/openreturn or UCP capability advertisement.
MCP server
Wraps the REST API so AI agents can manage returns via the Model Context Protocol. OAuth 2.1 token delegation for the consumer-agent-retailer chain.
Reference portal
Self-hostable Next.js application. Full return and exchange flow. Transactional email included. WCAG 2.1 AA accessible. Open source.
Why this needs to exist
The current model is broken by design.
Commercial return portals operate as shipping label aggregators. They profit from each return shipment, which means their incentive is more returns, not fewer. They lock retailers into proprietary systems and treat return data as their asset, not the retailer's. The consumer experience is fragmented: a different portal for every retailer, no continuity, no portability.
There is no open standard.
There is no open standard for how returns work programmatically. Every platform reimplements the same flows independently. Headless commerce architectures have no clean interface to plug into. AI agents (which are rapidly becoming the primary way consumers manage tasks) have no protocol to follow when handling returns on someone's behalf. Every retailer is an island.
What OpenReturn changes.
OpenReturn gives retailers sovereignty over their return process and their data. It gives developers a stable interface to build on. It gives AI agents a protocol to follow across any store that implements the standard. And it treats exchanges (keeping a sale rather than losing it) as a first-class flow, not an afterthought. New return models, like customer-to-customer forwarding, can plug in via the extensible return method interface without changing the core protocol.
How OpenReturn relates to Forwarding
Forwarding (It Goes Forward's commercial product) is one implementation of a return method that runs on top of OpenReturn. It is not the only one. OpenReturn defines the protocol; Forwarding is a plug-in that implements the peer-to-peer return forwarding method through that protocol.
This is the same relationship as Vercel and Next.js, or Elastic and Elasticsearch: the infrastructure is open, the commercial product is built on top of it. We open-source the infrastructure because we believe the industry needs a shared standard, and because an open standard creates a larger ecosystem than a proprietary one.
If you want to use Forwarding, you do not need to implement OpenReturn separately; it is included. If you want to build something else on top of OpenReturn, you can do that independently.
Open standard (Apache 2.0)
OpenReturn Protocol
REST API + MCP server
Forwarding
IGF commercial product
Your return method / portal
Third-party implementations
Protocol coverage
Full return lifecycle
Reason capture, condition assessment, exchange selection, carrier handoff, tracking events, notification delivery, and resolution (refund, exchange, store credit, or forwarding).
Extensible return methods
Third-party return methods (like Forwarding) plug in via a defined interface. New resolution types can be added without changing the core protocol.
Dual discovery
Retailers advertise OpenReturn support via /.well-known/openreturn endpoint or UCP capability advertisement. AI agents can discover it programmatically.
AI agent support
MCP server wraps the REST API. OAuth 2.1 token delegation handles the consumer-agent-retailer permission chain. A2A Agent Card discovery is planned.
GDPR by design
No intermediary touches retailer or consumer data. Retailer-owned API keys throughout. Data minimisation framing for agent-mediated flows.
Self-hostable
Reference portal is a self-hostable Next.js application. No dependency on IGF infrastructure. Run it yourself or use IGF's hosted version.
Integrations
Carriers
- PostNL
- DHL
- UPS
- DPD
- Budbee
- + community adapters
Platforms
- Shopify
- WooCommerce
- Magento
- BigCommerce
- Headless (generic)
- ERP (Exact, SAP, Microsoft Dynamics)
Payments
- Stripe
- Generic adapter interface (Mollie, Adyen, etc.)
Planned (roadmap)
- Klaviyo(planned)
- Zendesk(planned)
- Freshdesk(planned)
- Gorgias(planned)
- InPost(planned)
- DHL Packstations(planned)
- Vinted(planned)
- Refurbed(planned)
- WMS integrations(planned)
- BORIS (return in store)(planned)
- Cross-border flows(planned)
- CO₂ reporting (CSRD)(planned)
- A2A Agent Card discovery(planned)
Governance
The OpenReturn protocol specification is governed through an open RFC process on GitHub. Any party can propose changes, challenge decisions, or contribute adapters. Governance is intended to move to The Commons Conservancy once the protocol reaches v1.0 stability, removing It Goes Forward as the sole steward and placing the standard under independent non-profit governance.
This is a deliberate design choice. A standard controlled by one commercial company is not a standard; it is a proprietary API with good documentation. For OpenReturn to fulfil its purpose, it must be governed independently.
RFC process on GitHub →Why It Goes Forward initiated this
There are two reasons.
The first is practical: the playbook works. Vercel open-sourced Next.js and built a hosting business on top of it. Elastic open-sourced the search engine and sells managed Elasticsearch. GitLab open-sources the platform and sells enterprise features. We open-source the return infrastructure and sell Forwarding, the peer-to-peer method that runs on top of it.
The second is genuine: we believe the industry needs a shared standard and we are in a position to build it. Every return portal re-implementing the same flows is waste. Every retailer locked into a proprietary system that controls their return data is an unnecessary constraint. If OpenReturn becomes the standard and IGF is the company that initiated it, that is a better position than being one of many proprietary return portal vendors.
Get involved
Implement it
The full protocol specification and reference implementation are on GitHub. Fork it, implement it, and open a PR with your adapter.
View on GitHub
Discuss it
Questions, proposals, and RFC discussions happen in GitHub Discussions. All protocol decisions are made in the open.
Join the discussion
Work with IGF
If you are a return portal, carrier, e-commerce platform, or agency interested in integrating OpenReturn or Forwarding, get in touch.
Contact us