--- title: "Shippingbo Integration" description: "Connect AI agents to Shippingbo, a French order and warehouse management platform for ecommerce. Agents manage orders, products, and return orders, and look up configured carriers and warehouses so fulfillment data stays in sync across sales channels." url: https://flowrunner.ai/integrations/shippingbo date_modified: 2026-08-12T15:40:33-07:00 --- # Shippingbo [Logistics](https://flowrunner.ai/integrations/category/logistics-fulfillment) Connect AI agents to Shippingbo, a French order and warehouse management platform for ecommerce. Agents manage orders, products, and return orders, and look up configured carriers and warehouses so fulfillment data stays in sync across sales channels. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 14 actions · API key · available [Shippingbo website](https://shippingbo.com/) · [Platform Documentation](https://developer.shippingbo.com) · Capability data verified 2026-08-10 1. An order arrives from a sales channel or an inbound integration 2. Agent reads the line items, the destination address, and the channel's own order reference 3. Agent derives the source reference and tests whether it is stable across retries 4. Agent creates the order in Shippingbo for every case with a reliable reference 5. Agent confirms the created order carries the reference it intended 6. Agent posts the orders whose reference cannot be derived to the fulfillment channel 7. Fulfillment owner supplies or confirms the reference before those orders are created ## What This Integration Enables Shippingbo earns its place by being the point where an order from anywhere becomes one order. A French order and warehouse management platform for ecommerce, it takes the sales channels a merchant is on and hands the warehouse a single consistent object to fulfill. That is a claim about identity, not about features, and identity is exactly where these workflows succeed or fail. The platform deduplicates on a source reference that the caller supplies, so the merchant's own choice of identifier is what stops the same order being created twice. FlowRunner agents list, read, create, update, and delete orders, keep the product catalog current, list and create customer return orders, and read the carriers and warehouses configured in the account so a workflow can route to real options rather than hard coded names. Values are expressed in cents and weights in grams following the platform's conventions, and list operations use limit and offset paging with sorting by id, so any workflow reporting across the whole account pages rather than trusting the first response. The order create path passes the destination address and any extra attributes through dedicated fields, which keeps the connector honest about the platform's schema instead of pretending every merchant's order looks the same. ### Without FlowRunner **Every channel its own shape**: Orders from each marketplace, storefront, and phone call arrive in a different format **Duplicates found in the warehouse**: A retried integration creates a second order, and it is discovered when a second box is packed **Returns handled off system**: A return authorization is agreed by email and only later reflected where fulfillment can see it ### With FlowRunner **One order object**: Every channel's order lands in the same structure with the same identifiers **Duplicates prevented at the boundary**: The deduplication reference is derived and checked before an order is written **Returns created against the order**: A return is registered as a record linked to the original order rather than a message in a thread ## Use Case Scenarios ### Multi-channel orders funneled into one fulfillment queue Orders arrive from [Shopify](https://flowrunner.ai/integrations/shopify), a marketplace feed, and a B2B system that sends a file. The agent normalizes each into the Shippingbo order shape, derives a source reference from the channel's own order identifier, and calls Create Order. The warehouse works one queue. The merchant keeps the ability to trace any order back to the channel it came from, because the reference that guarantees uniqueness is also the reference that answers "where did this come from". ### Catalog kept aligned with what can actually be shipped Product data that is wrong in the OMS becomes a wrong label or a rejected parcel. The agent watches the master catalog and applies changes with Create Product and Update Product, carrying weight in grams and value in cents as the platform expects. Where a product would be deleted, the agent raises it rather than calling Delete Product, because deletion is permanent and a product referenced by historical orders is rarely safe to remove on a rule. ### Returns registered where fulfillment can see them A customer service agent agrees a return in [Zendesk](https://flowrunner.ai/integrations/zendesk). The FlowRunner agent finds the original order with Get Order, creates the return with Create Return Order linked to it, and writes the return reference back into the ticket. Later, List Return Orders feeds a weekly view of what is coming back and from which channel. The return stops living in a conversation and starts living where the warehouse will meet it. ## Human-in-Loop Highlight The gate sits just before Create Order, on the source reference. Shippingbo's protection against duplicate orders is that the caller supplies a deduplication reference, which means the guarantee is only as good as the identifier the workflow chose. When an order comes from a channel with a stable order number, that is easy and the agent should never bother anyone. The trouble is the rest: a phone order with no channel number, a CSV row from a B2B customer whose file changes format, a retried webhook where the upstream system generated a fresh identifier on the retry. In those cases the agent can still create an order, and it will look perfectly correct. The duplicate stays invisible until two pickers pull the same items and two parcels go to one customer. One of them comes back as a return the merchant pays for in both directions. So the agent stops: "4 of today's 212 orders have no stable channel reference. Order from Durand SARL, 3 lines, 148,50 EUR, arrived by file with no order number. Use the file line hash as reference, use a reference I supply, or skip and handle manually?" A person answers once and the rule usually generalizes. This is [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) placed on identity, which is the least glamorous and most expensive thing to get wrong in an order management system. 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 14 actions ### Orders 5 - **List Orders** Returns a paginated list of orders with an optional state filter and id sorting. Used for reconciliation between channels and fulfillment. - **Get Order** Retrieves one order by id, including line items, shipment references, and tracking. Used when support or finance needs the full record. - **Create Order** Creates an order with line items and a destination shipping address, deduplicated on the source reference you supply. Used to funnel every channel into one queue. - **Update Order** Applies a partial update to an existing order's fields. Used to push address corrections and line changes that arrived after the order was created. - **Delete Order** Permanently deletes an order by id. Used to remove an order created in error, and proposed to a person rather than run on a rule because it cannot be undone. ### Products 5 - **List Products** Returns a paginated list of catalog products. Used to compare the platform's catalog against the master system. - **Get Product** Retrieves one product by id. Used to confirm weight, value, and barcode before an order references it. - **Create Product** Adds a product to the catalog with title, reference or SKU, weight, value, and barcode. Used to make a new SKU shippable as soon as it exists upstream. - **Update Product** Applies a partial update to an existing product. Used to keep dimensions, weights, and identifiers aligned with the master catalog. - **Delete Product** Permanently deletes a product by id. Used for genuine cleanup, with the caution that historical orders may reference it. ### Returns 2 - **List Return Orders** Returns a paginated list of customer return orders. Used to see what is coming back and from which channel. - **Create Return Order** Creates a return linked to an existing order. Used to register an agreed return where the warehouse will actually meet it. ### Logistics 2 - **List Carriers** Returns the carriers configured in the account. Used so routing logic picks from real configured options rather than hard coded names. - **List Warehouses** Returns the warehouses configured in the account. Used to route orders and reporting to the correct site. ## Frequently Asked Questions ### What can FlowRunner do with Shippingbo? FlowRunner agents can run List Orders, Get Order, and Create Order in Shippingbo, plus 11 more actions. ### Does connecting Shippingbo to FlowRunner require OAuth? No. Shippingbo connects to FlowRunner with an API key, no OAuth flow required. ### Can Shippingbo trigger a FlowRunner workflow automatically? Shippingbo doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Shippingbo?** This integration exposes Shippingbo 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/shippingbo. Site index: https://flowrunner.ai/llms.txt