--- title: "CommerceHQ Integration" description: "CommerceHQ is a hosted ecommerce platform for direct-to-consumer stores. Agents poll new orders into an ERP or warehouse, create fulfillments and shipments with tracking, refund orders, manage products, collections and customers, and search across store data." url: https://flowrunner.ai/integrations/commercehq date_modified: 2026-09-04T19:08:45-07:00 --- # CommerceHQ [E-commerce](https://flowrunner.ai/integrations/category/e-commerce) CommerceHQ is a hosted ecommerce platform for direct-to-consumer stores. Agents poll new orders into an ERP or warehouse, create fulfillments and shipments with tracking, refund orders, manage products, collections and customers, and search across store data. 55 actions · Basic auth · available [CommerceHQ website](https://commercehq.com/) · [Platform Documentation](https://developers.commercehq.com) · Capability data verified 2026-08-26 1. A scheduled poll runs, because this platform publishes no webhooks at all 2. Search Orders returns everything created since the last order the flow recorded 3. Get Order with expansion pulls the line items, customer, fulfilments and shipments 4. Get Helpers turns the bare integer ids on the order into collection, vendor and warehouse names 5. Create Fulfilment and Create Shipments write the warehouse result and tracking number back 6. The fulfillment channel receives the order in names rather than in ids 7. An operator confirms any order where the agent wants to change the customer or the address ## What This Integration Enables CommerceHQ is a hosted store for direct to consumer brands, and its API has two properties that decide how anything sensible gets built on it. There are no webhooks anywhere in the platform, so every workflow is a poll with a memory rather than a subscription. And a meaningful part of the resource surface was never documented by the vendor at all, which is why this connector separates what rests on a published contract from what does not. FlowRunner agents run the catalog, customers and orders, fulfill line by line, create shipments with carriers and tracking, issue refunds, export order files through the store's own CSV templates, and read the store's lookup maps so nothing downstream receives a bare integer where a name belongs. The read side is generous and the write side is narrow, which is a good combination for automation. Line items, customers, fulfilments and shipments are all relations, so an agent has to ask for them, and the universal search accepts contains matches, value lists and comparison operators across almost every resource. What agents should not be doing unattended is the small set of writes that quietly destroy a correction someone made on purpose. FlowRunner's [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) gate exists for exactly those, and the rest of the surface runs without asking. ### Without FlowRunner **New orders noticed on somebody's rounds**: With no event stream, orders reach the warehouse when a person next opens the admin screen **Records that look empty but are not**: An order read without expansion appears to have no line items, no customer and no shipments **Ids where names belong**: Products and orders carry bare integers for collections, vendors and warehouses, so downstream systems get numbers ### With FlowRunner **A poll with a memory**: A scheduled search from the last recorded order is what makes new orders visible, reliably and on a cadence you set **Complete records by default**: Expansion is part of the read, so relations arrive with the record rather than being quietly absent **Decoded before it leaves**: Lookup maps resolve every id into a name before an order reaches a warehouse, a ledger or a spreadsheet ## Use Case Scenarios ### The poll that stands in for a webhook Every few minutes the agent calls Search Orders for orders created after the last one it saw, sorted descending, because there is no event to subscribe to. Each hit is read back with Get Order and full expansion so the line items, customer and any existing shipments arrive with it. Get Helpers translates the collection, vendor and warehouse ids into names, and the order posts to [Slack](https://flowrunner.ai/integrations/slack) with the order number, total and customer email so the fulfillment team is looking at a record rather than a notification. Orders that carry a flag the workflow does not recognize stop there instead of continuing. ### Warehouse result written back correctly The warehouse reports a dispatch. The agent calls Create Fulfilment for the picked lines, naming a warehouse on every line whose product tracks inventory and omitting it on every line that does not, because the same body shape fails on one product and succeeds on another. It buys the label through [Shippo](https://flowrunner.ai/integrations/shippo), then writes the carrier and tracking number back with Create Shipments and corrects it later with Update Shipments if the carrier changes. List Shipping Carriers is read first, so the tracking number is attached to a carrier the store already knows about rather than to a new one created by accident. ### A day of orders that reconciles On a nightly run the agent uses Search Orders with a comparison on the created field to pull the day, decodes the ids with Get Helpers, and appends one row per order into a finance sheet in [Google Sheets](https://flowrunner.ai/integrations/google-sheets). Where a fulfillment partner wants a file rather than an API call, Export Orders To CSV renders the same set through one of the store's own CSV templates, with the template id read from List CSV Templates. New shoppers are mirrored into marketing through [Klaviyo](https://flowrunner.ai/integrations/klaviyo) so the welcome sequence starts from the same email address the store holds. ## Human-in-Loop Highlight Update Order Customer looks like a small correction and is not. Reassigning an order to a different customer also copies that customer's primary address onto the order, which means any shipping address a support agent fixed by hand a moment earlier is overwritten as a side effect. The parcel then goes to the address on file rather than to the one the shopper actually gave, and nothing in the API says this happened. So the support agent workflow gathers and stops. It posts: "Order 4417 looks like it was placed under the wrong account. Reassigning it to the correct customer will replace the shipping address currently on the order, which was edited two hours ago, with that customer's stored address. Current order address and stored address are both below. Reassign, or leave the order and fix the account link separately?" A person answers, and if the reassignment goes ahead the agent knows to run Update Order Address afterward rather than before. The lookup, the diff and the ordering of the calls are the agent's work. Deciding that a parcel should change destination is not. 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 55 actions ### Products 6 - **List Products** Returns a page of the store's products. A product arrives without its variants and images unless expansion names them, so a workflow that reads variants must expand or it will conclude there are none. - **Get Product** Reads a single product by id. Also the reliable way to learn a store's real product field names, which matters because the vendor publishes no complete field table for creating one. - **Create Product** Creates a product in the catalog. Only the fields confirmed against a live store are offered by name, and everything else goes in the open field block, so read an existing product first to see the exact names your store uses. - **Update Product** Applies a partial update, leaving anything not sent untouched. Fields with no named parameter go in the open field block for the same reason. - **Delete Product** Permanently deletes a product along with its variants and images. This cannot be undone. - **Search Products** Runs the universal search over products, accepting contains matches, value lists, relation searches and comparison operators in one body. The field names here are database names rather than the names a product comes back with, and an unrecognized name is ignored rather than refused, which quietly returns everything. ### Collections 6 - **List Collections** Returns a page of the store's product collections. Each carries an automatic flag, and an automatic collection fills itself from rules, so adding products to one by hand has no lasting effect. - **Get Collection** Reads a single collection by id. Its products are a relation, so expansion is needed to see them. - **Create Collection** Creates a product collection. Title is offered by name and everything else, including the rules that make a collection automatic, goes in the open field block. - **Update Collection** Applies a partial update to one collection, leaving anything not sent untouched. - **Delete Collection** Permanently deletes a collection. The products in it survive and simply stop belonging to it. - **Search Collections** Runs the universal search over collections. Its field names come from the search reference rather than from the record, and an unrecognized name is ignored rather than refused. ### Customers 6 - **List Customers** Returns a page of the store's customers. Addresses are relational, so without expansion the record comes back with no addresses at all rather than with an empty list. - **Get Customer** Reads a single customer by id. Use it to learn the store's real customer field names before writing an update, since the search field names deliberately differ from the record's own. - **Create Customer** Creates a customer record. Only email is confirmed as a record field name, so name, phone and address go in the open field block using the spelling a read of an existing customer shows. - **Update Customer** Applies a partial update to one customer. This is also the route that edits a customer's addresses, because the platform has no separate customer address endpoint. - **Delete Customer** Permanently deletes a customer record. This is a deletion rather than a suppression, so check your own retention rules before automating it. - **Search Customers** Runs the universal search over customers, which is the practical way to find someone by email or by an address detail. Its field names are database names, and a name it does not recognize is ignored rather than refused, which returns every customer. ### Orders 9 - **List Orders** Returns a page of the store's orders. Line items, customer, fulfilments and shipments are all relations, so without expansion an order looks like it has nothing on it. - **Get Order** Reads a single order by id, with expansion for line items, customer, fulfilments and shipments. Check the order's refundability flag here before attempting a refund, because the platform decides that per order rather than per request. - **Get Order Page** Returns the page number an order sits on for the current sort and page size. Used to deep link an operator straight to the right place in the admin order list instead of making them search for it. - **Search Orders** Runs the universal search over orders with comparison operators, so a workflow can ask for orders above a value or created after a date. With no webhooks on this platform, a scheduled search for orders newer than the last id seen is how new orders get noticed at all. - **Update Order** Applies a partial update to one order, which the vendor documents for editing the order's notes. Money, line items and status are changed through the refund, fulfilment and shipment operations instead. - **Update Order Address** Edits the shipping or billing address on one order. This changes the order's copy of the address and not the customer's address book, so a later order for the same shopper still uses their stored address. - **Update Order Customer** Reassigns an order to a different customer, and copies that customer's primary address onto the order as a side effect. The operation this page's human gate exists for. - **Export Orders To CSV** Exports one or more orders through one of the store's CSV templates, which is how an order feed reaches a fulfillment partner or an accounting system that wants a file rather than an API call. - **Refund Order** Refunds money against an order and optionally restocks the goods. The amount is a decimal in the store's major currency units, the refundability flag should be read first, and a notification setting controls whether the shopper is emailed. ### Fulfilments and Shipments 5 - **Create Fulfilment** Fulfils item lines on an order. A line whose product tracks inventory must name a warehouse and a line whose product does not must not, so read the products first rather than assuming one body shape works for both. - **Update Order Fulfilments** Edits every fulfilment on an order in one call. This route takes a bare array rather than an object, unlike its single record sibling. - **Update Fulfilment** Edits a single fulfilment, which is where a tracking number and carrier normally land once a warehouse has dispatched. Unlike the whole order variant, this route takes an object. - **Create Shipments** Creates one or several shipments against an order, accepting either a single shipment or a list. The connector wraps whichever form is given so a workflow does not have to reason about the difference. - **Update Shipments** Edits several shipments on an order in one call, which is the usual place a carrier and tracking number are corrected after the fact. ### Shipping Carriers 3 - **List Shipping Carriers** Returns the carriers configured on the store, which are what a tracking number is attached to when a shipment is created. Also a good connection test, being a small read that needs no ids. - **Save Shipping Carrier** Creates a carrier, or updates an existing one when a carrier id is present. One route with two meanings, so an id left over from an earlier step turns an intended create into an overwrite of a live carrier. - **Delete Shipping Carrier** Permanently deletes a carrier. Shipments already created against it keep their tracking numbers but lose the carrier that renders the tracking link, so check usage first. ### Files 3 - **List Files** Returns a page of the files in the store's media library, which is where product images and theme assets live. - **Upload File** Downloads a file from a URL and uploads it to the media library, which is how a product image reaches the store from a workflow. The multipart field name defaults to the common spelling and can be changed if your store expects another. - **Delete File** Permanently deletes a file from the media library. Anything still pointing at it, a product image or a theme asset, breaks immediately. ### Lookups 2 - **Get Helpers** Returns the store's lookup maps in one call: collections, tags, types, vendors and warehouses, each as ids and titles. This is the field decoder, because products and orders expose all of these as bare integers. - **Get Helper** Returns a single lookup map by name, for when a workflow needs only the warehouses or only the types rather than the whole set. ### Undocumented Resources 15 - **List Gift Cards** Returns the store's gift cards. This resource appears nowhere in the vendor's reference and was confirmed by probing a live store, so read a record before building a workflow around its fields. - **List Coupons** Returns the store's discount coupons, confirmed the same way. The platform has no discounts resource at all, so this is where discount codes live. - **List Warehouses** Returns the store's warehouses in full rather than as the id and title pairs the lookup maps give. Worth reading before fulfilling, since a tracked product needs a warehouse on every line. - **List Inventory Transfers** Returns stock transfers between the store's warehouses. There is no inventory or stock resource on this API, so transfers and warehouses are the stock movement surface the platform exposes. - **List Vendors** Returns the store's vendors, meaning its suppliers, in full rather than as id and title pairs. - **List Upsells** Returns the store's up sell campaigns, the offers shown during checkout. The record shape is unpublished and should be read before it is relied on. - **List Taxes** Returns the store's tax configuration. Useful for reconciling an order's tax lines against the rate the store was configured with at the time. - **List Themes** Returns the storefront themes installed on the store. - **List Automated Emails** Returns the store's automated email templates, the notifications sent for order and shipping events. Worth reading before turning shopper notification on in a refund, so you know what the customer will actually receive. - **List Employees** Returns the staff accounts on the store. This is personal data, so treat what comes back accordingly and do not log it wholesale. - **List CSV Templates** Returns the CSV templates an order export renders through, which is where the template id for a CSV export comes from. - **List Apps** Returns the apps installed on the store. - **List Private Apps** Returns the store's private apps, which are the credentials this connection itself is built from. Treat the response as secret material and keep it out of workflow logs. - **Get Undocumented Record** Reads a single record by id from one of the resources the platform serves but does not document. The routes were proven to exist by probing a live store, but their record shapes are unpublished, so inspect one before a workflow depends on a field. - **Search Undocumented Resource** Runs the universal search against one of those same undocumented resources. Its search field names are unpublished too, so start from a record read and expect an unrecognized name to be ignored rather than refused. ## Frequently Asked Questions ### What can FlowRunner do with CommerceHQ? FlowRunner agents can run List Products, Get Product, and Create Product in CommerceHQ, plus 52 more actions. ### Does connecting CommerceHQ to FlowRunner require OAuth? No. CommerceHQ connects to FlowRunner with basic authentication (a username and password), no OAuth flow required. ### Can CommerceHQ trigger a FlowRunner workflow automatically? CommerceHQ doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at CommerceHQ?** This integration exposes CommerceHQ 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/commercehq. Site index: https://flowrunner.ai/llms.txt