--- title: "WeSupply Integration" description: "WeSupply is the post-purchase layer of a store: tracking, returns and delivery notifications. Agents push orders in so they become trackable and returnable, move shipments through their statuses, run the returns flow, enroll customers in SMS updates, and quote delivery dates." url: https://flowrunner.ai/integrations/wesupply date_modified: 2026-09-04T19:45:02-07:00 --- # WeSupply [Logistics](https://flowrunner.ai/integrations/category/logistics-fulfillment) WeSupply is the post-purchase layer of a store: tracking, returns and delivery notifications. Agents push orders in so they become trackable and returnable, move shipments through their statuses, run the returns flow, enroll customers in SMS updates, and quote delivery dates. 21 actions · API key · available [WeSupply website](https://wesupplylabs.com/) · [Platform Documentation](https://wesupplylabs.com/) · Capability data verified 2026-08-26 1. A customer raises a return through the WeSupply portal 2. Get Return reads the items, the refund split, the return label and its cost 3. The agent reads the original order back and compares it against what was requested 4. The agent confirms whether the configured refund processor is the same system that imported the order 5. The agent assembles the proposed outcome, the amount, and the notification mode without calling the route 6. The proposal posts to the returns queue with the money and the messaging it would trigger spelled out 7. A returns owner approves the action and decides whether WeSupply executes it or only records it ## What This Integration Enables WeSupply owns the half of the order the customer actually experiences. The store takes the money and the warehouse packs the box, and then everything the buyer sees for the next two weeks belongs here: the tracking page, the delivery estimate, the status emails and text messages, and the return when it comes back. FlowRunner agents push orders in so they become trackable and returnable, move items and shipments through their statuses, run the returns flow, and quote delivery dates both before a sale and after it. The design principle worth understanding before building against it is that this API is written from the customer's side, so most operations here do something the customer will notice. Moving an order line to a new status is what fires the matching customer notification. Enrolling a phone number is what starts the text messages. Advancing a return is what sends the email about it, and in the right configuration also moves the money. That is a feature, not a hazard, but it does mean that a fully unattended agent on this connector is an agent speaking to your customers without supervision. This connector is where a [digital andon cord](https://flowrunner.ai/concepts/digital-andon-cord) earns its place: the agent runs the whole post purchase process and stops at the one call that spends money on the customer's behalf. ### Without FlowRunner **Tracking questions reach a person**: Customers ask where the parcel is, and someone opens the carrier site to answer **Returns decided in a spreadsheet**: Approvals, refunds, and notifications are tracked separately and drift apart **Delivery promises are guesses**: The date shown at checkout comes from a static rule rather than from the carriers ### With FlowRunner **Orders become self-serve**: An imported order is trackable and returnable, and the tracking link is in the confirmation email **Returns advanced from the flow**: The agent gathers the evidence, and a named person approves the outcome and its messaging **Dates quoted from the carriers**: A delivery estimate can be asked for before the sale and refreshed after it ## Use Case Scenarios ### Every order arrives already trackable An order is paid in [Shopify](https://flowrunner.ai/integrations/shopify) or [Magento](https://flowrunner.ai/integrations/magento). The agent assembles the complete WeSupply order document, customer and line items included, and calls Import Order. Because that route is an upsert with no separate update counterpart, the flow always sends the whole document rather than a patch, and always advances the modification timestamp, since WeSupply keeps the older version when the incoming one is not more recent. It then calls Get Order Tracking Links and puts the returned URL straight into the shipping confirmation sent through [Klaviyo](https://flowrunner.ai/integrations/klaviyo). Any order WeSupply does not recognize is omitted from that response rather than reported as an error, so the flow falls back to the store's own order view for anything missing. ### A delivery promise the checkout can stand behind Before the sale, the storefront asks the flow for a date. The agent calls the shipping estimate for a single product on a product page, or the multi product form at the cart, where WeSupply answers per carrier, per method, and per product. After the sale it switches to the order level estimate, which arrives as two timestamps in one string and comes back from this connector already split into a from and a to. When a customer asks a support agent in [Zendesk](https://flowrunner.ai/integrations/zendesk) where their parcel is, the flow answers with the same window the checkout quoted, rather than with a different one. ### Status changes that speak for themselves A warehouse marks items ready for pickup, backordered, or out of stock. The agent calls Update Order Items with the previous status included, because without it WeSupply only updates lines sitting in a handful of states and answers an apparent success carrying a failure inside it, which this connector raises as a real error rather than swallowing. Each status change fires the matching customer notification. On a schedule the agent reads the changed lines back within a date window to reconcile what the store has actually processed against what it believes it sent. ## Human-in-Loop Highlight Process Return is the operation in this connector where a workflow reaches into the world and cannot pull its hand back. Two choices ride on the same call. The action decides whether the return is approved, controlled, refunded, or turned down, and it applies to every item in the return with no per item control. The notification handling decides whether WeSupply merely records that the return was dealt with somewhere else, firing nothing, or runs it through WeSupply and sends every customer notification the new status carries. And when the refund processor configured in the WeSupply admin is the same system that imported the order, choosing to refund issues a real refund against real money. So the agent does everything up to the call and nothing past it. It reads the return in full, matches the items against the original order, checks the return label cost against the value of what is coming back, and posts the whole picture: "Return 4471, three items, 218 euros, label cost 9 euros, requested reason is wrong size. Refunding through WeSupply will issue the refund in the store and email the customer. Approve refund, approve as controlled without notification, or reject?" A person answers. Rejecting, it is worth knowing, only works while the return is still in its requested state, which is one more reason this decision is made deliberately rather than discovered late. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via email Human decides Agent resumes with decision ## Agent Capabilities 21 actions ### Orders 4 - **Import Order** Pushes one order into WeSupply, which is what makes it trackable, returnable, and notifiable. This is an upsert with no separate update route: re-importing the same external order identifier replaces the order, and WeSupply only accepts the update when the modification timestamp is more recent than the one sent last time. Send the complete order every time with only the changed values altered, because this is a whole document write rather than a patch. - **Import Orders** Sends a ready made array of complete WeSupply order documents in one request, which is the bulk form and the right operation when the documents come from an upstream step or a backfill. The same upsert rules apply to every order in the batch, so an order whose modification timestamp has not moved is silently kept at its older version. - **Get Order Tracking Links** Returns the customer facing WeSupply tracking URL for each external order identifier you pass, which is what goes into a shipping confirmation email. An order WeSupply does not know is silently omitted from the response rather than reported as an error, so the vendor's own advice is to fall back to your store's own order view for any identifier missing from the result. - **Look Up Orders** Reads full order details back out of WeSupply, including the customer, the items, and their current shipping status, by internal identifier, external identifier, or customer email. The response is always an array, so a lookup by customer email returns every order that customer has. ### Items 2 - **Update Order Items** Moves one or more lines of an existing order to a new status, which is how a warehouse or store tells WeSupply that an item is ready for pickup, picked up, backordered, or out of stock, and is what fires the matching customer notification. Without the previous item status supplied, WeSupply only updates lines currently in a small set of states and answers an apparent success carrying a failure inside it, which this operation raises as an error. - **List Updated Order Items** Returns order lines whose status changed inside a date window, grouped by order, which is the read side of the status update and the way to reconcile what a store or warehouse has actually processed. The date format is fixed and any other is refused with an explicit message. ### Shipments 3 - **Update Shipment** Attaches a tracking number, carrier, and carrier status to lines of an existing order, which drives the WeSupply tracking page and the shipment notifications. The tracking URL and shipping status come as a pair when the tracking data originates outside WeSupply, and this operation is keyed on the internal order identifier rather than the external one most other routes use. - **List Allowed Shipping Countries** Returns the country codes the WeSupply account is configured to ship to. It is the cheapest connection test in this service: it takes no parameters, touches no order data, and a success proves both the account subdomain and the credential are right. - **Create Tracker** Starts tracking a parcel from just its tracking number and carrier code, with no order import and no shipment behind it. This is the one route that works entirely on its own. Some carriers refuse to answer without an extra detail such as the recipient postcode or phone number, and the courier code must come from WeSupply's supported carrier list rather than being guessed. ### Returns 4 - **Process Return** Moves an existing return to approved, controlled, refunded, or not approved. Notification handling is the most consequential choice in this service: recording the return as handled elsewhere fires no WeSupply triggers and no customer emails, while running it through WeSupply sends every notification the new status carries. Where the configured refund processor is the same system that imported the order, refunding issues an actual refund. The action applies to all items in the return with no per item control, rejecting only works while the return is still in its requested state, and WeSupply cannot create a return, only advance one a customer or administrator raised. - **List Returns** Reads returns with their full detail: state, return logic, logistics, the return label and its cost, the refund control, and the items. The page size is fixed and not adjustable, so walk the pages until one comes back short. An account whose plan does not include returns access is refused with an explicit permission message rather than an empty list. - **List Recent Returns** Returns the reference numbers of every return raised in a fixed recent window. There is no paging and no date filter, and the response is a plain array of numbers rather than return objects, so pair it with the single return read to get the detail of each. - **Get Return** Reads a single return in full, including its items, its refund split, its authorization flags, and its return shipping label, found by return reference, internal order identifier, external order identifier, or customer email. WeSupply exposes one route with four alternative identifiers, so this is one operation with an identifier type rather than four near identical ones. ### SMS Notifications 2 - **Subscribe To SMS Notifications** Enrols the customer on an order for WeSupply text message updates about that order. This is a state changing call that WeSupply exposes as an ordinary read verb, so it is neither safe nor repeatable in the way that usually implies. Consent is your responsibility rather than WeSupply's, which is a reason to gather it upstream in the flow rather than assume it here. - **Unsubscribe From SMS Notifications** Removes a phone number from the text message updates for one order. It is scoped to a single order, so a customer who wants no messages at all has to be unsubscribed from each of their orders in turn. ### Delivery Estimates 4 - **Get Estimated Delivery For Order** Returns WeSupply's estimated delivery window for an order that has already been imported. The window arrives from WeSupply as two timestamps in one comma separated string, and this operation splits it into a from and a to pair rather than leaving a flow to parse it. - **Get Shipping Estimate** Estimates delivery for a single product before it is bought, which is what powers a delivery promise on a product page. WeSupply nests this request with the location, the time, and the product each in their own node, and this operation assembles that from flat parameters and generates the request identifier the vendor requires. - **Get Shipping Estimates** Estimates delivery for several products at once, which is the cart and checkout form and returns a per carrier, per method, per product answer. WeSupply keys its product node by item identifier as an object rather than taking an array, and the same identifiers come back as the keys inside each carrier's estimate, so this operation converts your array for you and every product must carry an item identifier. - **Get Carrier Delivery Dates** Asks the carriers themselves for delivery dates to a destination and returns a timestamp per carrier service level. The carrier list is a bracket notation array WeSupply expects as repeated query parameters, which this operation sends correctly, because a comma joined list is accepted by the server and then quietly ignored as a filter. ### GDPR 2 - **Export Customer Data** Returns every order and customer record WeSupply holds for one email address, which is what a subject access request needs. Run it before any erasure, because the erasure is irreversible and this is the only way to keep a copy. - **Delete Customer Data** Erases all of a customer's data from WeSupply, matched on email address. This is irreversible and it is not scoped to one order: every order, address, and notification history for that email goes, and the customer's tracking pages stop resolving. ## Frequently Asked Questions ### What can FlowRunner do with WeSupply? FlowRunner agents can run Import Order, Import Orders, and Get Order Tracking Links in WeSupply, plus 18 more actions. ### Does connecting WeSupply to FlowRunner require OAuth? No. WeSupply connects to FlowRunner with an API key, no OAuth flow required. ### Can WeSupply trigger a FlowRunner workflow automatically? WeSupply doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at WeSupply?** This integration exposes WeSupply to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/wesupply. Site index: https://flowrunner.ai/llms.txt