Docs for developers and integrators | Figures checked on 11.10.2026
According to its documentation, the weclapp API has no fixed rate limits, meaning no fixed number per minute. It does, however, limit the number of concurrently active requests per tenant. Requests above that are not rejected but currently wait in a queue for up to 30 seconds; after that comes HTTP 429 Too Many Requests (as of 11.10.2026).
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.
Evaluate X-Weclapp-Wait-Ms and X-Weclapp-Wait-Reason, and throttle when the wait time rises.
Start with only a few concurrent requests and increase only step by step (our recommendation).
Fetch custom field definitions only once.
Changes come to you, no unfiltered querying.
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.
Not as a fixed number. weclapp states that the API has no fixed rate limits. There is, however, a limit for parallel requests per tenant. Requests above it wait in a queue. After currently up to 30 seconds of waiting, the API responds with HTTP 429 Too Many Requests. The client must handle this error.
You don't get an error immediately. Requests above the limit are not rejected but wait until resources are free, and therefore take longer. Only when the wait time currently exceeds 30 seconds does HTTP 429 follow. So set client timeouts of at least one minute, so that requests that would succeed later don't abort too early.
In the API documentation, weclapp states no number for this (as of 11.10.2026), so we don't state one either. Treat the limit as unknown and design your client so that it can cope with wait times and 429. For bulk runs, start with a few parallel requests, increase step by step and watch the X-Weclapp-Wait-Ms header. Throttle when the wait time rises.
Catch the status code in the client, wait, retry the request and lengthen the wait on every further failed attempt (exponential backoff). weclapp names exactly this approach as a recommendation. For write requests, check before every retry whether the first attempt has already arrived. This is especially important after a client timeout or connection drop. It is our recommendation, not a requirement from weclapp.
Yes. With the X-Weclapp-Wait-Timeout-Ms header, you set how long a request waits at most for processing to start. X-Weclapp-Request-Timeout-Ms sets a limit for the entire request. Both headers can only shorten timeouts. The request timeout is a best effort, not a hard limit; the server ignores invalid or non-positive values.
weclapp recommends an event-driven architecture with webhooks and advises against unfiltered polling. If you do have to query, filter and fetch a few larger result sets instead of sending many individual requests. That lowers the effective request time and thus the load by which weclapp assesses.
The API documentation states no fixed number per minute, because weclapp sets no fixed rate limits (as of 11.10.2026). What matters is the number of concurrently active requests and the effective request time over several minutes. Many short requests are uncritical, many heavy requests over minutes can become critical. Watch X-Weclapp-Wait-Ms and throttle when the wait time rises.
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
Are you planning a bulk run or an integration and want to go through the pattern together?
