Loop Returns offers two kinds of integration on top of its return and exchange flow: a one-way feed that pushes return data out to your systems by webhook or scheduled polling, and a two-way integration that lets your warehouse or ERP process a return, grade the condition of an item, and set its disposition through Loop's own API. Most businesses running Loop only ever wired up the first half. We build whichever direction is still missing, so a return doesn't just get logged somewhere, it actually moves your inventory, accounting, and warehouse process forward.
One-way integration gets return data out of Loop. Webhook events, return updated, return created, return closed, label created, fire the moment something changes, or your system can poll the returns list on a schedule instead.
Two-way integration lets your systems act back into Loop. The Process Return API can mark a return as received and processed straight from your warehouse system, and the item grading and dispositioning APIs record a returned item's condition and what should happen to it, restock, write off, send to liquidation, without someone doing that by hand in Loop's own dashboard.
Authentication depends on which piece you're calling. A standard API key, sent in the request header, covers most read access. The Label API, the webhooks API, and the ship-by-Loop API currently require OAuth 2.0 instead.
Loop's documentation describes what each endpoint does. It doesn't decide which warehouse system should receive a Process Return call, what grading criteria your team actually uses, or what your books should look like when a store-credit resolution comes back instead of a refund. That logic is specific to how each business already runs, and it's exactly the part that tends to get skipped the first time anyone connects Loop to anything else.
A warehouse scan triggers the Process Return API directly, marking the item received and graded in Loop the same moment it's checked in physically, instead of someone logging into Loop afterward to catch it up.
An item graded through Loop's API as resellable, damaged, or write-off routes to the matching inventory action automatically, rather than a person deciding by hand what each grade should mean downstream.
Tell us whether you're only pulling return data out of Loop or also pushing grading and processing decisions back in, and we'll look at what the other half would take.
Tell us which part of Loop's API your business has wired up already, the webhook feed, the Process Return API, item grading, none of it yet, and we'll work out what the missing half would actually save your team. Loop's API is just this page's example; the same one-way-only pattern shows up in plenty of other tools that technically support more than anyone ever finished building.
Let's talk →Yes, and it supports two directions: a one-way feed for pulling return data out through webhooks or scheduled polling, and a two-way integration that lets an external system process returns and record item grading back into Loop.
One-way integration only sends data out of Loop, your system listens and reacts to it. Two-way integration also lets your system act back into Loop, processing a return or recording an item's grade and disposition through Loop's own API instead of someone handling it in the dashboard.
Yes. Loop sends webhook events for return updates, return creation, return closure, and label creation, which lets another system react the moment something changes instead of polling for it on a schedule.
Yes. The Shopify integration runs on the same underlying Loop API and webhook events as any custom integration, so a business that outgrows what the Shopify app covers by default can still build directly against those same endpoints.