--- title: "ShippingEasy Integration" description: "Connect AI agents to ShippingEasy, US shipping label software by Auctane. Agents search and retrieve orders account wide or per store, create orders, update order status, and cancel orders so fulfillment systems stay aligned with shipping." url: https://flowrunner.ai/integrations/shippingeasy date_modified: 2026-08-12T15:40:33-07:00 --- # ShippingEasy [Logistics](https://flowrunner.ai/integrations/category/logistics-fulfillment) Connect AI agents to ShippingEasy, US shipping label software by Auctane. Agents search and retrieve orders account wide or per store, create orders, update order status, and cancel orders so fulfillment systems stay aligned with shipping. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 8 actions · Custom auth · available [ShippingEasy website](https://shippingeasy.com/) · [Platform Documentation](https://shippingeasy.com) · Capability data verified 2026-08-10 1. A payment reversal or fraud flag arrives for an order already loaded in ShippingEasy 2. Agent searches account wide, then within the owning store, to locate the order 3. Agent confirms the order has not already shipped 4. Agent gathers the current status, the store it belongs to, and the refund state upstream 5. Agent posts the order with an explicit note of what canceling here does and does not change 6. Fulfillment owner approves the cancel and takes the refund and marketplace legs alongside it ## What This Integration Enables ShippingEasy is US shipping label software from Auctane, and the connector is deliberately about the order layer rather than the label layer. That is the right boundary. Buying postage is a decision with rate shopping, packaging, and carrier account rules behind it, and it happens well inside ShippingEasy. What upstream systems actually need is for the orders to be there, correct, and carrying an honest status. FlowRunner agents search orders account wide or within a specific store, and look up an order by its ShippingEasy id or by the external order number from the originating store. They push new orders in with billing details, recipients, and line items, move an order's status through the fulfillment lifecycle, and cancel an order that should no longer ship. Two structural facts shape a workflow. The account is a set of stores, and store-scoped operations need a store API key that is distinct from the account key, obtainable through List Stores, so resolving the right storefront is a step rather than an assumption. And the search surface has a horizon: the last updated filter reaches back three months, with paging up to 200 records per page. A reconciliation flow that concludes "nothing outstanding" is only making that claim inside the window, which is a fine claim to make as long as the workflow says so rather than treating an empty result as proof. Requests are signed with an HMAC computed over the method, path, sorted parameters, and body, which the connector handles so the workflow never touches a signing routine. ### Without FlowRunner **Two systems, one truth**: Order status in the storefront and in the shipping app drift apart between manual updates **Cancels done in one place**: An order pulled from shipping stays open in the storefront and on the marketplace **Store scoping done by habit**: Whoever knows which store an order lives in is the only person who can find it ### With FlowRunner **Status pushed as it changes**: Payment and fulfillment events move the shipping app's status without anyone retyping it **Cancels treated as multi-system**: Stopping a shipment is presented with the other legs that still need doing **Store resolved by the workflow**: The right store scope is looked up rather than remembered ## Use Case Scenarios ### Sales become shippable orders automatically A sale lands in a storefront, a marketplace, or an internal B2B system. The agent resolves the owning store with List Stores, then calls Create Order with the recipient, the line items, and the billing detail. When payment confirms, it calls Update Order Status to move the order to Awaiting Shipment so it appears in the queue someone is working. The shipping team sees ready work rather than a mix of paid and unpaid orders they have to sort by hand. ### A fulfillment dashboard built from a scheduled search On a schedule the agent runs Search Orders filtered to Ready For Shipment, groups by store and age, and posts the picture into [Slack](https://flowrunner.ai/integrations/slack) or writes it to [Google Sheets](https://flowrunner.ai/integrations/google-sheets). Orders sitting past a threshold are called out by name. The value is not the dashboard, it is that the oldest unshipped order reaches a person before a customer does. ### Order lookups answered inside the support ticket Support receives "where is my order" with a storefront order number, not a ShippingEasy id. The agent calls Search Store Orders or Get Store Order using the external identifier, reads the status, and replies inside the [Zendesk](https://flowrunner.ai/integrations/zendesk) ticket. The two identifier systems stay separate in the platforms and get joined in the workflow, which is where that translation belongs. ## Human-in-Loop Highlight The gate sits on Cancel Order, and the reason is that this cancel is only one leg of the real one. Canceling in ShippingEasy stops the shipment. It does not refund the customer, does not release the marketplace's order record, does not stop a late-shipment clock at Amazon or eBay, and does not tell anyone what happened. An agent that receives a chargeback notice and calls Cancel Order on its own has done a third of the job and left a storefront that still thinks the order is live and a customer who has heard nothing. That is worse than doing nothing, because it looks handled. So the agent gathers the whole picture first and then asks: "Order 55-40912 in store Northline Supply, status Awaiting Shipment, not yet labeled. Payment reversed 11 minutes ago. Canceling here stops the shipment only. Refund is not issued and the marketplace record stays open. Cancel and open the refund and marketplace tasks, cancel only, or hold for review?" The fulfillment owner decides, and the agent then runs whichever set of legs was chosen. [Orchestration as a Service](https://flowrunner.ai/concepts/orchestration-as-a-service) is exactly this: the agent knows the boundary of what one system can do and refuses to pretend that boundary is the whole decision. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 8 actions ### Orders 8 - **Search Orders** Searches orders account wide, filtered by status, order number, tags, or last updated date within the past three months, with paging. Used for the recurring sweeps that drive fulfillment dashboards and exception handling. - **Get Order** Retrieves the full detail of an order by its numeric ShippingEasy id. Used when the workflow already holds the platform identifier. - **List Stores** Returns the stores in the account along with the store API keys used to scope store-level operations. Used to resolve the right storefront before any store-scoped call. - **Search Store Orders** Searches orders within a specific store using the store API key. Used when the question is scoped to one storefront rather than the whole account. - **Get Store Order** Retrieves an order within a store by the external order identifier from the originating system. Used in support workflows where the customer quotes the storefront's order number. - **Create Order** Creates a new order with billing details, recipient, and line items. Used to push sales from any upstream system into the shipping queue. - **Update Order Status** Moves an order through the fulfillment lifecycle. Used to reflect payment and fulfillment events so the shipping queue shows only what is genuinely ready. - **Cancel Order** Cancels an order so it will not be shipped. Used after a person has confirmed the refund and marketplace legs, because this operation covers the shipment only. ## Frequently Asked Questions ### What can FlowRunner do with ShippingEasy? FlowRunner agents can run Search Orders, Get Order, and List Stores in ShippingEasy, plus 5 more actions. ### Does connecting ShippingEasy to FlowRunner require OAuth? ShippingEasy uses a custom authentication method to connect to FlowRunner. ### Can ShippingEasy trigger a FlowRunner workflow automatically? ShippingEasy doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at ShippingEasy?** This integration exposes ShippingEasy 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/shippingeasy. Site index: https://flowrunner.ai/llms.txt