A product synchronisation job that retries immediately can turn a temporary throttle into a longer incident. Before buying an integration, ask for bounded waiting, a resumable queue and an honest incomplete state. Request-count limits and cost-based limits must not be mixed.
Primary evidence and claim boundaries
Retry-After can specify delay seconds or an HTTP date. Primary reference · Read 17 October 2026.
Shopify states that limit mechanics vary by API and plan, including cost-based versus request-based approaches. Primary reference · Read 17 October 2026.
Filled acceptance example
Synthetic teaching scenario, not a client case, provider integration test or business result. Scroll the example table on narrow screens.
| Synthetic response | Declared job policy | Next state |
|---|---|---|
| 429 at 10:00:00; Retry-After:30 | No retry earlier than advised | Earliest10:00:30, plus chosen jitter |
| 503; date 10:01:00Z; now 10:00:20Z | Date-based wait | Wait at least 40 seconds |
| Third transient failure | Example max 3 attempts reached | Stop automatic retry; keep cursor/pending rows |
| No valid header; permanent validation error | No transient classification | Quarantine for correction, not busy retry |
Practical handover procedure
- Record the actual API/version, throttle signals and retryable errors. Agree total attempts, maximum elapsed time, job ownership and manual escalation. Three attempts here is illustrative.
- Calculate wait from the received response, preserve server-date evidence and account for clock uncertainty. Use bounded backoff/jitter where appropriate, rather than a zero-delay loop.
- Exercise a throttle, a malformed header and a permanent error offline. In authorised integration testing verify checkpoint readback and no duplicate side effects when the queue resumes.
Interpret the outcome
The first two waits are 30 and 40 seconds respectively, not a universal “retry in one second”. A stopped job still owns unfinished rows and needs an operator outcome. The provider’s capacity cannot be inferred from these teaching numbers.
Acceptance decision
Approve only when retry timing, bounded termination, checkpoint ownership and pending-row counts are inspectable. A final 200 for one request does not prove the whole synchronisation completed.
Limits and unverified work
No external API requests, waits or account expansion were performed. Exact limits, safe retries and idempotency remain provider- and operation-specific.
Download the filled bilingual acceptance record — Contains these inputs, steps, expectations and limits. This is a teaching record, not an executable integration.