How often does a shipping app pull new WooCommerce orders?
I'd Ship That for WooCommerce polls your store's REST API on a schedule, every 10 to 15 minutes, so a paid order reaches The Workbench inside that window rather than the moment the buyer checks out. WooCommerce does offer webhooks at WooCommerce > Settings > Advanced > Webhooks, but our WooCommerce connection does not use them.
Polled sync, in plain terms
Polling means we ask your store what is new on a timer. Every cycle, the connection requests recent orders over the WooCommerce REST API, matches them against what it already has, and adds the ones it has not seen. Nothing on your site has to call out, and nothing has to be installed to make it work.
What the poll asks for
Read permission is enough to pull orders. Writing the status and tracking back afterwards is what needs a Read/Write key, which is why a shipping connection asks for one key at the higher level rather than two.
| Part of the request | What it does |
|---|---|
| GET /wp-json/wc/v3/orders | The orders list endpoint on the versioned REST namespace |
| status filter | Limits the pull to the statuses that are actually shippable |
| after and before | Bounds the window so each cycle is not a full history read |
| page and per_page | Pages through results, which default to 10 per page |
Why webhooks are not the default answer
WooCommerce webhooks are event notifications sent to a URL you configure, and they are managed under WooCommerce > Settings > Advanced > Webhooks. They also fail quietly in the ways outbound calls do: WooCommerce automatically disables a webhook after more than five consecutive delivery failures, where a failure is any response that is not a 2xx, 301 or 302. A poll that missed a cycle simply catches up on the next one.
If your store already sends webhooks to another service, leave them alone. A scheduled pull does not interfere with them.
When an order is late to appear
| Symptom | Check |
|---|---|
| Order missing entirely | Its status: pending payment orders are not paid and are not pulled |
| Nothing at all is syncing | The key still exists on the REST API screen and has not been revoked |
| Orders pull, no write back | The key permission is Read/Write, not Read |
| Connection fails outright | Permalinks are set to anything but Plain, so /wp-json/wc/v3/ answers |
What a sync window means for a shipping day
A ten to fifteen minute window matters at the edge of a carrier cutoff, not across a normal morning. Work the queue in batches: pull, pack, buy, print. The orders that arrive during a batch are in the next one. If you are racing a cutoff, buy the labels you have rather than waiting for the cycle to turn.
Key takeaways
- Our WooCommerce sync polls the REST API every 10 to 15 minutes.
- The pull is a filtered GET on /wp-json/wc/v3/orders, bounded by date and paged.
- WooCommerce webhooks exist and are configured in WP admin; we do not use them for WooCommerce.
- Pending payment orders are not imported, because they are not paid.
What arrives, and how fast
I'd Ship That for WooCommerce is in early access. The scheduled sync brings processing and on-hold orders into The Workbench with the buyer, the address and the line items, and leaves pending payment orders where they are. You rate shop USPS and UPS against what arrived, and buying the label sets the order to completed with the tracking number, the provider and a customer-visible note.
Related questions
The schedule is what keeps the queue current without you thinking about it, and the window is short enough that most sellers never wait on it. If an order is missing after a cycle, the cause is usually its status rather than the timing.
A poll is a small number of authenticated REST requests on a timer, bounded by a date window and paged results. That is a far lighter load than the traffic a storefront handles, and it happens whether or not a shopper is browsing.
Later cycles pick up changes, so a cancellation or refund on your side is seen on a subsequent pull rather than in the same moment. Statuses that mean the order is dead, including cancelled, refunded and failed, are treated as cancelled on our side.
No. The connection reads your store on a schedule using the REST API key, so there is nothing to configure under WooCommerce > Settings > Advanced > Webhooks for our WooCommerce integration.