Connecting Claude to Linnworks: what actually becomes possible
The interesting part of connecting Claude to Linnworks is not the connecting. It is the questions that stop being projects.
The shape of the change
Most Linnworks questions are not hard. They are just inconvenient. “How much did we sell of that line last month?” is a two-minute answer and a twenty-minute errand: find the right report, set the dates, export, open, filter, read, report back. The cost is not the thinking. It is the five context switches around it.
Connect an assistant to the data and the errand disappears. You type the question where you are already typing, and the answer comes back from live data in seconds. The jobs that benefit most are the ones nobody ever built a report for, because they come up once and then not again for a month.
What becomes possible, concretely
Morning triage. “What is sitting in open orders that should not be?” — and then the follow-ups, which is where it earns its keep.
Buying conversations. “What have we got on order with this supplier, when is it due, and what are we short of in the meantime?” Three systems-worth of looking, one sentence.
Customer calls. Someone rings about an order. Search by their name, read the order, see what was refunded and why, all while they are still on the phone.
Returns patterns. “Which SKUs came back most in the last ninety days?” Nobody runs that report monthly. Everybody would like to know the answer.
The awkward ad-hoc one. The question from your accountant, your insurer or your biggest customer that does not map onto any saved view.
Who ends up using it
Not, in our experience, the developers. It is the person who currently has to ask the developer. Once the connector is in place, the bottleneck between a question and its answer stops being a human diary.
What it will not do
It will not replace your despatch process, your picking, or your channel integrations — Linnworks is still doing that work. It will not invent data that is not in Linnworks: if your cost prices are wrong, your margin answers are wrong. And it is not a substitute for a scheduled report that genuinely needs to land in someone’s inbox every Monday. Ask-on-demand and report-on-schedule are different tools.
It also will not fix a messy catalogue. An assistant reading a SKU list full of duplicates and abandoned variants gives you confident answers about a mess. Worth tidying first — see getting the existing mess in order.
Read, write, or both
Seventeen tools come with the connector: thirteen that read — open and processed orders, individual orders, stock search, stock levels, customers, purchase orders, returns and refunds — and four that write: create an order, set a retail price, archive and unarchive stock items. The write tools are separable. Strip them before you deploy and the connector can only look.
Most teams should start there. Reading is where nearly all the value sits, and a connector that cannot change anything is a much shorter conversation with whoever signs off on it.
Getting it running
The server runs as a Cloudflare Worker in your own account, authenticating to Linnworks with your own application credentials, so your order data never passes through anyone else’s infrastructure. You can connect Claude to your own Linnworks account with the production source rather than building the integration from the API docs — setup is four Wrangler secrets and one deploy.
Next: thirty questions worth asking your order data.
Questions, or want a tool we don't have yet? Email hello@grafto.co.uk — a real person replies.