Für Entwickler:innen und Integrator:innen
Nicht als feste Zahl pro Minute. weclapp begrenzt die gleichzeitig aktiven Requests je Tenant. Requests über dieser Grenze werden nicht abgelehnt, sondern warten bis zu 30 Sekunden in einer Warteschlange. Danach antwortet die API mit HTTP 429 Too Many Requests.
Integration besprechen
Statt einer festen Zahl pro Minute arbeitet weclapp mit vier Regeln. Wer sie kennt, baut einen Client, der nie an die Grenze stößt.
weclapp begrenzt die Zahl gleichzeitig aktiver Requests je Tenant. Wie hoch die Grenze ist, veröffentlicht weclapp nicht.
Requests über der Grenze werden nicht abgelehnt, sondern warten bis zu 30 Sekunden. Erst danach antwortet die API mit HTTP 429 Too Many Requests.
Der Schutz vor Dauerlast zählt Rechenzeit: 500 Requests mit je 100 Millisekunden ergeben 50 Request-Sekunden und sind unkritisch. Viele schwere Requests über mehrere Minuten sind es nicht.
Musste ein Request warten, nennt X-Weclapp-Wait-Ms die Wartezeit und X-Weclapp-Wait-Reason den Grund: concurrency, load oder beides. Damit steuerst du deinen Client, lange bevor ein 429 kommt.
Nach einem 429 warten, wiederholen und die Wartezeit jedes Mal verlängern. Schreibzugriffe erst wiederholen, wenn klar ist, dass der erste Versuch nicht angekommen ist.
X-Weclapp-Wait-Ms und X-Weclapp-Wait-Reason bei jedem Request auswerten. Bei concurrency weniger parallel senden, bei load schwere Requests über mehr Zeit strecken.
Mit wenigen gleichzeitigen Requests starten und erst erhöhen, solange die Wartezeit nicht steigt. Die Grenze nennt weclapp nicht, dein Client findet sie selbst.
filter=id in[...] statt vieler Einzelabfragen. Definitionen benutzerdefinierter Felder einmal laden und zwischenspeichern.
Ein Request kann 30 Sekunden in der Queue stehen und trotzdem erfolgreich enden. Ein kürzerer Client-Timeout bricht ihn zu früh ab.
Änderungen kommen per Webhook zu dir. Ungefiltertes Polling rät weclapp ausdrücklich ab.
Ein Shop spielt einmal 10.000 Aufträge aus einem Altsystem ein. So läuft der Import stabil durch.
Die Aufträge gehen in Paketen raus, anfangs mit nur zwei oder drei Requests gleichzeitig. Jeder Request hat ein Timeout von mindestens einer Minute.
Bleibt die Wartezeit niedrig, erhöht der Client die Parallelität um eins. Meldet weclapp concurrency, nimmt er einen Request weg, bei load halbiert er.
Kommt ein 429, pausiert der Client und wiederholt mit wachsender Wartezeit. Nach einem Timeout prüft er zuerst, ob der Auftrag schon angelegt ist.
Der Lauf merkt sich, welche Pakete durch sind, und setzt nach einem Abbruch genau dort wieder an.
Der Import läuft außerhalb der Hauptgeschäftszeit und nicht parallel zum Abrechnungslauf.
Genau dieses Vorgehen steckt in weclappy, unserem Open-Source-Client für die weclapp API in Python. Er steuert die Parallelität aus den Wait-Headern, pausiert nach einem 429 alle Requests gemeinsam und wiederholt keinen Schreibzugriff, dessen Ausgang offen ist. Kostenlos unter MIT-Lizenz.
Die Grenze gilt je Tenant. Shop-Anbindung, Versand-Tool, Buchhaltungsexport und n8n-Workflows teilen sich dieselbe Kapazität.
Der nächtliche Import sollte nicht mit dem Abrechnungslauf zusammenfallen. Frag vor jedem neuen Massenlauf, was sonst im Tenant läuft.
Logge X-Weclapp-Wait-Ms und X-Weclapp-Wait-Reason bei jedem Request und setz einen Alarm auf steigende Wartezeiten oder gehäufte 429. Steigt die Wartezeit, obwohl du nicht mehr sendest, läuft gerade ein anderer Client im Tenant.
Spitzen wie der Black Friday brauchen saubere Integrationen und geplante Massenläufe. Mehr dazu: Hält mein ERP den Black Friday aus?
Ein Abrechnungslauf mit vielen Rechnungen ist ein typischer Massenlauf. Mehr dazu: Abo-Rechnungen in Masse per API
Abgleiche von Tickets, Zeitbuchungen und Verträgen laufen als Massenläufe und folgen demselben Muster.
Nicht als feste Zahl. weclapp setzt keine festen Rate-Limits, begrenzt aber die parallelen Requests je Tenant. Requests darüber warten in einer Warteschlange. Nach bis zu 30 Sekunden Wartezeit antwortet die API mit HTTP 429 Too Many Requests, und dein Client muss diesen Fehler behandeln.
Du bekommst nicht sofort einen Fehler. Die Requests über der Grenze warten, bis Ressourcen frei sind, und dauern deshalb länger. Erst wenn die Wartezeit 30 Sekunden überschreitet, folgt HTTP 429. Setze Client-Timeouts von mindestens einer Minute, damit Requests mit späterem Erfolg nicht zu früh abbrechen.
weclapp veröffentlicht dafür keine Zahl. Gestalte deinen Client so, dass er die Grenze selbst findet: mit wenigen parallelen Requests starten, schrittweise steigern und drosseln, sobald X-Weclapp-Wait-Ms steigt.
Fange den Statuscode ab, warte, wiederhole den Request und verlängere die Wartezeit bei jedem weiteren Fehlversuch (exponentielles Backoff). So empfiehlt es auch weclapp. Bei Schreibzugriffen prüfst du vor jeder Wiederholung, ob der erste Versuch schon angekommen ist, besonders nach einem Client-Timeout oder Verbindungsabbruch.
Ja. Mit dem Header X-Weclapp-Wait-Timeout-Ms legst du fest, wie lange ein Request höchstens auf den Start der Verarbeitung wartet. X-Weclapp-Request-Timeout-Ms setzt ein Limit für den gesamten Request. Beide Header können Timeouts nur verkürzen. Der Request-Timeout ist ein Bestwert, kein hartes Limit; ungültige oder nicht positive Werte ignoriert der Server.
weclapp empfiehlt eine ereignisgesteuerte Architektur mit Webhooks und rät von ungefiltertem Polling ab. Wenn du doch abfragen musst, filtere und hole wenige größere Ergebnismengen, statt viele Einzelrequests zu senden. Das senkt die effektive Request-Zeit und damit die Last, nach der weclapp bewertet.
Eine feste Zahl pro Minute gibt es nicht, weil weclapp keine festen Rate-Limits setzt. Entscheidend sind die Zahl gleichzeitig aktiver Requests und die Request-Zeit über mehrere Minuten. Viele kurze Requests sind unkritisch, viele schwere Requests über Minuten können kritisch werden. Beobachte X-Weclapp-Wait-Ms und drossle, wenn die Wartezeit steigt.
Adaptive Parallelität, sichere Retries und Paginierung im Detail. Zum Artikel
Sechs Fallen, die ohne Fehlermeldung auftreten. Zum Artikel
Ein Massenlauf Schritt für Schritt. Zur Seite
Alle Endpunkte zum Durchspielen, bevor du entwickelst. Zur Collection
Wir gehen deine Jobs gemeinsam durch: welche Parallelität dein Tenant verträgt, wie Retries sicher laufen und welche Läufe sich in die Quere kommen.
