Peak-Zeitplan für Online-Händler:innen

Hält mein ERP den Black Friday aus?

Ob dein ERP 5.000 Bestellungen an einem Tag trägt, lässt sich nicht pauschal zusagen: Eine Obergrenze für Bestellungen pro Tag nennt weclapp in der API-Dokumentation nicht, und wir versprechen auch keine. Rund um die Uhr gerechnet sind 5.000 Bestellungen etwa 3,5 pro Minute (eigene Orientierungsrechnung); entscheidend sind die Spitze innerhalb des Tages und die Zahl der Requests pro Bestellung. Die weclapp API hat keine festen Rate-Limits, begrenzt aber die gleichzeitigen Requests je Tenant, also je weclapp-System: Überzählige warten aktuell bis zu 30 Sekunden, danach folgt HTTP 429.

Peak-Vorbereitung besprechen

Gibt es eine Zahl für Bestellungen pro Tag?

In der API-Dokumentation nennt weclapp keine Durchsatzgrenze und keine Zahl für die erlaubten parallelen Requests. Als Ziel nennt weclapp, unsachgemäße Nutzung zu verhindern, ohne normale Nutzung einzuschränken: Bei üblichen Anwendungsfällen soll es keine oder nur minimale Auswirkungen geben. Ob dein Peak-Tag spürbare Wartezeiten auslöst, hängt von der Zahl und der Dauer deiner Requests ab, nicht von der Bestellzahl allein.

Zur Verfügbarkeit führt weclapp auf der Preisseite „99,5% Verfügbarkeit“ in der Liste „In allen Paketen enthalten“ auf. Einen Bezugszeitraum nennt die Preisseite nicht. Eine Aussage zu Durchsatz oder Antwortzeit steht an dieser Stelle ebenfalls nicht.

Was passiert in der API bei einer Spitze?

Die Mechanik steht in der weclapp-API-Dokumentation im Abschnitt „Load management“. Für den Peak gilt: Eine Spitze zeigt sich zuerst als längere Antwortzeit, erst später als HTTP 429. Sichtbar wird sie an den Antwort-Headern X-Weclapp-Wait-Ms und X-Weclapp-Wait-Reason, die weclapp setzt, wenn ein Request warten musste.

Die Wartezeit kommt zur Antwortzeit deiner Anbindung dazu. Setze deshalb Client-Timeouts länger als die Wartezeit; weclapp empfiehlt mindestens eine Minute, damit Requests, die später noch erfolgreich enden, nicht zu früh abbrechen. Bewertet wird die effektive Request-Zeit, nicht nur die Zahl der Requests.

weclapp empfiehlt, kurze Spitzen vieler paralleler Requests zu vermeiden und ressourcenintensive Aufgaben über einen längeren Zeitraum zu verteilen. Wichtig sind für dich also die Verdichtung, etwa durch eine Aktion um 20 Uhr, und die Zahl der Requests pro Bestellung.

Wie viele Requests löst dein Peak aus? Rechne es selbst

Die Bestellzahl allein sagt wenig. Das Schema stammt von wals.pro, nicht von weclapp. Vier Schritte:

Bestellungen in der Spitzenstunde: Tagesbestellungen mal Anteil der Spitzenstunde. Den Anteil kennst du aus dem Vorjahr oder aus deiner Aktionsplanung.
Requests pro Bestellung: Zähle, was deine Anbindungen auslösen, etwa Auftrag, Kunde, Lieferung, Rechnung, Zahlung und Tracking. Das Protokoll deines Integrationsanbieters oder ein Probelauf zeigt es.
Requests pro Sekunde: Schritt 1 mal Schritt 2, geteilt durch 3.600.
Gleichzeitig aktive Requests: Requests pro Sekunde mal durchschnittliche Antwortzeit in Sekunden.

Dein Wert ist eine Planungsgröße, kein Freifahrtschein. weclapp nennt das Limit nicht. Logge deshalb schon im normalen Betrieb die Wartezeit-Header, dann hast du vor dem Peak einen Vergleichswert. Künstliche Last auf deinem produktiven System brauchst du dafür nicht.

Standard-Anbindung oder eigene Brücke?

Zwei Fälle unterscheiden sich. Bei der Standard-Anbindung an Shop und Marktplätze steuerst du die Requests nicht selbst. Laut weclapp-Dokumentation zur Shopify-Anbindung überträgt weclapp den Bestand nach Aktivierung alle 5 Minuten an den Shop (die Integrationsseite von weclapp spricht dagegen von Echtzeit; plane mit dem dokumentierten Takt und lass ihn bei weclapp bestätigen), und eingehende Aufträge gehen vom Shop automatisch nach weclapp, wenn der Haken „Automatische Auftragsübertragung vom Shop“ gesetzt ist. Einzelheiten stehen in Bestände zwischen Shop und Marktplätzen synchron halten. Marktplätze gehören zum Paket Handel. Wie sich die Standard-Anbindung bei einer Spitze verhält, dazu liegen uns keine geprüften Angaben vor. Frag weclapp oder deinen Partner.

Bei eigenen Skripten, Workflows und zugekauften Brücken liegt die Steuerung bei dir. Für sie gilt der Zeitplan weiter unten, und dort steht auch, was du an der Standard-Anbindung prüfen kannst.

Ein Peak-Tag im Ablauf, fiktives Beispiel

Ein fiktiver Händler hat neben der Standard-Anbindung eine eigene Brücke für Sonderfälle. Er erwartet am Black Friday 5.000 Bestellungen und rechnet mit der Spitze am Abend nach einer Aktion. Backoff, Pakete und Timeouts setzt er so um, wie es die weclapp-API-Dokumentation empfiehlt. Für den Peak kommt dazu:

Er überträgt Bestellungen aus Sonderfällen über eine eigene Warteschlange gleichmäßig, statt jede sofort einzeln zu senden.
Preis- und Bestandsläufe legt er in den Vormittag, also außerhalb der Spitze.
Eine Woche vorher gilt ein Änderungsstopp für die Brücke.
Aufgaben, die nach mehreren Versuchen offen bleiben, landen in einer Liste für das Team. Sie verschwinden nicht still.

Das Beispiel nennt bewusst keine Leistungszahlen.

Fünf Fragen an deine Anbindungen

Ein Webhook meldet Änderungen von selbst; Polling heißt, dass die Anbindung ständig nachfragt. Backoff heißt, dass sie nach einem Fehler wartet und die Wartezeit mit jedem Versuch verlängert.

Arbeitet die Anbindung mit Webhooks oder mit Polling? weclapp rät von ungefiltertem Polling ab.
Wie viele Requests schickt sie höchstens gleichzeitig, und lässt sich das begrenzen?
Was passiert bei HTTP 429? weclapp erwartet, dass der Client den Fehler behandelt.
Merkt sie sich, was schon verarbeitet ist? Sonst entstehen nach einem Abbruch doppelte Aufträge.
Wo siehst du hängende Aufgaben, bevor Kund:innen nachfragen?

Eine Anbindung, die einen dieser Punkte nicht beantworten kann, ist der erste Kandidat für deinen Probelauf.

Peak-Zeitplan

Die Zeitabstände sind Empfehlungen von wals.pro, keine Vorgabe von weclapp. Bleiben dir weniger als vier Wochen, ziehst du die Zeilen zusammen: Systeme auflisten und Requests pro Bestellung zählen in der ersten Woche, Probelauf und Alarm in der zweiten, Änderungsstopp eine Woche vor dem Peak. Reicht auch das nicht, richte zuerst den Alarm auf die Wartezeit-Header und die Liste hängender Aufgaben ein.

Wann	Was prüfen	Erledigt, wenn
Sobald wie möglich, spätestens 4 Wochen vorher	Systeme auflisten, die in dein weclapp lesen oder schreiben; Requests pro Bestellung je Anbindung zählen	Jedes System hat eine verantwortliche Person, der Wert steht schriftlich da
3 Wochen vorher	Probelauf mit simulierten 429-Antworten	Nach der Wartezeit wird erneut gesendet, kein Auftrag entsteht doppelt
2 Wochen vorher	Wartezeit-Header im Log sichtbar machen, Alarm einrichten; Bestandsübertragung zum Shop und Auftragsübertragung aus dem Shop prüfen	Der Alarm löst im Test aus, beide Übertragungen sind sichtbar aktiv
1 Woche vorher	Änderungsstopp, Massenläufe außerhalb der Spitze legen	Der Kalender der Massenläufe liegt vor
Am Peak-Tag	Zeit bis ERP-Auftrag, Wartezeit, 429, Bestandsabweichung, Labelfehler, offene Zahlungen	Je Bereich beobachtet eine Person und darf entscheiden
Am Tag danach	Retouren, Gutschriften, Erstattungen, Zahlungsabgleich	Offene Posten sind gezählt und zugewiesen

Was belastet einen Peak außer der API?

Ein Peak belastet mehr als die API. Bestand, Versand und Zahlung laufen parallel mit.

Bestand: Bei Spitzen kann das Überverkaufsrisiko steigen, weil mehr Bestellungen in kürzerer Zeit eintreffen. Mehr dazu in Bestände zwischen Shop und Marktplätzen synchron halten.

Versand: Jedes Paket braucht ein Label. weclapp bindet DHL direkt an. Fulfillment 4 weclapp bindet weitere Carrier und Speditionen direkt an und erzeugt mehrere Labels je Lieferung.

Zahlung: Mit dem Peak steigen die Zahlungseingänge. Zahlungsabgleich 4 weclapp erkennt offene Posten und Banktransaktionen, prüft sie und verbucht eindeutige Fälle in weclapp, unsichere gehen in die Prüfung. Sammelavise von PayPal und American Express löst es per fünfstufigem Scoring-Abgleich in Einzelzahlungen inklusive Gebühren auf, weitere Zahlungsdienstleister auf Anfrage.

Personal: Lege fest, wer am Peak-Tag Meldungen sieht und entscheidet.

rund 3,5

Bestellungen pro Minute im Tagesschnitt bei 5.000 am Tag (eigene Orientierungsrechnung von wals.pro)

30 s

maximale Wartezeit in der Queue, aktuell (weclapp-API-Dokumentation)

nicht genannt

Zahl für die erlaubten parallelen Requests in der API-Dokumentation

99,5%

Verfügbarkeit laut Preisseite, ohne genannten Bezugszeitraum

Die Mechanik

Queue, Wartezeit, 429 und Backoff. weclapp-API-Dokumentation

Bestand und Marktplätze

Überverkäufe vermeiden. Bestände synchron halten

Versand

Mehrere Labels je Lieferung, mehrere Carrier. Mehrere Versanddienstleister in weclapp

Der Überblick

Was ein ERP für Online-Händler:innen können muss. ERP für Online-Händler

Passt

Händler:innen mit mehreren Kanälen, die am Black Friday eine Spitze erwarten.
Teams, die eigene Skripte, Workflows oder zugekaufte Brücken steuern und vor dem Peak anpassen können.
Betriebe, die vor dem Peak einen Probelauf einplanen.

Passt nicht

Garantierte Antwortzeiten auch in Lastspitzen. Laut weclapp soll es bei üblicher Nutzung keine oder nur minimale Auswirkungen geben; wer über der Grenze liegt, wartet jedoch.
Verträge, die einen festen Durchsatz pro Sekunde oder Minute verlangen. In der API-Dokumentation steht dafür keine Zahl.
Händler:innen mit wenigen Bestellungen am Tag. Der Zeitplan wäre mehr Aufwand als Nutzen.
Wer erst am Peak-Tag selbst anfängt, die Anbindungen zu prüfen.

Häufige Fragen

Hält weclapp 5.000 Bestellungen an einem Tag aus?

Eine belegte Obergrenze für Bestellungen pro Tag nennt weclapp in der API-Dokumentation nicht, und wir sagen keine zu. Im Tagesschnitt sind 5.000 Bestellungen rund 3,5 pro Minute (eigene Rechnung). Entscheidend sind die Spitze und die Zahl der Requests je Bestellung. Wie du sie ausrechnest, steht oben im Rechenschema. Deinen Fall besprechen wir im Gespräch, ohne Zusage zur Last.

Wie viele Requests löst eine Bestellung aus?

Das hängt von deinen Anbindungen ab, eine allgemeine Zahl gibt es nicht. Zähle sie im Probelauf oder im Protokoll deines Integrationsanbieters: Auftrag, Kunde, Lieferung, Rechnung, Zahlung und Tracking können jeweils eigene Requests auslösen. Multipliziere die Zahl mit den Bestellungen der Spitzenstunde und teile durch 3.600, dann hast du die Requests pro Sekunde.

Woran merke ich am Peak-Tag, dass weclapp Requests verzögert?

An den Antwort-Headern X-Weclapp-Wait-Ms und X-Weclapp-Wait-Reason, die weclapp setzt, wenn ein Request warten musste. Ihre Bedeutung steht in der weclapp-API-Dokumentation. Logge sie schon vor dem Peak, damit du einen Vergleichswert hast, richte einen Alarm bei steigender Wartezeit ein und drossle die Parallelität, sobald sie steigt.

Was empfiehlt weclapp für Lastspitzen?

Laut API-Dokumentation sollst du kurze Spitzen vieler paralleler Requests vermeiden und ressourcenintensive Aufgaben über einen längeren Zeitraum verteilen. Weniger, dafür größere Requests sind besser als viele einzelne, Webhooks besser als ständiges Abfragen. Unsere Empfehlung für den Black Friday: Bestellungen über eine eigene Warteschlange gleichmäßig abarbeiten, statt jede sofort einzeln zu übertragen.

Was gehört in den Probelauf vor dem Black Friday?

Teste die Wiederholungslogik mit simulierten 429-Antworten, zum Beispiel über einen Mock vor deiner Anbindung. Prüfe, ob nach der Wartezeit erneut gesendet wird, ob kein Auftrag doppelt entsteht und ob hängende Aufgaben in einer Liste landen. Erzeuge keine künstliche Last und keine Testdaten auf deinem produktiven Mandanten. Größere Läufe sprichst du vorher mit deinem Partner ab.

Was sagt die Angabe 99,5% Verfügbarkeit für den Black Friday?

weclapp führt auf der Preisseite „99,5% Verfügbarkeit“ in der Liste „In allen Paketen enthalten“ auf. Einen Bezugszeitraum nennt die Preisseite nicht. Ob und wie die Angabe vertraglich zugesagt ist, klärst du mit weclapp oder deinem Partner. Zu Durchsatz und Antwortzeit sagt die Angabe nichts. Plane so, dass auch eine kurze Störung dein Team nicht überrascht.