Open-Source-Initiative

OpenReturn

Ein offenes Protokoll für den E-Commerce-Retouren-Lebenszyklus.

Ein maschinenlesbarer Standard, in den jede E-Commerce-Plattform, jedes Headless-Commerce-Tool oder jeder KI-Agent integriert werden kann: kostenlos, offen und selbst-hostbar.

Apache 2.0REST API + MCPIn Entwicklung

Auf GitHub ansehen →openreturn.io ↗

Was OpenReturn ist

OpenReturn ist ein offener Standard, der definiert, wie E-Commerce-Retouren programmatisch funktionieren. Er deckt den gesamten Retouren-Lebenszyklus ab: Gründeerfassung, Umtauschauswahl, Paketdienstübergabe, Tracking, Benachrichtigungsereignisse und mehrere Lösungstypen (Rückerstattung, Umtausch, Gutschrift oder Weiterleitung an einen anderen Verbraucher).

Es ist kein Produkt, für das man zahlt. Es ist eine Spezifikation, die jeder implementieren kann, ein Referenzportal, das jeder hosten kann, und ein MCP-Server, der es KI-Agenten ermöglicht, Retouren im Namen von Verbrauchern zu verwalten. Lizenziert unter Apache 2.0.

Protokoll-Spezifikation

Offener Standard mit REST API. Vollständige OpenAPI-3.1-Spezifikation. Discovery über /.well-known/openreturn oder UCP-Capability-Advertisement.

MCP-Server

Umhüllt die REST API, sodass KI-Agenten Retouren über das Model Context Protocol verwalten können. OAuth-2.1-Token-Delegation für die Kette Verbraucher-Agent-Händler.

Referenzportal

Selbst-hostbare Next.js-Anwendung. Vollständiger Retouren- und Umtauschprozess. Transaktionale E-Mail enthalten. WCAG 2.1 AA zugänglich. Open Source.

Warum das existieren muss

Das aktuelle Modell ist von Natur aus defekt.

Kommerzielle Retourenportale arbeiten als Versandetiketten-Aggregatoren. Sie profitieren von jeder Retourensendung, was bedeutet, dass ihr Anreiz mehr Retouren sind, nicht weniger. Sie sperren Händler in proprietäre Systeme ein und behandeln Retourendaten als ihr Eigentum, nicht das des Händlers. Das Verbrauchererlebnis ist fragmentiert: ein anderes Portal pro Händler, keine Kontinuität, keine Portabilität.

Es gibt keinen offenen Standard.

Es gibt keinen offenen Standard dafür, wie Retouren programmatisch funktionieren. Jede Plattform implementiert die gleichen Abläufe unabhängig voneinander neu. Headless-Commerce-Architekturen haben keine saubere Schnittstelle zum Anschluss. KI-Agenten (die schnell zur primären Art werden, wie Verbraucher Aufgaben verwalten) haben kein Protokoll, dem sie folgen können, wenn sie Retouren im Namen von jemandem bearbeiten. Jeder Händler ist eine Insel.

Was OpenReturn verändert.

OpenReturn gibt Händlern Souveränität über ihren Retourenprozess und ihre Daten. Es gibt Entwicklern eine stabile Schnittstelle zum Aufbau. Es gibt KI-Agenten ein Protokoll, dem sie in jedem Shop folgen können, der den Standard implementiert. Und es behandelt Umtäusche (einen Verkauf zu behalten statt zu verlieren) als First-Class-Flow, nicht als Nebensache. Neue Retourenmodelle, wie Customer-to-Customer-Forwarding, können über die erweiterbare Retourenmethoden-Schnittstelle eingesteckt werden, ohne das Kernprotokoll zu ändern.

Wie sich OpenReturn zu Forwarding verhält

Forwarding (das kommerzielle Produkt von It Goes Forward) ist eine Implementierung einer Retourenmethode, die auf OpenReturn läuft. Es ist nicht die einzige. OpenReturn definiert das Protokoll; Forwarding ist ein Plug-in, das die Peer-to-Peer-Retourenmethode über dieses Protokoll implementiert.

Das ist die gleiche Beziehung wie Vercel und Next.js oder Elastic und Elasticsearch: Die Infrastruktur ist offen, das kommerzielle Produkt ist darauf aufgebaut. Wir veröffentlichen die Infrastruktur als Open Source, weil wir glauben, dass die Branche einen gemeinsamen Standard braucht, und weil ein offener Standard ein größeres Ökosystem schafft als ein proprietärer.

Wenn Sie Forwarding nutzen möchten, müssen Sie OpenReturn nicht separat implementieren; es ist enthalten. Wenn Sie etwas anderes auf OpenReturn aufbauen möchten, können Sie das unabhängig tun.

Offener Standard (Apache 2.0)

OpenReturn-Protokoll

REST API + MCP-Server

Forwarding

IGF kommerzielles Produkt

Ihre Retourenmethode / Portal

Drittanbieter-Implementierungen

Protokoll-Abdeckung

Vollständiger Retouren-Lebenszyklus

Gründeerfassung, Zustandsbewertung, Umtauschauswahl, Paketdienstübergabe, Tracking-Events, Benachrichtigungszustellung und Auflösung: Rückerstattung, Umtausch, Gutschrift oder Forwarding.

Erweiterbare Retourenmethoden

Drittanbieter-Retourenmethoden (wie Forwarding) werden über eine definierte Schnittstelle eingesteckt. Neue Auflösungstypen können hinzugefügt werden, ohne das Kernprotokoll zu ändern.

Duale Discovery

Händler bewerben OpenReturn-Unterstützung über den /.well-known/openreturn-Endpunkt oder UCP-Capability-Advertisement. KI-Agenten können es programmatisch entdecken.

KI-Agent-Unterstützung

MCP-Server umhüllt die REST API. OAuth-2.1-Token-Delegation regelt die Berechtigungskette Verbraucher-Agent-Händler. A2A Agent Card Discovery ist geplant.

DSGVO by Design

Kein Vermittler berührt Händler- oder Verbraucherdaten. Händlereigene API-Schlüssel durchgängig. Datenminimierungs-Framing für agent-vermittelte Flows.

Selbst-hostbar

Referenzportal ist eine selbst-hostbare Next.js-Anwendung. Keine Abhängigkeit von IGF-Infrastruktur. Selbst hosten oder die gehostete Version von IGF nutzen.

Aufgebaut auf offenen Standards

UCP

Universal Capability Protocol: Capability-Advertisement und Discovery

ucp.dev

MCP

Model Context Protocol: KI-Agent-Integration

modelcontextprotocol.io

OpenAPI

OpenAPI 3.1: REST-API-Spezifikation

spec.openapis.org/oas/latest.html

Integrationen

Paketdienste

PostNL
DHL
UPS
DPD
Budbee
+ Community-Adapter

Plattformen

Shopify
WooCommerce
Magento
BigCommerce
Headless (generisch)
ERP (Exact, SAP, Microsoft Dynamics)

Zahlungen

Stripe
Generische Adapter-Schnittstelle (Mollie, Adyen, etc.)

Geplant (Roadmap)

Klaviyo(geplant)
Zendesk(geplant)
Freshdesk(geplant)
Gorgias(geplant)
InPost(geplant)
DHL Packstations(geplant)
Vinted(geplant)
Refurbed(geplant)
WMS-Integrationen(geplant)
BORIS (Retoure im Laden)(geplant)
Grenzüberschreitende Flows(geplant)
CO₂-Reporting (CSRD)(geplant)
A2A Agent Card Discovery(geplant)

Governance

Die OpenReturn-Protokollspezifikation wird über einen offenen RFC-Prozess auf GitHub verwaltet. Jede Partei kann Änderungen vorschlagen, Entscheidungen anfechten oder Adapter beitragen. Die Governance soll zu The Commons Conservancy übergehen, sobald das Protokoll die v1.0-Stabilität erreicht: Dadurch wird It Goes Forward als alleiniger Verwalter entfernt und der Standard unter unabhängige Non-Profit-Governance gestellt.

Dies ist eine bewusste Designentscheidung. Ein von einem einzigen kommerziellen Unternehmen kontrollierter Standard ist kein Standard, sondern eine proprietäre API mit guter Dokumentation. Damit OpenReturn seinen Zweck erfüllen kann, muss es unabhängig verwaltet werden.

RFC-Prozess auf GitHub →

Warum It Goes Forward dies initiiert hat

Es gibt zwei Gründe.

Der erste ist praktisch: Das Drehbuch funktioniert. Vercel hat Next.js als Open Source veröffentlicht und darauf aufbauend ein Hosting-Geschäft aufgebaut. Elastic hat die Suchmaschine als Open Source veröffentlicht und verkauft Managed Elasticsearch. GitLab veröffentlicht die Plattform als Open Source und verkauft Enterprise-Funktionen. Wir veröffentlichen die Retoureninfrastruktur als Open Source und verkaufen Forwarding, die Peer-to-Peer-Methode, die darauf läuft.

Der zweite ist ehrlich: Wir glauben, dass die Branche einen gemeinsamen Standard braucht und wir sind in der Position, ihn zu bauen. Jedes Retourenportal, das die gleichen Flows neu implementiert, ist Verschwendung. Jeder Händler, der in einem proprietären System eingesperrt ist, das seine Retourendaten kontrolliert, ist eine unnötige Einschränkung. Wenn OpenReturn zum Standard wird und IGF das Unternehmen ist, das ihn initiiert hat, ist das eine bessere Position, als einer von vielen proprietären Retourenportal-Anbietern zu sein.