How Loopwing talks to your marketplaces, ticks on a heartbeat, and behaves when rate-limited.
Three sections, all of them operational truth. The platforms we connect to, the exact cadence of every beat, and the rules the agent follows under a 429.
Two platforms. Every channel we know is one of them.
Loopwing is opinionated about where it operates. Each platform gets a single official API surface that the agent owns end to end — no scraped endpoints, no third-party gateways.
- Products · variants · collections
- Inventory levels per location
- Orders · fulfillments · returns
- Pricing rules per channel
- Draft orders · transfers
- Catalog Items · Listings
- Inventory · FBA Inbound
- Pricing · Competitive Pricing
- Reports · Sales & Traffic
- Orders · Notifications
- Messaging · Brand Analytics
Loopwing reads your store’s policy active set when it enrolls and requests each scope the modules you enabled actually require. You see the scope list we requested, you approve it once, and it stays stable as long as your policy file does — no opportunistic re-prompts.
Every beat on a real, named cadence.
Each module runs on a deliberate interval — fast enough to catch drift, slow enough to stay inside per-store rate limits. Listed is the cadence the agent commits to, not aspiration.
Per-store caps. Predictable behavior under a 429.
Each platform enforces its own rate ceiling. Loopwing reads it live, queues work the moment it’s told to back off, and resumes the moment the window reopens — without losing or duplicating anything.
Shopify enforces leaky-bucket limits that replenish per plan tier. Loopwing reads your store’s bucket state on every call and stays inside it — never bursts it. On a 429, the agent reads the response, parks the queued work, and resumes once the bucket refills; nothing drops, nothing double-fires.
- Pre-flight budget check before every batch
- Single in-flight token per store
- 429 → wait + resume with jitter
- No retry storms, no double-spend
Amazon SP-API tracks distinct rate and quota objects per operation (orders, pricing, inventory, reports). Loopwing enrolls the store once and reads the live ceiling for each object on every call. On a 429, the agent waits for Retry-After, deduplicates any retried request, and surfaces both the rate-limit header and the dedicated x-amzn-RequestId so you can audit exactly what was deferred.
- Per-operation rate ceiling tracked live
- Retry uses Retry-After + exponential backoff
- Request IDs logged per call
- Work queues, never lost
On any 429 — Shopify bucket exhaustion, Amazon SP-API rate or quota object, or a transient network error treated conservatively — Loopwing parks the affected work, deduplicates any retried operation, and resumes once the platform tells us it’s ready. Heartbeats stay on schedule; nothing writes twice.
Every deferred call is logged with the request ID the platform returns, so when your store dashboard surfaces a rate-limit event, you can match it to a Loopwing job in seconds.
One short email, an onboarding call inside a day, and Loopwing running against live APIs by close of business.