A bulk Xero job loses orders when it meets a rate limit: pace it and keep a checkpoint

The limits to design around

Xero publishes limits per connected organisation: no more than 5 calls in progress at once, 60 calls a minute and a daily allowance, plus a separate per-minute limit across all organisations for an app. At the time this guide was checked Xero's FAQ stated the daily figure as 5,000 calls per 24 hours; limits can change, so read the current figures for your app before choosing a pace. Going over a limit returns HTTP 429 with a Retry-After header giving the number of seconds to wait, and responses carry headers showing the remaining daily, minute and app-minute allowance.

Four ways a busy run drops orders

A 429 treated as an ordinary error is the obvious one: the order is logged and skipped. Less obvious is a retry that ignores Retry-After and fails again, using up the minute. Parallel workers can break the concurrency limit even when the average rate looks fine. And a run that restarts from the beginning after a crash repeats earlier orders while the log cannot say which were already created.

• Compare source count with created count for the same date field before blaming anything else.
• Look for 429 responses clustered near the end of the run.
• Check how many requests can be in flight at once.

Batches and per-item status

Xero lets you send several invoices in one request; the limits FAQ suggests about 50 items is practical under the 3.5MB request size cap. Used with the summarizeErrors=false option, each submitted item returns its own status and validation errors inside an HTTP 200 response. That means a successful call does not prove every invoice was created: your code must read each item's status, and put failures on a held list with Xero's reason.

A checkpoint that survives a crash

Keep a small durable record keyed by your stable source order identifier, with states such as pending, created and held. Write pending before the call and created or held after reading the response. A restarted run then does only the pending work, and an order that was in flight at the crash is held as in doubt rather than created again. Pace the run below the per-minute and concurrency ceilings, honour Retry-After exactly, and finish every run with three counts that must add up: created plus held plus already existing equals the source count. This checkpoint reduces repeat work but is not a complete duplicate-prevention design; a lost response after a successful create still needs the lookup described in the retry guides.

What fits, what does not, and how it is accepted

The fixed-price job "Make a bulk Xero invoice run finish every order, or list exactly which ones it held" is from £445, an untested published price confirmed after your enquiry, with payment after the agreed checks pass and you sign off. It is accepted when a synthetic run of 150 orders, sent one call per order against a simulated limit of 60 calls a minute, with a simulated rate-limit response, ends with created plus held plus already-existing equal to 150, the request log stays within the agreed pace, and a halfway restart creates only the pending orders and holds an order that was in flight at the stop.

It cannot raise Xero's limits, does not backfill past months, and does not replace your architecture. Tests use a simulated responder and the Xero demo company, which resets after 28 days, rather than a live connection. This guide is written from vendor documentation read on 11 October 2026. Send invented examples and counts first, never credentials, bank details, invoices or customer records; real records are handled only after written agreement through a secure handoff.