--- title: "Was Sie mit der QuotWay API und Webhooks bauen können" description: "Sechs Integrationen mit der REST API und signierten Webhooks von QuotWay im Tarif Enterprise – ERP, CRM, Headless, Freigaben, BI – und was sie nie tut." url: "https://www.quotway.com/de/blog/quotway-api-webhooks-recipes" type: "blog post" category: "Shopify AI & integrations" published: "2026-09-30" verified: "2026-09-30" audience: "Händler im Tarif Enterprise sowie die Entwickler und Agenturen, die QuotWay an ein ERP, ein CRM, einen Headless-Shop oder ein BI-Tool anbinden" scope: "Die QuotWay REST API v1 und ausgehende Webhooks, wie sie am 30. September 2026 gestartet sind: sechs Integrationsrezepte mit ihren Events, Endpunkten und Stolperfallen, die Designentscheidungen hinter der API, ihre Grenzen und Fragen, die Sie der API jeder Angebots-App stellen sollten" locale: "de" source: "QuotWay - B2B Quote & Negotiation App for Shopify" --- # Was Sie mit der QuotWay API und Webhooks bauen können QuotWay hat jetzt eine öffentliche REST API und signierte ausgehende Webhooks, im Tarif Enterprise – auch während der 14-tägigen kostenlosen Testphase. Zusammen sorgen sie dafür, dass der Rest Ihrer Systeme Ihren Angeboten folgt, ohne dass jemand eine Zahl abtippt: Ihr ERP erfährt von einem angenommenen Angebot in dem Moment, in dem der Käufer annimmt, Ihr CRM-Deal zeigt den Betrag, der tatsächlich vereinbart wurde, ein Headless-Shop oder eine Vertriebs-App kann Angebotsanfragen einsenden, und Ihr Team erfährt von Freigaben dort, wo es ohnehin arbeitet. Eines tut sie nie: Preise festlegen. Die API erfasst, was Käufer anfragen, und sendet Angebote, die Ihr Team bereits kalkuliert hat; Preise, Ihr Mindestpreis und Ihre Genehmigungsrichtlinien bleiben in QuotWay, wo Ihr Team sie steuert. Dieser Beitrag zeigt sechs Dinge, die Sie bauen können, die Stolperfalle in jedem davon, warum die API so gestaltet ist, wie sie ist, und die Fragen, die Sie der API jeder Angebots-App stellen sollten. Die Referenz steht in [der API-Dokumentation](/docs/api); jede Angabe hier entspricht ihr mit Stand 30. September 2026. ## Was verfügbar ist | Baustein | Was er Ihnen gibt | | --- | --- | | REST API v1 unter `api.quotway.com` | Angebote lesen (Positionen, Summen, Ereignisse, PDFs, Analysen), Angebotsanfragen anlegen, Nachrichten posten, ein Angebot senden, das Ihr Team bereits gespeichert hat | | Ausgehende Webhooks | Ein signierter HTTPS-Request für 25 Angebotsereignisse – von der neuen Anfrage über Angebote, Gegenangebote, Annahme, Umwandlung und Zahlung bis zu jeder Genehmigungsentscheidung | | Events-Feed | `GET /v1/events`: die Ereignisse der letzten 30 Tage in Reihenfolge, um alles nachzuholen, was ein Empfänger verpasst hat | | Keys | Mit Scopes (`read_quotes`, `read_customer_data`, `read_analytics`, `write_quotes`, `manage_webhooks`), optionalem Ablaufdatum und IP-Allowlist, 24 Stunden Überlappung beim Rollen eines Keys; `qw_test_`-Keys für Entwicklungsshops | | Spezifikation | OpenAPI 3.1 unter `https://api.quotway.com/openapi.json` – importierbar in Postman, Insomnia oder einen Codegenerator | Keys erstellt ein Admin des Shops unter **Einstellungen → Integrationen → API-Keys**. Die Limits liegen bei 120 Requests pro Minute je Key und 300 je Shop. ## 1. Melden Sie Ihrem ERP den Abschluss in dem Moment, in dem er steht **Events:** `quote.accepted`, `quote.partially_accepted`, `quote.converted` · **Scope:** `read_quotes` Wenn ein Käufer annimmt, erreicht ein Webhook Ihren Endpunkt innerhalb von Augenblicken. Ihr Handler prüft ihn, antwortet mit `200` und ruft das vollständige Angebot ab, um den Verkaufsdatensatz anzulegen oder zu aktualisieren, den Ihr ERP für den Deal führt – Angebotsnummer, Unternehmen des Käufers, vereinbarte Positionen und Summen. Wird das Angebot zu einem Shopify-Bestellentwurf, feuert `quote.converted` einmal pro Bestellentwurf, mit dem Link, den Ihr ERP neben der Bestellung ablegen kann – [wie diese Umwandlung bei genau einem Bestellentwurf bleibt](/blog/idempotent-draft-order-creation), ist eine eigene Engineering-Geschichte. Die Bestellung selbst sollte das ERP weiterhin so erreichen wie Ihre anderen Bestellungen – über Ihren bestehenden Shopify-Connector –, und der umgewandelte Bestellentwurf trägt die Referenz des Angebots, sodass beide zusammenfinden. Der Webhook ergänzt die Verhandlung hinter der Bestellung; er ersetzt nicht den Bestellsync. [Integrationsmuster für ERP, CRM und PIM](/blog/shopify-b2b-erp-crm-pim-integration-patterns) legt fest, welches System welches Feld schreiben sollte. Der Handler, mit der offiziellen Standard-Webhooks-Bibliothek: ```js import express from "express"; import { Webhook } from "standardwebhooks"; const wh = new Webhook(process.env.QUOTWAY_WEBHOOK_SECRET); // "whsec_…" const app = express(); // Keep the body raw for this route - verification needs the exact bytes. app.post("/hooks/quotway", express.raw({ type: "application/json" }), async (req, res) => { let event; try { event = wh.verify(req.body.toString("utf8"), req.headers); } catch { return res.status(400).send("Invalid signature"); } const eventId = req.headers["webhook-id"]; if (await alreadyProcessed(eventId)) return res.sendStatus(200); await enqueueForProcessing(eventId, event); // fetch event.data.url and upsert, in the background res.sendStatus(200); }); ``` **Die Stolperfalle:** Zustellungen erfolgen *mindestens einmal* und *nicht in Reihenfolge*. Dasselbe Ereignis kann zweimal ankommen, und eine Wiederholung eine Stunde später trägt das Angebot so, wie es *dann* ist. Deduplizieren Sie also über den Header `webhook-id`, sortieren Sie nach `data.sequence`, und rufen Sie für alles, was Sie in ein führendes System schreiben, das Angebot über `data.url` ab, statt der Zusammenfassung im Payload zu vertrauen. ## 2. Halten Sie den CRM-Deal auf dem Betrag, der tatsächlich vereinbart wurde **Events:** die Verhandlungs- und Ergebnisereignisse · **Scope:** `read_quotes` (plus `read_customer_data`, wenn das CRM die Kontaktdaten des Käufers braucht) Ein CRM-Deal, der einem Angebot folgt, braucht zwei Dinge: die richtige Phase und den richtigen Betrag. Die Phasen lassen sich direkt zuordnen: | QuotWay-Ereignis | Deal-Phase | | --- | --- | | `quote.created` | Neue Anfrage | | `quote.proposal_sent` | Angebot gesendet | | `quote.countered` | Verhandlung | | `quote.merchant_approval.requested` | Interne Prüfung | | `quote.accepted` | Gewonnen | | `quote.partially_accepted` | Teilweise gewonnen – die nicht entschiedenen Positionen sind weiterhin offen | | `quote.declined`, `quote.buyer_approval.rejected` | Verloren | | `quote.expired` | Abgelaufen – ein Nachfassen wert, nicht zwingend verloren | | `quote.order_completed` | Bezahlt | Beim Betrag liegen CRMs meist falsch. Bei einer Teilannahme zeigt `total` des Angebots weiterhin das gesamte ursprüngliche Angebot – das ist, was *angeboten* wurde, und es wird nie überschrieben. Speichern Sie stattdessen `totals.headline`: Das ist der Betrag, nach dem Sie handeln, und `totals.headline_mode` sagt, warum es genau diese Zahl ist (`none` oder `full` – die Angebotssumme; `decided` oder `open` – die angenommene Summe). Ist der Modus `open`, ist `still_open_total` das, was noch im Spiel ist, sodass ein Deal sowohl den vereinbarten Teil zeigen kann als auch den Teil, über den der Käufer noch nicht entschieden hat. **Die Stolperfalle:** Eine Position, die der Käufer bei einer Teilannahme nicht gewählt hat, ist *weiterhin offen*, nicht abgelehnt. Wer sie auf „verloren“ setzt, rechnet die Pipeline klein und schickt ein Nachfassen an einen Käufer, der nicht Nein gesagt hat. ## 3. Nehmen Sie Angebotsanfragen aus einem Headless-Shop oder einer Vertriebs-App an **Endpunkt:** `POST /v1/quotes` · **Scope:** `write_quotes` Eine Hydrogen-Storefront, eine Theken-App oder das Werkzeug eines Außendienstmitarbeiters kann eine Angebotsanfrage genauso senden wie der Button „Angebot anfragen“ im Onlineshop – von seinem Server aus, mit dem Key auf der Serverseite: ```bash curl https://api.quotway.com/v1/quotes \ -H "Authorization: Bearer $QUOTWAY_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: 9d3e1f7a-5b2c-4e8d-a1f0-6c7b8a9d0e12" \ -d '{ "buyer": { "email": "buyer@example.com", "name": "Dana Ortiz", "company_name": "Acme Restaurant Group" }, "lines": [ { "variant_id": "gid://shopify/ProductVariant/4455667788", "quantity": 100, "requested_price": "11.50" } ], "notes": "Delivery to our Denver kitchen, please." }' ``` Die Anfrage durchläuft dieselbe Annahme wie im Shop: Ihre Zielregeln entscheiden, ob sie zulässig ist, die benutzerdefinierten Felder Ihres Angebotsformulars werden validiert, Ihre Automatisierungsregeln laufen darauf, und Ihr Team erhält die übliche E-Mail zum neuen Angebot. `requested_price` ist nur der Zielpreis des Käufers – den Preis, den Ihr Team anbietet, legt es in QuotWay fest. Übergeben Sie eine Shopify-`customer_id`, prüft QuotWay die echten Tags des Kunden und seine Mitgliedschaften in B2B-Unternehmen; ist er Kontakt eines Unternehmensstandorts, wird das Angebot unternehmensbezogen – genau wie bei einem Käufer, der in Ihrem Shop angemeldet ist. **Die Stolperfalle:** Die `201`-Antwort meldet `submitted`, aber Ihre Automatisierungsregeln greifen innerhalb von Augenblicken auf das neue Angebot zu – eine Regel für automatisches Senden kann ein Angebot senden, eine Regel für automatisches Ablehnen kann es ablehnen. Gehen Sie nicht davon aus, dass ein gerade angelegtes Angebot noch `submitted` ist; hören Sie auf `quote.proposal_sent`, `quote.declined` und `quote.assigned`, oder rufen Sie es vor dem Handeln erneut ab. Und senden Sie immer einen `Idempotency-Key`: Bricht die Verbindung ab, nachdem das Angebot angelegt wurde, liefert die Wiederholung dieselbe Antwort statt einer doppelten Anfrage. ## 4. Bringen Sie Freigabeanfragen dorthin, wo Ihr Team ohnehin arbeitet **Events:** `quote.merchant_approval.requested`, `.granted`, `.rejected` Braucht ein Angebot eine interne Freigabe – ein Rabatt über Ihrem Schwellenwert, ein Angebot mit hohem Wert –, feuert `quote.merchant_approval.requested`. Ein kleines Relay kann daraus eine Nachricht in dem Kanal machen, den Ihre Freigebenden im Blick haben, mit Angebotsnummer und einem Link, um das Angebot in QuotWay zu öffnen; `.granted` und `.rejected` schließen den Kreis. Jedes System, das einen signierten Webhook empfangen kann, schafft das: Ihr eigener Endpunkt oder der generische Webhook-Trigger einer Integrationsplattform. Die Freigabe selbst erfolgt weiterhin in QuotWay, unter Ihren Genehmigungsrichtlinien. Die Nachricht ist eine Benachrichtigung, kein Button, der freigibt. **Die Stolperfalle:** Webhook-Payloads enthalten bewusst keine Namen, E-Mail-Adressen oder Freitexte von Käufern, die Nachricht hat also, was sie zum Weiterleiten braucht (Angebotsnummer, Status, Summen), und nichts Persönliches. Brauchen Ihre Freigebenden mehr, rufen Sie das Angebot mit einem Key mit den passenden Scopes ab – und überlegen Sie zweimal, bevor Sie Käuferdaten in einen gemeinsamen Kanal kopieren. ## 5. Holen Sie Angebotskennzahlen in Ihr BI-Tool **Endpunkt:** `GET /v1/analytics/summary` · **Scope:** `read_analytics` ```bash curl -G https://api.quotway.com/v1/analytics/summary \ -H "Authorization: Bearer $QUOTWAY_API_KEY" \ --data-urlencode "period=week" \ --data-urlencode "limit=4" ``` Der Endpunkt liefert dieselben vorberechneten Kennzahlen wie das Analyse-Dashboard von QuotWay – Volumen, angenommener und umgewandelter Wert, Pipeline und Antwortzeiten – nach Tag, Woche oder Monat, in UTC und in der Basiswährung des Shops. Ein geplanter Job, der sie in ein Data Warehouse oder eine Tabelle zieht, ist die ganze Integration; der Key braucht keinen Zugriff auf personenbezogene Daten. ## 6. Geben Sie Angebote erst nach einer Prüfung in einem anderen System frei **Endpunkt:** `POST /v1/quotes/{id}/send-proposal` · **Scope:** `write_quotes` Manche Teams kalkulieren in QuotWay, wollen aber, dass ein anderes System entscheidet, *wann* ein Angebot rausgeht – ein ERP, das Marge oder Bestand bestätigt, ein CRM-Schritt, der den Deal als bereit markiert, ein Job, der die Angebote des Morgens um neun freigibt. `send-proposal` sendet das Angebot, das Ihr Team bereits im Angebotseditor gespeichert hat, mit genau den Prüfungen, die der Admin durchführt: Das Angebot muss ein Angebot aufnehmen können, bei einem unternehmensbezogenen Angebot werden die Katalogpreise erneut aus Shopify gelesen, eine Position unter Ihrem Mindestpreis stoppt das Senden, sofern der Aufruf es nicht ausdrücklich bestätigt (dieselbe Bestätigung, die der Admin verlangt), und eine Genehmigungsrichtlinie hält das Angebot zur Freigabe zurück, statt es zu senden. **Die Stolperfalle:** Hat niemand ein Angebot gespeichert, gibt es nichts zu senden – der Aufruf liefert `409 no_staged_proposal`. Die API sendet, was Ihr Team kalkuliert hat; sie kalkuliert nie selbst. ## Warum sie so gebaut ist Sechs Entscheidungen prägen die API, und jede ist ein Grund, dem zu vertrauen, was sie tut. 1. **Sie setzt nie Preise.** Bei der Preisgestaltung verdient oder verliert ein Angebotswerkzeug Geld, und sie bleibt bei Ihrem Team – Mindestpreis, Genehmigungsrichtlinien und Angebotseditor gelten für alles, auch für das, was über die API ankommt. Es gibt keine Endpunkte, um Positionen zu bepreisen oder zu bearbeiten, im Namen eines Käufers anzunehmen oder abzulehnen oder ein Angebot in einen Bestellentwurf umzuwandeln. 2. **Webhooks enthalten keine personenbezogenen Daten.** Ein Payload enthält Kennungen, den Ereignistyp sowie Nummer, Status, Währung und Summen des Angebots – nie Name, E-Mail, Telefon, Adresse oder Nachricht eines Käufers. Käuferdaten kommen nur aus der API, und nur mit einem Key, der den Scope `read_customer_data` hat. Ein falsch konfigurierter Endpunkt kann nicht preisgeben, was ihm nie gesendet wurde. 3. **Webhooks folgen der Spezifikation Standard Webhooks.** Die Signatur-Header sind die standardisierten, Sie prüfen also mit den offiziellen `standardwebhooks`-Bibliotheken statt mit selbst geschriebenem Code. Während einer Secret-Rotation werden Zustellungen 24 Stunden lang mit beiden Secrets signiert, sodass beim Umstellen nichts fehlschlägt. 4. **Zustellungen werden wiederholt und lassen sich danach erneut abspielen.** Eine fehlgeschlagene Zustellung wird siebenmal wiederholt – acht Versuche insgesamt – über etwa 3,7 Tage; ein Endpunkt, der dauerhaft fehlschlägt, wird deaktiviert, und Ihr Team erhält eine E-Mail. Alles Verpasste steht 30 Tage lang in Reihenfolge in `GET /v1/events`. 5. **Jeder Schreibzugriff ist idempotent.** Jeder `POST` akzeptiert einen `Idempotency-Key`, der 24 Stunden lang gilt, sodass eine wiederholte Anfrage kein zweites Angebot anlegen und kein Angebot doppelt senden kann. 6. **Fehler sind spezifisch und stabil.** Fehler folgen RFC 9457 mit einem stabilen `code` – `not_eligible`, `below_price_floor`, `insufficient_scope` –, der auf seinen eigenen Eintrag in [der Fehlerreferenz](/docs/api/errors) verlinkt, sodass eine Integration auf einen Code verzweigen kann, statt einen Satz zu parsen. ## Was sie (noch) nicht tut - **Keine fertigen Konnektoren.** Es gibt keine App im Zapier-Verzeichnis, keinen MCP-Server und keine eingebaute Verbindung zu HubSpot, Salesforce oder Klaviyo. Sie können jedes dieser Systeme *über* die API und Webhooks anbinden. - **Keine SDKs, keine GraphQL-API und keine Sandbox.** Die OpenAPI-Spezifikation lässt sich in die meisten Tools importieren; `qw_test_`-Keys funktionieren in einem Shopify-Entwicklungsshop, mit den echten Daten dieses Shops. - **Keine Preisgestaltung, keine Bearbeitung von Positionen, keine Annahme und keine Umwandlung über die API** – bewusst so, wie oben beschrieben. ## Fragen an die API jeder Angebots-App Welche App Sie auch prüfen: Diese Fragen trennen eine API, auf der Sie bauen können, von einer Zeile auf einer Preisseite: - Ist die Dokumentation öffentlich, mit einer maschinenlesbaren Spezifikation, die Sie importieren können? - Sind Webhooks signiert, und können Sie sie mit einer Standardbibliothek statt mit eigenem Code prüfen? - Was passiert mit einer Zustellung, die Ihr Endpunkt verpasst – wie lange wird sie wiederholt, und können Sie sie erneut abspielen? - Kann eine wiederholte Anfrage ein Duplikat erzeugen, oder akzeptieren Schreibzugriffe einen Idempotency-Key? - Enthalten Webhook-Payloads Kundendaten, und können Sie einen Key so einschränken, dass er keine lesen kann? - Kann die API Preise ändern – und wenn ja, gelten Ihr Mindestpreis und Ihre Freigaben weiterhin? - Wie viel Vorlauf bekommen Sie vor einer inkompatiblen Änderung? (Die [API-Nutzungsbedingungen](/api-terms) von QuotWay sagen mindestens sechs Monate zu.) Der Rest einer App-Prüfung – Datenverarbeitung, API-Versionen, was serverseitig durchgesetzt wird – steht in [wie Sie eine Shopify-B2B-App bewerten](/blog/shopify-b2b-app-evaluation-checklist). ## Erste Schritte 1. Stellen Sie sicher, dass der Shop im Tarif Enterprise oder in der 14-tägigen Testphase ist – die [Preise](/pricing) zeigen die Tarifdetails. 2. Erstellen Sie unter **Einstellungen → Integrationen → API-Keys** einen Key mit nur den Scopes, die Sie brauchen, und akzeptieren Sie die API-Nutzungsbedingungen. 3. Folgen Sie [dem Quickstart](/docs/api/quickstart): den Key mit `/v1/ping` prüfen, Angebote auflisten, eine Anfrage anlegen – etwa zehn Minuten. 4. Fügen Sie unter **Einstellungen → Integrationen → Webhooks** einen Webhook-Endpunkt hinzu und senden Sie einen Test-Ping. Die Produktseite dazu ist [die Feature-Seite zu API & Webhooks](/features/api-webhooks). ## Häufige Fragen ### Hat QuotWay eine API? Ja. QuotWay hat eine öffentliche REST API (v1) unter `api.quotway.com` und signierte ausgehende Webhooks, im Tarif Enterprise – auch während der 14-tägigen kostenlosen Testphase. Sie liest Angebote, legt Angebotsanfragen an, postet Nachrichten und sendet Angebote, die Ihr Team bereits kalkuliert hat; Preise setzt sie nie. ### Welcher Tarif enthält die QuotWay API und Webhooks? Der Tarif Enterprise ($199/Monat), und ein Shop in der 14-tägigen kostenlosen Testphase kann beides nutzen. Wechselt ein Shop in einen niedrigeren Tarif, bleiben seine Keys und Webhook-Endpunkte erhalten, sind aber pausiert, bis er wieder im Tarif Enterprise ist. ### Kann ich Angebote aus einem Headless-Shopify-Shop anlegen? Ja – mit `POST /v1/quotes` vom Server Ihres Shops. Die Anfrage durchläuft dieselben Zielregeln, dieselbe Validierung benutzerdefinierter Felder und dieselben Automatisierungsregeln wie der Angebots-Button im Onlineshop und landet als Anfrage, die Ihr Team kalkuliert. ### Enthalten QuotWay-Webhooks Kundendaten? Nein. Webhook-Payloads enthalten Kennungen, den Ereignistyp sowie Nummer, Status, Währung und Summen des Angebots – keine Namen, E-Mail-Adressen, Telefonnummern, Adressen oder Nachrichten. Kontaktdaten von Käufern kommen nur aus der API, mit einem Key, der den Scope `read_customer_data` hat. ### Wie prüfe ich die Signatur eines QuotWay-Webhooks? QuotWay folgt der Spezifikation Standard Webhooks, verwenden Sie also die offizielle `standardwebhooks`-Bibliothek für Ihre Sprache: Übergeben Sie ihr den rohen Request-Body, die Header `webhook-id`, `webhook-timestamp` und `webhook-signature` sowie das `whsec_`-Secret Ihres Endpunkts. Weisen Sie alles zurück, was die Prüfung nicht besteht. ### Kann die API Preise setzen oder ein Angebot für den Käufer annehmen? Nein. Es gibt keine Endpunkte, um Positionen zu bepreisen oder zu bearbeiten, im Namen des Käufers anzunehmen oder abzulehnen oder ein Angebot umzuwandeln. Ein über die API gesendetes Angebot ist das, das Ihr Team gespeichert hat, mit denselben Prüfungen von Mindestpreis und Freigabe wie im Admin. ### Kann QuotWay mit Zapier oder HubSpot verbunden werden? Über die API und Webhooks ja – etwa mit einem Webhook an den generischen Webhook-Trigger einer Integrationsplattform oder mit Ihrem eigenen Dienst, der das CRM aktualisiert. Eine fertige App im Zapier-Verzeichnis und eine native Anbindung an HubSpot gibt es derzeit nicht. ## Quellen Die API-Dokumentation von QuotWay, gelesen am 30. September 2026: - [API-Überblick](/docs/api), [Quickstart](/docs/api/quickstart) und [Authentifizierung, Keys und Scopes](/docs/api/authentication) - [Webhooks](/docs/api/webhooks) – der Ereigniskatalog, Payloads, Signaturen, Wiederholungen und Reihenfolge - [Angebote anlegen](/docs/api/create-quotes), [Nachrichten und Angebote](/docs/api/messages-and-proposals), [das Angebotsobjekt](/docs/api/quote-object), [Ereignisse](/docs/api/events), [Analysen](/docs/api/analytics) und [Rate Limits](/docs/api/rate-limits) - [Fehler](/docs/api/errors) und die [OpenAPI-Spezifikation](https://api.quotway.com/openapi.json) - [API-Nutzungsbedingungen](/api-terms)