ScanOrders
LogisticsScanOrders is barcode pick and fulfillment scanning for Shopify and WooCommerce sellers. Agents read orders and their picked state, add order lines, and poll for newly picked fulfillments to trigger the next step in the warehouse.
What This Integration Enables
ScanOrders sells one claim: this item was physically scanned by a person before it shipped. Everything else in the product exists to make that claim checkable. The picking queue holds what should be scanned, the picked list holds what was, and the mis-scan report holds where the two disagreed. FlowRunner agents connect all three to the rest of the operation, so a scan at the bench becomes a fulfillment event upstream, and a mis-scan becomes a message to a supervisor rather than a line in a report nobody opens.
Two behaviors shape how a flow should be built against it. First, the API reads are not push based, so a flow either polls the vendor's own watermark or polls the order listing with a modified date constraint it controls, and the second is the right choice for anything that must not miss a row. Second, an unauthenticated read of this API returns a success with an empty list rather than a rejection, so a flow whose credential quietly expired receives the words "no orders" and carries on as though the warehouse were empty. The connector ships a connection test that reports an explicit authentication flag for exactly this reason. Treat the first empty result in any new flow as a question, not an answer.
Without FlowRunner
With FlowRunner
Use Case Scenarios
-
The store's orders become a scannable queue
An order is paid in Shopify or WooCommerce. The agent reads the line items and calls Create Order Line for each one, writing the barcode, the order number, and the quantity to pick. The picker works from the scanner without touching a screen. When the flow polls back and finds the lines picked, it triggers the next step: a label goes to the bench printer through SellIntegro CloudPrint, and the store's fulfillment record is updated. The picker's scan, not a person clicking a button, is what advanced the order.
-
Mis-scans caught while the box is still open
On a short interval the agent calls List Incorrect Scans, which is the exception report showing where a picker scanned something the order did not expect. Each entry posts to the packing channel in Slack with the order number, the expected item, and the item that was actually in the picker's hand. A mis-scan usually means the wrong thing is about to ship, and catching it at the bench costs a walk back to the shelf. Catching it after delivery costs a return, a replacement, and the customer's patience.
-
Orders that arrive as files instead of as API calls
Some accounts receive their orders as files rather than through a store connection. For those, the agent runs the FTP sourced synchronization for a barcode and then reads back the resulting line, because the two creation routes in this API are not interchangeable and differ in substance as well as in field spelling. The account check route additionally requires the account username and password in the body on top of the token, which is a deliberate extra verification rather than a redundant one, and the connector keeps the two operations separate so a flow chooses knowingly.
Human-in-Loop Highlight
Mark Picked writes the same picked state that a scanner writes, for picks completed outside the warehouse scanner. It is a genuinely necessary operation, and it is also the one place in this connector where a flow can manufacture the exact evidence the product exists to produce. Reverse Pick can put the line back in the queue afterwards, so the state is recoverable, but the audit trail is not: a line marked picked in bulk and a line scanned at the shelf are indistinguishable once written. So the agent never marks a line picked on its own reasoning. When a dispatch cutoff approaches with lines still unscanned, it gathers them and asks the supervisor: "Four lines on order 10482 are unscanned and the courier collects in twenty minutes. Marking them picked records them as verified without a scan. Mark them, hold the order for the next collection, or split the shipment?" The supervisor answers, and their name sits beside the decision. Delete Order, by contrast, has no undo and no soft delete in this API at all, which is why it stays out of any unattended path entirely.
Agent Capabilities
13 actionsConnection
1- Test Connection Verifies the ScanOrders token by reading one order and reporting whether the call authenticated. It exists because an unauthenticated read of this API answers a success with an empty list rather than a rejection, so the authentication flag it reports is the difference between an empty warehouse and a broken credential.
Orders
7- List Orders Searches order lines with constraints, sorting, and offset paging, and reports how many rows remain. This is the read that gives a flow a watermark it controls rather than one the vendor manages.
- Get Order Reads one order line by its identifier.
- Create Order Line Creates an order line ready for picking. The vendor publishes two routes with an identical contract and its own integration calls the second, so this operation retries the alternative spelling automatically when the primary answers a routing failure.
- Sync Order Line Creates an order line through the synchronization route, which also verifies the account username and password in addition to the token. It is not interchangeable with the ordinary creation route: it demands a product description and a warehouse location, and the two routes spell their fields differently.
- Sync Order Line From FTP Runs the FTP sourced synchronization for one barcode, for accounts whose orders arrive as files rather than through a store connection.
- Look Up Order Resolves an order through the application's own lookup workflow rather than by reading the raw record.
- Delete Order Deletes an order line permanently. This API offers no undo and no soft delete, which is why it belongs behind a review step rather than in an unattended cleanup sweep.
Picking
4- Mark Picked Marks a quantity as picked in bulk, for picks completed outside the warehouse scanner. It writes the same state a scan writes, which is what makes it the operation this page's human gate exists for.
- Reverse Pick Reverses a bulk pick and puts the line back into the picking queue.
- List Picked Orders Lists picked orders by status. This is the primitive the vendor's own integration polls, and the legal status values are not published anywhere, so read the real ones off live records first.
- Watch New Picked Orders Returns newly picked orders using the vendor's own watermark. It takes no parameters and the vendor does not document how it decides what is new, so two flows polling it may interfere with each other's view. Poll the order listing instead when a flow must not miss a row.
Exceptions
1- List Incorrect Scans Lists mis-scans, the exception report showing where a picker scanned something the order did not expect. It is arguably the highest value poll in this product, because a mis-scan usually means the wrong item is about to ship.
Frequently Asked Questions
What can FlowRunner do with ScanOrders?
FlowRunner agents can run Test Connection, List Orders, and Get Order in ScanOrders, plus 10 more actions.
Does connecting ScanOrders to FlowRunner require OAuth?
No. ScanOrders connects to FlowRunner with an API key, no OAuth flow required.
Can ScanOrders trigger a FlowRunner workflow automatically?
ScanOrders doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Other Logistics integrations
Start building with ScanOrders
Free plan, no card required. Connect in minutes.