Handling API Limits and Retries

Introduction#

Rate limit errors look like infrastructure noise until orders stop importing during a sale. Retry design is integration logic — not an afterthought in exception handlers.

This article covers ERP connector API discipline — not general REST tutorials or Shopify GraphQL storefront queries.

Understanding Shopify rate limits#

Shopify REST and GraphQL Admin APIs expose bucket state via response headers. Clients should track available cost, restore rate, and requested query cost — throttling proactively before hard 429 responses when possible.

Bulk operations and pagination multiply cost. Catalog sweeps must use cursors and minimal field sets instead of fetching entire product graphs per SKU.

Odoo-side constraints#

Odoo XML-RPC and JSON-RPC are not infinite throughput — long transactions, missing indexes on external ID fields, and N+1 browse loops inside importers slow workers and hold connections.

Batch creates and writes where ORM allows; profile hot paths during load tests. Database locks from concurrent order imports can mimic API failures with timeout errors.

Classifying errors for retry#

Transient: network blips, 429, 5xx, Odoo serialization failures — retry with backoff. Permanent: 404 on mapped entity, validation errors, unknown SKU — route to dead-letter without endless retry.

Ambiguous 400 responses need structured logging of payload hash and mapping version so operators can fix data and replay once.

• ▸Max attempts with exponential backoff and jitter
• ▸Circuit breaker when error rate spikes across workers
• ▸Separate retry policy per queue priority

Idempotency and duplicate prevention#

Retries are safe only when importers check external IDs before create. Order import, inventory set, and partner create must upsert or no-op on duplicate — otherwise backoff logic doubles shipments.

Use idempotency keys in middleware where Shopify APIs support them; store processed webhook IDs to skip duplicate delivery.

Budget allocation across job types#

Define daily or per-minute API cost budgets per job family. When orders queue depth rises, pause catalog diff workers automatically. Media uploads get leftover budget after orders and inventory.

Reconciliation jobs should use delta queries with tight time windows to minimize call count versus full exports.

Practical recommendations#

• ✓Parse and log Shopify rate-limit headers on every client response.
• ✓Never retry permanent mapping errors more than once without human fix.
• ✓Add jitter to backoff schedules so workers do not thundering herd.
• ✓Index external ID fields used in importer lookups.
• ✓Load test retry behavior under simulated 429 responses.
• ✓Document API budget ownership between connector and custom middleware teams.

Common mistakes#

• !Fixed one-second retry loops on 429 without reading Retry-After headers.
• !Retrying order create on timeout without idempotency check — duplicates result.
• !Full catalog pagination during peak sharing budget with order import.
• !Treating all 400 errors as transient and filling dead-letter queues slowly.
• !Ignoring Odoo database symptoms and blaming Shopify limits only.
• !No circuit breaker — workers hammer a failing endpoint for hours.

Conclusion#

API limit handling combines header-aware throttling, classified retries, and idempotent importers — not generic catch-and-sleep loops.

Priority budgets tie rate limit strategy to queue design so orders survive catalog congestion.