Can my ERP handle Black Friday?

In its API documentation, weclapp states no throughput limit and no number for permitted parallel requests (as of October 11, 2026). weclapp's stated goal is to prevent improper use without restricting normal use: typical use cases should see no or only minimal impact. Whether your peak day triggers noticeable wait times depends on the number and duration of your requests, not on the order count alone.

On availability, weclapp lists "99.5% availability" on its pricing page under "Included in all packages" (checked on October 11, 2026). The pricing page names no reference period. There is also no statement on throughput or response time here.

The mechanics are described in the weclapp API documentation in the "Load management" section. For the peak, this applies: a spike first shows up as longer response times and only later as HTTP 429. It becomes visible in the response headers X-Weclapp-Wait-Ms and X-Weclapp-Wait-Reason, which weclapp sets when a request had to wait.

The wait time adds to the response time of your integration. Therefore set client timeouts longer than the wait time; weclapp recommends at least one minute, so that requests that still end successfully later don't abort too early. What counts is the effective request time, not just the number of requests.

weclapp recommends avoiding short bursts of many parallel requests and spreading resource-intensive tasks over a longer period. What matters for you, then, is the concentration, for example through a promotion at 8 p.m., and the number of requests per order.

The order count alone says little. The scheme comes from wals.pro, not from weclapp. Four steps:

1. Orders in the peak hour: daily orders times the peak hour's share. You know the share from last year or from your promotion planning.
2. Requests per order: count what your integrations trigger, such as sales order, customer, delivery, invoice, payment and tracking. Your integration provider's log or a trial run will show it.
3. Requests per second: step 1 times step 2, divided by 3,600.
4. Concurrently active requests: requests per second times average response time in seconds.

Your value is a planning figure, not a free pass. weclapp does not state the limit. Therefore log the wait-time headers even in normal operation, so you have a baseline before the peak. You don't need artificial load on your production system for this.

Two cases differ. With the standard integration to your shop and marketplaces, you don't control the requests yourself. According to weclapp's documentation on the Shopify integration (page as of August 6, 2025), weclapp transmits stock to the shop every 5 minutes after activation (weclapp's integration page, by contrast, speaks of real time; plan with the documented interval and have weclapp confirm it), and incoming orders go from the shop to weclapp automatically if the checkbox "Automatic order transfer from the shop" is ticked. Details are in Keeping inventory in sync between shop and marketplaces. Marketplaces are part of the Handel package. How the standard integration behaves during a spike, we have no verified information. Ask weclapp or your partner.

With your own scripts, workflows and purchased bridges, control is yours. The schedule further below applies to them, and it also lists what you can check on the standard integration.

A fictional merchant has, in addition to the standard integration, its own bridge for special cases. They expect 5,000 orders on Black Friday and anticipate the peak in the evening after a promotion. They implement backoff, batches and timeouts as recommended by the weclapp API documentation. For the peak, the following is added:

1. They transmit orders from special cases evenly through their own queue instead of sending each one immediately and individually.
2. They move price and stock runs to the morning, i.e. outside the peak.
3. A change freeze applies to the bridge one week before.
4. Tasks that remain open after several attempts end up in a list for the team. They don't disappear silently.

The example deliberately gives no performance figures.

A webhook reports changes on its own; polling means the integration keeps asking. Backoff means it waits after an error and lengthens the wait with each attempt.

• Does the integration work with webhooks or with polling? weclapp advises against unfiltered polling.
• How many requests does it send at most at the same time, and can that be limited?
• What happens on HTTP 429? weclapp expects the client to handle the error.
• Does it remember what has already been processed? Otherwise duplicate orders arise after an abort.
• Where do you see stuck tasks before customers ask?

An integration that can't answer one of these points is the first candidate for your trial run.

The time intervals are wals.pro recommendations, not a weclapp requirement. If you have less than four weeks left, combine the rows: list systems and count requests per order in the first week, trial run and alert in the second, change freeze one week before the peak. If even that isn't possible, first set up the alert on the wait-time headers and the list of stuck tasks.

A peak strains more than the API. Stock, shipping and payment run in parallel.

Stock: During spikes, the risk of overselling can rise because more orders arrive in a shorter time. More in Keeping inventory in sync between shop and marketplaces.

Shipping: Every parcel needs a label. weclapp connects DHL directly. Fulfillment 4 weclapp connects further carriers and freight forwarders directly and generates multiple labels per delivery.

Payment: Incoming payments rise with the peak. Zahlungsabgleich 4 weclapp detects open items and bank transactions, checks them and posts clear cases in weclapp; uncertain ones go to review. It resolves collective remittance advices from PayPal and American Express into individual payments including fees via a five-stage scoring match; other payment providers on request.

Staff: Decide who sees and handles alerts on the peak day.