Sending 500 orders
The courier takes 50 or 100 parcels per call. A desk selection of 500 is one Feeef request, then chunks with a short rest between them.
You can select up to 500 orders and send them to one company. The company's own API will not take 500 in one call. Most of them stop at 50 or 100. The desk does not ask you to split the selection yourself.
POST /v1/stores/{storeId}/orders/cloud-parcels/sendMany is still one request. The body is the list (items or orderIds) and the carrier account (ca_…). Feeef builds the parcels and hands the list to Cloud as one batch. Cloud is the part that talks to the company. The route list is the shipping guide.
The chunk
Cloud groups the parcels by account, then cuts the list at the size that company accepts.
| Company | One courier call | Rest before the next chunk |
|---|---|---|
| Ecotrack, including DHD | 100 | 3 seconds |
| NOEST | 100 | 2 seconds |
| E-com Delivery | 100 | 2.5 seconds |
| Yalidine, Guepex, MDM Express, Zimou, Procolis | 50 | 2 seconds |
| Maystro | one parcel, in groups of 50 | 2 seconds between groups |
| ZR Express | one parcel, in groups of 50 | 1 second between groups |
| DeliveryOS | one parcel, in groups of 50 | 4 seconds between groups |
Five hundred Ecotrack orders are five calls, with three seconds between them. Five hundred Yalidine orders are ten calls. The rest is there so the next call does not land inside the company's rate-limit window. A gap of a few hundred milliseconds was enough to get HTTP 429 from Ecotrack's single-order endpoint. The chunk rest is longer than that, and it sits between chunks, not between every parcel.
Maystro, ZR Express, and DeliveryOS do not have a bulk create. Each parcel is its own HTTP call. Those calls stay on the short pace (300ms, 50ms, and 500ms). The 1–5 second rest starts only after a group of 50, which is the same shape as a bulk chunk.
How long it takes
The Feeef request stays open until Cloud reports the batch finished. A few dozen orders return in seconds. Five hundred, with the rests and the courier's own latency, can take several minutes. The Dart client waits up to 15 minutes on shipOrders. If that deadline passes, the response says the batch is still processing. Leave it. Sending the same orders again creates a second set of parcels.
After the company accepts the chunk, Feeef writes the tracking code back onto each order. That write is parallel, a handful at a time, so it does not add one round trip per order on top of the courier time.
Failed rows come back on the same response. A commune the company does not cover, a missing phone, a 429 that still got through — those orders are ok: false with an error. The ones that shipped have trackingId. You retry the failed rows, not the whole selection.
The older per-carrier send dialogs are a different path. A new integration uses sendMany and lets Cloud do the chunking. One selection, one request, then 50 or 100 at a time.
The inventory engine: one quantity the order can trust
How Feeef stock works now — scoped SKUs, reservations, movements, and why the number on the product is no longer the stock.
Shipping is a parcel now
Carrier accounts, fee cards, quotes, stop desks, labels, and what happens when the commune is not covered.