---
title: "Natives Shopify B2B, Angebots-App, Eigenentwicklung oder CPQ: ein Entscheidungsleitfaden"
description: "Kein Sieger, nur Passung: 18 Anforderungen und fünf Fragen für die Wahl zwischen nativem Shopify B2B, Angebots-App, Eigenentwicklung und CPQ."
url: "https://www.quotway.com/de/blog/shopify-b2b-native-vs-quote-app-vs-custom-vs-cpq"
type: "blog post"
category: "For Shopify agencies"
published: "2026-09-20"
verified: "2026-09-20"
shopify_api_version: "2026-07"
audience: "Shopify-Agenturen und Solution Architects, die einen B2B-Angebotsstack empfehlen"
scope: "Die vier Wege, B2B-Angebote auf Shopify zu betreiben, bewertet nach Anforderung, mit den Bedingungen, unter denen jeder passt"
locale: "de"
source: "QuotWay - B2B Quote & Negotiation App for Shopify"
---

# Natives Shopify B2B, Angebots-App, Eigenentwicklung oder CPQ: ein Entscheidungsleitfaden

Unter den vier Wegen, B2B-Angebote auf Shopify zu betreiben, gibt es keinen Sieger, nur Passung.

Natives Shopify B2B passt, wenn Preise feststehen und der Käufer dagegen bestellt. Eine Angebots-App passt, wenn der Preis pro Geschäft für Standardprodukte entschieden wird und das Geschäft mit seiner Historie zu einer Shopify-Bestellung werden muss. Eine Eigenentwicklung passt, wenn der Workflow selbst das Produkt ist und der Händler Entwickler hat, die so lange mit Shopifys vierteljährlichen API-Releases Schritt halten, wie der Shop existiert. CPQ passt, wenn das Produkt aus Regeln konfiguriert wird und das Vertriebsteam bereits in einer CRM-Opportunity lebt. Die meisten B2B-Shops landen bei nativem B2B für Standardpreise plus einer der anderen drei Optionen für die Ausnahmen; der Fehler ist, zwei zu wählen, die beide die Preise besitzen wollen.

Dieser Leitfaden richtet sich an die Agentur oder den Architekten, der eine Empfehlung abgeben muss. Er definiert die vier Optionen, bewertet sie gegen achtzehn Anforderungen und gibt einen Entscheidungsbaum mit fünf Fragen. Der [Beitrag zur Architektur](/blog/shopify-b2b-quote-architecture) erklärt, warum die Eigentümerregel zählt; [wann Sie keine Angebots-App brauchen](/blog/when-not-to-use-a-shopify-quote-app) ist die lange Fassung des nativen Blatts; die [Bewertungs-Checkliste](/blog/shopify-b2b-app-evaluation-checklist) ist das, was Sie gegen jede App oder jeden Eigenbau in der engeren Wahl laufen lassen, und der [Testplan für den Start](/blog/shopify-b2b-launch-test-plan) das, was vor dem Livegang der gewählten Option durchlaufen wird.

## Die vier Optionen, definiert

**Natives Shopify B2B.** Unternehmen, Unternehmensstandorte und Kontakte; Kataloge mit Preislisten, Mengenregeln und Mengenpreisen; Zahlungsziele, hinterlegte Karten und Bestellnummern im Checkout; „Zur Genehmigung einreichen“, um aus einem Checkout einen Bestellentwurf zu machen; eigene Preise, gesperrte Preise und reservierter Bestand auf diesem Entwurf; Anzahlungen und Teilzahlungen auf Plus. Seit dem 2. April 2026 in jedem Tarif. Es hat kein Objekt für eine Preisanfrage, ein Angebot, ein Gegenangebot, eine Freigabe oder eine Verhandlungshistorie. Was Sie betreiben: Shopify.

**Eine Angebots-App.** Eine öffentliche App, die Anfrage, Angebotsversionen, Gegenangebote, Freigaben und Prüfprotokoll auf die nativen Objekte setzt, den Katalogpreis des Käufers als Ausgangspunkt liest und den Bestellentwurf anlegt, wenn der Preis vereinbart ist. Vom Händler installiert und entfernt; der Anbieter trägt API-Upgrades, Compliance-Webhooks und Shop-Extensions. Was Sie betreiben: ein Abonnement und die Roadmap des Anbieters.

**Eine Eigenentwicklung.** Dieselbe Angebotsebene, für einen Händler geschrieben, als Custom App auf der Admin API mit eigener Datenbank, Theme App Extension, Customer Account Extension und Webhooks. Jedes Verhalten kann genau so sein, wie der Händler es will. Was Sie betreiben: eine Anwendung, so lange der Shop handelt – die Pflichten stehen unten, und sie werden nach dem Livegang nicht kleiner.

**CPQ.** Configure-Price-Quote-Software, von einem Anbieter definiert als „Software, die Vertriebsteams hilft, Produkte zu konfigurieren, Preisregeln anzuwenden, Rabatte und Freigaben zu verwalten und korrekte Angebote zu erstellen“ – Produktkonfiguration aus Regeln, Preisgovernance, geführter Verkauf, Freigaben, Dokumente und Verträge, üblicherweise aus einer CRM-Opportunity heraus erstellt. Shopify ist nicht ihr Zuhause: Shop, Kundenkonto und Bestellentwurf sind eine Integration, die ein CPQ-Projekt bauen oder kaufen muss. Was Sie betreiben: eine Plattform pro Nutzer und ihre Integration.

## Die Passungsmatrix

Die Passung ist so bewertet, wie ein B2B-Shop auf Shopify die Anforderung erfüllt, nicht abstrakt. „Teilweise“ heißt: Die Option kann es mit einem Umweg oder einem zweiten Werkzeug.

| Anforderung | Natives B2B | Angebots-App | Eigenentwicklung | CPQ |
| --- | --- | --- | --- | --- |
| Preislisten je Unternehmen, je Standort | Ja – Kataloge | Liest sie; besitzt sie nie | Liest sie; besitzt sie nie | Teilweise – eigenes Preisbuch, in Kataloge synchronisiert |
| Mengenstaffeln | Ja – bis zu 10 Staffeln je Produkt | Liest sie | Liest sie | Ja – eigene Regeln |
| Käufer bestellt und zahlt auf Ziel | Ja | Ja – über den umgewandelten Bestellentwurf | Ja – über den Bestellentwurf, den Sie anlegen | Teilweise – die Bestellerfassung ist die Integration |
| Eine Prüfrunde vor der Bestellung | Ja – zur Genehmigung einreichen | Ja | Ja | Teilweise |
| Preisanfrage eines Gastes | Nein – Preise brauchen einen Unternehmenskontakt | Ja | Ja | Nein – Angebote starten aus einem CRM-Datensatz |
| Geschäftsspezifischer, verhandelter Preis | Kein Objekt | Ja | Ja | Ja |
| Gegenangebot des Käufers | Nein | Ja | Ja | Teilweise – meist vom Vertriebler getrieben |
| Durchgesetzte Freigabe eines Rabatts | Nein – Mitarbeiterberechtigungen regeln Konten, nicht Preise | Ja | Ja, wenn Sie die Durchsetzung bauen | Ja |
| Freie Positionen oder Dienstleistungen mit eigenem Steuer- und Versandkennzeichen | Ja – auf einem Bestellentwurf, von Hand | Ja | Ja | Ja |
| Produkt aus Optionen und Regeln konfiguriert | Nein | Nein – hält eine freie Position, berechnet sie nicht | Möglich | Ja – dafür ist CPQ da |
| Komplexes Konstruktionsprodukt, stücklistengetrieben | Nein | Nein | Möglich, zu echten Kosten | Ja |
| Fracht pro Geschäft bepreist | Bestellentwurf, von Hand | Ja | Ja | Ja |
| Präsentation in mehreren Währungen | Ja – Markets | Ja, wenn die App in der Präsentationswährung anbietet | Ja, wenn gebaut | Teilweise – CPQ-Währung gegenüber Shopify-Währung |
| Anzahlung auf der Bestellung | Auf Plus | Auf Plus, über den Bestellentwurf | Auf Plus | Auf Plus, sobald sie Shopify erreicht |
| Angebot im Kundenkonto | Nur Bestellentwürfe | Customer Account UI Extension | Customer Account UI Extension | Nein – CPQ-Portale sind eigene |
| ERP besitzt die Preise | Sync in Kataloge | Liest Kataloge | Liest Kataloge | Eigener Sync ins CPQ und in Kataloge |
| Angebot aus einer CRM-Opportunity erstellt | Nein | Teilweise – Ereignisse über Flow | Möglich | Ja – nativ |
| Zeit bis zum ersten Angebot | Stunden | Tage | Monate | Monate |
| Laufender Entwicklungsaufwand | Keiner | Beim Anbieter | Bei Ihnen | Beim Anbieter, plus Ihre Integration |
| Dateneigentum und Ausstieg | Shopify | Shopify + Export | Bei Ihnen | Anbieter + Shopify |

Lesen Sie die Spalten, nicht die Zeilen. Nativ hat die meisten „Ja“-Zellen für einen Shop, der nie verhandelt, und die meisten „Nein“-Zellen, sobald er es tut. Angebots-App und Eigenentwicklung haben dieselbe Spaltenform; der Unterschied ist, wer sie betreibt. Die CPQ-Spalte ist genau dort am stärksten, wo die anderen am schwächsten sind – Konfiguration und CRM – und dort am schwächsten, wo sie am stärksten sind – Shopify-Shop und Bestellung.

> **Entscheidungsbaum: nativ, Angebots-App, Eigenentwicklung oder CPQ**
>
> Fünf Fragen in Folge. Eins: Steht der Preis fest, bevor der Käufer fragt? Ja führt zu nativem Shopify B2B. Nein führt zu Frage zwei: Wird der Preis aus Produktoptionen und Regeln berechnet? Ja führt zu Frage drei: Bieten Vertriebler aus einer CRM-Opportunity an? Ja führt zu CPQ; Nein führt zu Konfigurator plus Angebots-App oder Eigenentwicklung. Von Frage zwei führt Nein zu Frage vier: Gibt es einen Workflow, den keine App abbildet, plus Entwickler, die eine App über Jahre betreiben? Ja führt zur Eigenentwicklung; Nein zur Angebots-App. Hinweis unter dem Baum: Die meisten Shops kombinieren natives B2B für Standardpreise mit genau einer weiteren Option für Ausnahmen.
>
> Fünf Fragen, vier Blätter. Der Baum ist die Kurzform der Abschnitte unten.

## Natives Shopify B2B: wann es reicht

Nativ ist die Antwort, wenn Frage 1 für jeden Käufer und jede Bestellung ja lautet: Der Preis steht im Katalog des Standorts, bevor jemand fragt, Staffeln sind Mengenrabatte, die für alle auf diesem Katalog gelten, und die einzige Prüfung, die der Händler will, ist ein Blick auf den Bestellentwurf, bevor er eine Bestellung wird. Seit dem 2. April 2026 gibt es das auf Basic, Grow und Advanced; Plus ergänzt unbegrenzte Kataloge, die direkte Katalogzuweisung an ein Unternehmen oder einen Standort, Anzahlungen und Teilzahlungen. Die acht Situationen, die nativ abdeckt, jede der Funktion zugeordnet, die sie abdeckt, stehen in [wann Sie keine Shopify-Angebots-App verwenden sollten](/blog/when-not-to-use-a-shopify-quote-app).

Nativ hört bei der ersten Antwort auf zu reichen. Ein Bestellentwurf kann einen eigenen Preis tragen, hat aber keinen Zustand für „der Käufer will weniger“, keine Version, keine Freigabe und keinen Beleg für den Austausch. Händler, die Verhandlungen über Bestellentwürfe abwickeln wollen, landen bei der Konversation in der E-Mail und einem veralteten Bestellentwurf – und das ist der Punkt, an dem eine der drei anderen Optionen gewählt wird, ob es jemand ausspricht oder nicht.

## Eine Angebots-App: wann sie passt

Eine Angebots-App passt, wenn der Preis pro Geschäft für Produkte entschieden wird, die Shopify bereits kennt: Der Käufer fragt, der Verkäufer bietet vom Katalogpreis aus an, eine oder beide Seiten bewegen sich, jemand gibt den Rabatt frei, und die angenommene Version wird zu einem Bestellentwurf zu den vereinbarten Preisen. Sie passt auch für den Käufer, den nativ nicht bedienen kann – den Gast, der eine Zahl will, bevor er ein Unternehmenskonto hat.

Die Bedingungen, die sie gegenüber einer Eigenentwicklung zur richtigen Wahl machen, sind praktischer Natur. Der Workflow, den der Händler braucht, ist der, den die App abbildet; der Händler hat kein Entwicklerteam oder eines mit Besserem zu tun, als Shopifys vierteljährliche API-Releases zu verfolgen; die Zeit bis zum ersten Angebot zählt; und die App besteht die [Bewertungs-Checkliste](/blog/shopify-b2b-app-evaluation-checklist) – vor allem die Fragen zur nativen Passung, denn eine App, die eine eigene Preisliste führt, hat das Problem nachgebaut, für dessen Lösung sie gekauft wurde. Was es kostet, sind das Abonnement und die Abhängigkeit von der Roadmap des Anbieters: Ein Verhalten, das die App nicht abbildet, ist ein Feature-Wunsch, kein Ticket.

QuotWay ist eine solche App und das Beispiel, für das diese Website sprechen kann: Ihr [unternehmensbezogenes Angebot](/features/b2b) startet ein Angebot vom Katalogpreis des Unternehmensstandorts, versioniert jedes Angebot und jedes Gegenangebot, setzt Freigaben auf dem Server durch und wandelt die angenommenen Positionen in einen nativen Bestellentwurf mit den Zahlungszielen des Standorts um; der [Lite-Tarif](/pricing) fährt diesen ganzen Kreislauf kostenlos mit zehn Angeboten im Monat, was ein günstigerer Weg ist, herauszufinden, ob ein Shop Angebotsvolumen hat, als jede der anderen drei Spalten. Gehen Sie die Checkliste dagegen so durch wie gegen jede andere App.

## Eine Eigenentwicklung: wann sie gerechtfertigt ist, und was sie am Laufen halten muss

Eine Eigenentwicklung ist gerechtfertigt, wenn beide Hälften von Frage 4 zutreffen: Es gibt einen Workflow, den keine App abbildet – eine Beschaffungsregel, ein Branchendokument, eine Preisverhandlung, die der Logik eines Vertrags folgt –, und der Händler finanziert Entwickler, die eine Anwendung so lange betreiben, wie der Shop handelt. Die erste Hälfte ist häufiger als die zweite, und Agenturen werden meist nur gebeten, die erste zu kalkulieren.

Was eine eigene Angebotsebene auf Shopify am Laufen halten muss, nach Shopifys eigenen Pflichtenseiten:

- Eine Admin-API-Version, aktualisiert im Quartalstakt von Shopify. Jede Version wird mindestens 12 Monate unterstützt; eine Anfrage an eine nicht unterstützte Version „fällt vorwärts“ – ohne Hinweis – auf die älteste unterstützte, und so bricht ein Aufbau, den niemand angefasst hat, im dreizehnten Monat. Neue Apps sind nur GraphQL; die REST Admin API ist seit dem 1. Oktober 2024 Legacy.
- Die drei Compliance-Webhooks – `customers/data_request`, `customers/redact`, `shop/redact` – und die Schutzmaßnahmen für geschützte Kundendaten für jeden Namen, jede E-Mail, Adresse oder Telefonnummer, die der Aufbau speichert. Eine Custom App wird für diesen Zugriff nicht wie eine öffentliche App geprüft, die Anforderungen sind aber dieselben.
- Webhook-Verarbeitung, die Shopifys Zustellmodell übersteht: verifizierte Signaturen, Duplikate über `X-Shopify-Webhook-Id` ignoriert, Wiederholungen (8 über 4 Stunden, dann wird das Abonnement gelöscht) und ein Abgleichsjob, weil die Zustellung „nicht immer garantiert ist“.
- Ratenlimit-bewusste API-Nutzung: 100 Punkte pro Sekunde auf Standard, 200 auf Advanced, 1.000 auf Plus, mit einer Obergrenze von 1.000 Punkten je Abfrage.
- Eine Theme App Extension für den Shop und eine Customer Account UI Extension für das Konto des Käufers, jede mit eigenen Größengrenzen und eigenem Upgrade-Pfad; ein Headless-Shop braucht einen dritten Pfad.
- Eine idempotente Umwandlung in den Bestellentwurf, mit dem verhandelten Preis auf jeder Position als `priceOverride`, dem Unternehmen als `purchasingEntity` und Abweichungsprüfungen gegen `draftOrderCalculate`.
- Wenn Checkout-Verhalten Teil des Workflows ist – eine Regel zur Bestellnummer, eine Validierung –, Shopify Functions; und „nur Shops im Shopify-Plus-Tarif können Custom Apps verwenden, die Shopify-Function-APIs enthalten“.

Zwei Abkürzungen sehen aus wie Eigenentwicklungen und sind keine. Das Angebot als Metaobjekte zu modellieren gibt Ihnen einen eigenen Datensatztyp im Admin und in der Storefront API, aber einen Datensatz, keinen Workflow: keine Zustände, keine Versionen, keine Freigaben, keine Durchsetzung. Und ein Aufbau aus Flow und Bestellentwürfen – Flow-Automatisierungen, die einen Bestellentwurf über Tags weiterschieben – ist eine Prüfrunde mit Zusatzschritten und endet bei derselben Antwort, bei der nativ endet.

Eine Eigenentwicklung ist nicht mehr gerechtfertigt, wenn sich der Workflow, für den sie gebaut wurde, als der herausstellt, den jede Angebots-App abbildet. Das passiert öfter als das Gegenteil, und es lohnt sich, vor dem Bau zu fragen, nicht danach; der [Beitrag zur Architektur](/blog/shopify-b2b-quote-architecture) ist die Spezifikation, die beide Wege erfüllen sollten, und die [Bewertungs-Checkliste](/blog/shopify-b2b-app-evaluation-checklist) der Test, ob eine bestehende App sie bereits erfüllt.

## CPQ: wann es gerechtfertigt ist, und wann es zu viel ist

CPQ ist gerechtfertigt, wenn Frage 2 ja lautet und Frage 3 ja lautet: Der Preis entsteht aus Produktkonfigurationsregeln statt aus einem Gespräch, und die Menschen, die anbieten, arbeiten aus CRM-Opportunities heraus, mit Verträgen, Verlängerungen und geführtem Verkauf drumherum. In dieser Welt ist Shopify die Oberfläche für Bestellerfassung und Fulfillment, das CPQ die Angebotsoberfläche, und die Integration dazwischen – konfiguriertes Produkt zu Shopify-Position, CPQ-Angebot zu Bestellentwurf, Shopify-Bestellung zurück zur Opportunity – ist ein eigenes Projekt, das das CPQ nicht mitliefert.

Volles CPQ ist zu viel für den Shop, dessen Produkte Standard sind, dessen Preise verhandelt statt berechnet werden und dessen Vertriebler in Shopify statt in einem CRM leben. Das sind die meisten Shopify-B2B-Shops. Das Erkennungsmerkmal sind die Konfigurationsregeln: Wenn die Positionen eines Angebots Varianten zu verhandelten Preisen plus gelegentlich eine freie Position sind, gibt es für einen Konfigurator nichts zu konfigurieren, und der Shop zahlt pro Nutzer für die zwei Komponenten, die er braucht – Freigaben und Dokumente –, verpackt mit mehreren, die er nicht braucht. Der [Beitrag zu Shopify CPQ](/blog/shopify-cpq) trennt die beiden Aufgaben; [QuotWay im Vergleich zu Enterprise-CPQ](/compare/vs-enterprise-cpq) ist der Direktvergleich für einen Shop, der zwischen beiden wählt.

Der mittlere Fall – konfigurierte Produkte, kein CRM – ist das gestrichelte Blatt im Baum: Ein Werkzeug für Produktoptionen berechnet den konfigurierten Preis, und eine Angebotsebene (App oder Eigenbau) verhandelt und wandelt ihn um. Es sind zwei Werkzeuge, weil es zwei Aufgaben sind.

## Kombinationen

Jede Kombination, die funktioniert, hat einen Eigentümer des Standardpreises, und das ist Shopifys Katalog.

- Nativ plus Angebots-App: der Standard für einen Shop mit Standardpreisen und verhandelten Ausnahmen. Kataloge bepreisen den Shop und die Nachbestellungen; die App bietet vom Katalogpreis aus an und gibt einen Bestellentwurf zurück.
- Nativ plus Eigenentwicklung: dieselbe Form, für den Shop, dessen Ausnahmen Regeln folgen, die keine App hat.
- Nativ plus CPQ: CPQ besitzt Konfiguration und das CRM-seitige Angebot; das ERP oder CPQ synchronisiert Standardpreise in Kataloge; Shopify erfasst die Bestellung. Das Angebot selbst lebt nicht im Kundenkonto, es sei denn, jemand baut das.
- Die Kombination, die scheitert: zwei beliebige Optionen, die beide eine Preisliste führen. Eine Angebots-App mit eigenen Preisen neben Katalogen oder ein CPQ-Preisbuch und Kataloge, beide von Hand gepflegt, liefern innerhalb von Wochen zwei Zahlen für einen Käufer.

## Häufige Fragen

### Kann Shopify B2B verhandelte Preise ohne App abbilden?

Für eine Runde ja: Stellen Sie den Standort so ein, dass Bestellungen als Entwürfe eingereicht werden, passen Sie die Preise auf dem Bestellentwurf an, sperren Sie sie und senden Sie die Rechnung. Es gibt kein Objekt für die Antwort des Käufers, eine zweite Version oder eine Freigabe, eine Verhandlung mit mehr als einem Austausch braucht also eine Angebotsebene irgendeiner Art – App oder Eigenbau.

### Können wir Angebotsanfragen ohne Shopify Plus umsetzen?

Ja. Unternehmen, Kataloge, Mengenregeln, Zahlungsziele und Bestellentwürfe gibt es seit April 2026 in jedem Tarif, und eine Angebots-App oder eine Custom App auf der Admin API funktioniert auf allen. Die Plus-Abhängigkeiten sind Shopifys: Anzahlungen und Teilzahlungen, unbegrenzte und direkt zugewiesene Kataloge und – für eine Eigenentwicklung – Shopify Functions, die einen Plus-Shop brauchen, wenn sie in einer Custom App ausgeliefert werden.

### Hat Shopify ein CPQ?

Nein. Es hat Kataloge, Mengenregeln, Bestellentwürfe und den B2B-Checkout; Konfigurationsregeln, geführter Verkauf und CRM-natives Anbieten kommen von CPQ-Plattformen, die sich mit Shopify integrieren, und Verhandlung über Standardprodukte kommt von Angebots-Apps. Welches ein Shop braucht, ist Frage 2 im Baum.

### Wie schätzen wir die Kosten einer Eigenentwicklung?

Kalkulieren Sie die Pflichten, nicht den Launch: das API-Upgrade jedes Quartal, die Compliance-Webhooks und Datenschutzmaßnahmen, die Webhook- und Ratenlimit-Behandlung, die zwei Extensions und ihre Upgrades und die Umwandlungslogik – jeweils für die Lebensdauer des Shops. Eine Aufwandsschätzung, die beim Livegang endet, schätzt die günstigere Hälfte.

### Welche Option hält die Daten in Shopify?

Nativ hält alles dort. Eine Angebots-App oder eine Eigenentwicklung hält die Verhandlung – Anfrage, Versionen, Freigaben, Prüfprotokoll – in ihrem eigenen Speicher und alles andere in Shopify, was die richtige Trennung ist; die Bestellung gehört immer Shopify. CPQ hält das Angebot im CPQ und die Bestellung in Shopify, und die Verbindung dazwischen ist so gut wie die Integration.

### Können eine Angebots-App und ein CPQ nebeneinander existieren?

Nur mit einer klaren Grenze: Eines von beiden besitzt das Angebot für eine gegebene Produktlinie. Zwei Systeme, die demselben Käufer beide einen Preis vorschlagen können, sind das Fehlerbild der zwei Preislisten in anderer Form.

## Quellen

Shopify-Seiten, alle gelesen am 20. September 2026:

- [B2B-Funktionen nach Tarif](https://help.shopify.com/en/manual/b2b/getting-started/plan-features) und [B2B for all – Ankündigung, 2. April 2026](https://www.shopify.com/news/b2b-for-all)
- [Checkout und Konten](https://help.shopify.com/en/manual/b2b/checkout) und [B2B-Bestellungen mit Bestellentwürfen anlegen](https://help.shopify.com/en/manual/b2b/checkout-and-orders/draft-orders)
- [Shopify Functions](https://shopify.dev/docs/apps/build/functions) und [Metaobjekte](https://shopify.dev/docs/apps/build/custom-data/metaobjects)
- [API-Versionierung](https://shopify.dev/docs/api/usage/versioning), [REST Admin API – Legacy-Hinweis](https://shopify.dev/docs/api/admin-rest), [Rate Limits der GraphQL Admin API](https://shopify.dev/docs/apps/build/apis/graphql-admin/rate-limits)
- [Datenschutzrechtliche Compliance – verpflichtende Webhooks](https://shopify.dev/docs/apps/build/compliance/privacy-law-compliance) und [Geschützte Kundendaten](https://shopify.dev/docs/apps/launch/protected-customer-data)
- [Webhooks – Zustellungen verifizieren, Timeouts und Wiederholungen](https://shopify.dev/docs/apps/build/webhooks/verify-deliveries) und [Webhooks – Überblick](https://shopify.dev/docs/apps/build/webhooks)
- [Theme App Extensions](https://shopify.dev/docs/apps/build/online-store/theme-app-extensions) und [Customer Account UI Extensions](https://shopify.dev/docs/api/customer-account-ui-extensions/latest)
- [Bestellentwürfe für B2B](https://shopify.dev/docs/apps/build/b2b/draft-orders) und [DraftOrderLineItemInput](https://shopify.dev/docs/api/admin-graphql/latest/input-objects/DraftOrderLineItemInput)
- CPQ-Definition eines Anbieters: [What is CPQ? (Salesforce)](https://www.salesforce.com/sales/cpq/what-is-cpq/)