# Anwendungsfälle für die Commerce-API: sieben Builds, die mit einem Widget nicht gehen

> Wenn ein Shop-Widget nicht die richtige Form ist: Embedded Commerce in SaaS, Kataloge für mehrere Oberflächen, White-Label-Shops, eigene UX, KI-Agenten, eigenes BI. Dazu Codebeispiele aus dem Shoprocket-JS-SDK.

Ryan Badger - 4. August 2025 - 5 Min. Lesezeit

## Wofür eine Ecommerce-API zum Einbetten da ist

Die meisten Ecommerce-Plattformen geben dir ein Widget. Script einfügen, Shop bekommen. Funktioniert bei 95 % der Shops gut.

Eine Commerce-API greifst du dir, wenn du etwas tun willst, das ein Widget nicht kann: Produkte in deiner eigenen UI rendern, den Checkout in ein SaaS-Dashboard einbetten, einen Katalog über mehrere Oberflächen verteilen (Web + Mobile + Sprache) oder eigene Kaufabläufe bauen, die keine Plattform von Haus aus mitbringt.

Shoprocket liefert beides. Das [Widget](https://v3.shoprocket.io/de/blog/headless-commerce-drei-stufen-optionen-entscheidung.md) ist der Standard. Das [`@shoprocket/core`-SDK](https://github.com/shoprocket/shoprocket-js) ist für den Moment, in dem du dem Widget entwächst oder nie eins gebraucht hast.

## Anwendungsfälle, die eine API brauchen, kein Widget

Das sind die Builds, bei denen ein Widget nicht reicht. Steht deine Idee auf dieser Liste, bist du im API-Terrain.

### 1. Commerce in deinem SaaS-Produkt

Dein SaaS-Dashboard hat bereits eine eigene UI. Deine Kunden sollen Add-ons, Credit-Pakete, Premium-Stufen oder physischen Merch kaufen können, ohne deine App zu verlassen.

Ein Widget wäre die falsche Form: Es kennt deine Nutzer nicht, passt nicht zu deinem Design-System und geht von einem Shop auf einer ganzen Seite aus. Mit der API renderst du Produktkarten mit deinen eigenen Komponenten, rufst beim Klick `cart.addItem()` auf und blendest dein eigenes Checkout-Panel ein (oder leitest auf einen gehosteten Checkout weiter, wenn du den Compliance-Aufwand abgeben willst).

```
import { ShoprocketCore } from '@shoprocket/core'

const sr = new ShoprocketCore({ publicKey: 'pk_...' })

// Add-on-Kacheln im SaaS-Dashboard rendern
const addons = await sr.products.list({ category: 'addons' })

// Nutzer klickt auf den Button "Credits hinzufügen"
await sr.cart.addItem(addon.id, 1)
```

### 2. Katalog für mehrere Oberflächen (Web + native App + Sprache + Chat)

Ein Produktkatalog, an jedem Ort anders dargestellt. Der Web-Shop zeigt die vollen Produktdetails, die native iOS-App eine kompakte Liste, der Sprachassistent beschreibt Artikel laut, eine Chat-Integration antwortet mit einem kaufbaren Link.

Alle vier Oberflächen rufen dieselbe API auf. Änderst du den Preis eines Produkts im Shoprocket-Dashboard, zeigt ihn jede Oberfläche beim nächsten Abruf. Kein Inhaltsabgleich pro Oberfläche.

### 3. White-Label- und Partner-Shops

Du bist eine Plattform, auf der andere ihre Waren verkaufen: ein Community-Marktplatz, ein Partnerverzeichnis, ein Franchise-Netzwerk mit eigenen Händlerseiten. Jeder Partner hat ein Branding, das ihm gehört, nicht dir.

Die Seite jedes Partners läuft auf deinem Framework, ruft die Commerce-API aber mit seinem `publicKey` auf. Seine Produkte, seine Bestellungen, seine Auszahlungen, alles pro Konto getrennt. Kein Widget kommt seinem Branding in die Quere.

### 4. Komplett eigene Käufer-UX

Interaktive Produktkonfiguratoren (individuelle PC-Builds, personalisierter Schmuck, Möbel auf Bestellung). 3D-Produktansichten. "Shop the Room"-Fotogalerien, in denen ein Klick auf Pixel im Bild das Produkt in den Warenkorb legt. Schnell-Nachbestellen-Buttons direkt in der E-Mail.

Das Widget kann nichts davon. Die API schon. Du renderst, welche UI sich dein Designer auch ausgedacht hat; die API erledigt dahinter die Commerce-Mechanik.

### 5. KI-Agenten und Agentic Commerce

Ein KI-Agent (ChatGPT, Claude, ein eigener Agent), der Produkte durchsuchen und im Namen des Nutzers Käufe abschließen kann. Der Agent braucht programmatischen Zugriff auf deinen Katalog und Warenkorb, kein DOM-Widget, das er erst parsen muss.

Shoprocket liefert neben dem normalen API-Zugang auch Feeds für KI-Commerce-Protokolle. Fragt man einen Agenten "Was ist unter 50 $ mit Gratisversand auf Lager?", bekommt er eine strukturierte Antwort statt eines Screen-Scrapes.

### 6. Embedded Commerce in Content-Tools

Eine Notion-Seite, deren Blöcke kaufbar sind. Ein Framer-Design mit Klick-zum-Kauf-Hotspots. Ein Newsletter-Tool, in dem Abonnenten eine Produktkarte antippen und bezahlen, ohne die E-Mail zu verlassen. Alles auf einer API aufgebaut.

### 7. Eigene Reports und BI-Dashboards

Das Shoprocket-Dashboard zeigt Umsatz, Conversion und Top-Produkte. Was es nicht zeigt, sind *deine* eigenen Kennzahlen: Lifetime Value nach Kundenkohorte, Bestellungen pro Empfehlungsquelle, Marge nach Lieferantenkosten. Die API stellt Bestell- und Kundendaten bereit, damit du sie in dein eigenes BI-Tool, eine Tabelle oder ein internes Dashboard leiten kannst.

## Was das SDK dir heute bietet

Aus `@shoprocket/core`:

```
// Products
sr.products.list({ limit, offset, sort, category })
sr.products.get(productId)

// Cart
sr.cart.get()
sr.cart.addItem(productId, quantity)
sr.cart.updateItem(itemId, quantity)
sr.cart.removeItem(itemId)

// Session
sr.session.create()
sr.setSessionToken(token)
```

Dazu die komplette REST-API für alles, was das SDK noch nicht abdeckt (Bestellungen, Kunden, Rabatte, Produkte schreiben). Die vollständige Referenz findest du unter [api.shoprocket.io/docs](https://api.shoprocket.io/docs).

## Wo API-first ein Fehler ist

Ein paar Fälle, in denen das Widget die richtige Wahl und die API übertrieben ist:

- **Ein einfacher Shop mit 10-200 Produkten.** Das Widget rendert das perfekt; eine eigene Katalog-UI zu schreiben, heißt, gelöste Arbeit noch einmal zu machen.
- **Du hast keine eigene Frontend-Kapazität.** API-first heißt, eigene Ladezustände, Varianten-UI, Fehlerbehandlung, Barrierefreiheit und i18n für 21 Sprachen zu bauen und zu pflegen. Das sind Wochen Arbeit, die dir das Widget geschenkt mitgibt.
- **Dir geht es vor allem um Tempo beim Start.** Das Widget braucht Minuten; API-first mindestens Wochen.

Nimm standardmäßig das Widget. Greif zur API, wenn du auf etwas stößt, das das Widget nicht kann.

## Ein realistisches erstes Projekt

Das häufigste "Ich brauche die API"-Projekt: ein SaaS-Produkt, das Credits, Abos oder einmalige Add-ons direkt im eigenen Dashboard verkaufen will.

Vorgehen:

1. Installiere `@shoprocket/core` in deinem Frontend
2. Lege in Shoprocket eine Kategorie namens "Add-ons" oder ähnlich an
3. Füge Produkte mit genau den Preisen und Beschreibungen hinzu, die du willst
4. Rendere die Produktliste in deinem Dashboard mit deiner eigenen Komponentenbibliothek
5. Lege beim Klick in den Warenkorb und leite auf den gehosteten Checkout von Shoprocket weiter (oder bette den Checkout inline ein, wenn dir der Mehraufwand recht ist)
6. Richte einen Webhook-Endpunkt ein, der `order.paid`-Events empfängt, damit du freischalten kannst, was der Kauf bringt (Credits, Zugang, Versand)

Das war's. Eine Handvoll Dateien, ein Tag Arbeit für jemanden, der den Umgang mit APIs gewohnt ist. Kein Widget, kein iframe, kein Kompromiss bei der UI deines Produkts.

## Was wir nicht empfehlen

Baue keine komplette Katalog-UI nach, die dem sehr ähnelt, was das Widget schon kann. Wenn du Wochen mit einem "Produktraster mit Filtern und Suche" verbringst, schreibst du, was das Widget in Minuten mitbringt. Nimm das Widget für diese Form und die API für die wirklich anderen Formen.

> **Tipp:** Wenn du über API-first nachdenkst, weil das Standard-Styling des Widgets nicht zu deiner Marke passt, probier zuerst die [Styling-Hooks des Widgets](https://github.com/shoprocket/shoprocket-js). Das Widget lässt weit mehr CSS-Anpassung zu, als es aussieht. Ein kompletter Neubau über die API ist ein viel größerer Aufwand.

## Kurz gesagt

- **Widget** = Standard, deckt 95 % der Shops ab
- **API / SDK** = wenn das Widget nicht die richtige Form ist (Embedded Commerce in SaaS, mehrere Oberflächen, White-Label, eigene UX, KI-Agenten, eigenes BI)
- **Das SDK heute:** Produkte, Warenkorb, Sessions; dazu die komplette REST-API für Bestellungen / Kunden / Rabatte
- **Muster fürs erste Projekt:** SaaS-Dashboard verkauft Credits oder Add-ons per SDK + webhook-gesteuerte Freischaltung
- **Nicht per API nachbauen**, was das Widget schon gut kann; wähle deine Form

[Starte eine kostenlose Testphase](https://app-v3.shoprocket.io/signup) und hol dir einen Public Key; das SDK ist in jedem Shoprocket-Tarif kostenlos nutzbar. 14 Tage, keine Karte.

---

- HTML version: https://v3.shoprocket.io/de/blog/commerce-api-anwendungsfaelle-sieben-builds-ohne-widget
- Language: Deutsch (de)
- Also in: [العربية](https://v3.shoprocket.io/ar/blog/commerce-api-use-cases-seven-builds-you-cant-do-with-a-widget.md), [Ελληνικά](https://v3.shoprocket.io/el/blog/commerce-api-use-cases-seven-builds-you-cant-do-with-a-widget.md), [English](https://v3.shoprocket.io/blog/commerce-api-use-cases-seven-builds-you-cant-do-with-a-widget.md), [Español](https://v3.shoprocket.io/es/blog/casos-de-uso-api-de-comercio-siete-proyectos-que-un-widget-no-puede-hacer.md), [Français](https://v3.shoprocket.io/fr/blog/api-commerce-sept-cas-usage-impossibles-avec-un-widget.md), [עברית](https://v3.shoprocket.io/he/blog/commerce-api-use-cases-seven-builds-you-cant-do-with-a-widget.md), [हिन्दी](https://v3.shoprocket.io/hi/blog/commerce-api-use-cases-seven-builds-you-cant-do-with-a-widget.md), [Bahasa Indonesia](https://v3.shoprocket.io/id/blog/kasus-penggunaan-commerce-api-tujuh-hal-yang-tidak-bisa-dilakukan-widget.md), [Italiano](https://v3.shoprocket.io/it/blog/api-commerce-sette-casi-duso-che-un-widget-non-copre.md), [日本語](https://v3.shoprocket.io/ja/blog/commerce-api-use-cases-seven-builds-you-cant-do-with-a-widget.md), [Lietuvių](https://v3.shoprocket.io/lt/tinklarastis/prekybos-api-panaudojimo-atvejai-septyni-sprendimai-kuriu-nepadarysite-su-valdykle.md), [Norsk](https://v3.shoprocket.io/nb/blogg/handels-api-sju-ting-du-ikke-kan-bygge-med-en-widget.md), [Nederlands](https://v3.shoprocket.io/nl/blog/commerce-api-use-cases-zeven-projecten-zonder-widget.md), [Polski](https://v3.shoprocket.io/pl/blog/api-do-e-commerce-siedem-zastosowan-ktorych-nie-zrobisz-widzetem.md), [Português](https://v3.shoprocket.io/pt/blog/casos-de-uso-api-de-commerce-sete-projetos-que-widget-nao-faz.md), [Română](https://v3.shoprocket.io/ro/blog/cazuri-de-utilizare-api-comert-sapte-proiecte-fara-widget.md), [Русский](https://v3.shoprocket.io/ru/blog/commerce-api-use-cases-seven-builds-you-cant-do-with-a-widget.md), [ไทย](https://v3.shoprocket.io/th/blog/commerce-api-use-cases-seven-builds-you-cant-do-with-a-widget.md), [Türkçe](https://v3.shoprocket.io/tr/blog/commerce-api-kullanim-senaryolari-widget-ile-yapilamayan-yedi-proje.md), [中文](https://v3.shoprocket.io/zh/blog/commerce-api-use-cases-seven-builds-you-cant-do-with-a-widget.md)