If you've built a Linnworks API integration before, you already know the documentation gets you about 70% of the way there. The last 30% is where syncs silently fail, stock counts drift, and someone in the warehouse asks why an order that shipped an hour ago still shows as unfulfilled. This post covers the parts that only show up once you're running the integration in production, not in a sandbox.
What you're actually integrating with
Linnworks isn't a single API endpoint. It's a central authentication service plus a set of regional data centres, and this matters more than most integration guides let on. When you authenticate, Linnworks doesn't just hand you a token; it also tells you which server your account's data actually lives on. Miss that step and you'll spend a confusing afternoon hitting the wrong host and getting inconsistent results, or worse, silent empty responses that look like a successful call with no data.
The Linnworks API integration auth flow, and where it trips people up
The standard flow is: you authenticate with an Application ID, Application Secret and Application Token (generated per installation in the Linnworks app store listing), and you call Auth/AuthorizeByApplication. In return you get a session token, a server URL, and a token TTL.
Rate limits: what the headers tell you, and what they don't
Linnworks enforces rate limiting per application, not per user, which matters if multiple internal tools or a client portal share the same Application ID. The API returns standard-looking rate limit headers on responses, but the useful information is in what happens when you exceed them: you get a 429, and if your retry logic doesn't back off properly, you can end up in a loop that makes the throttling worse, not better.
A few practical rules that have saved us pain on real builds:
This is the kind of thing that's invisible until you're running thousands of SKUs across multiple sales channels, which is exactly the scenario we built for on the Kukoon multi-retailer integration, where stock and order sync had to hold up across several channels without one job starving another of API budget.
Pagination is not consistent across endpoint families
This is the trap that catches people who assume one pattern applies everywhere. Some Linnworks endpoints paginate with PageNumber and EntriesPerPage. Others expect you to pass an entry count and a starting position with different parameter names entirely. A few endpoints cap the maximum page size lower than you'd expect, and if you request more than the cap, you don't always get an error; sometimes you just get truncated results with no obvious warning.
The practical fix is boring but necessary: don't write a generic pagination wrapper and assume it works everywhere. Test the actual page size limit for each endpoint you rely on, and assert on the returned count matching what you asked for. If it doesn't match, treat that as a signal to reduce your page size, not proceed as normal.
Inventory sync edge cases that cause the real damage
Order sync failures are annoying. Inventory sync failures are the ones that actually cost money, because they show up as overselling on Amazon or a customer-facing site while stock physically sits on a shelf.
What this means for your build
None of this is a reason to avoid Linnworks. It's a genuinely capable platform and the API is more complete than most warehouse systems offer. But treating it like a simple REST API you can wire up in an afternoon is how integrations end up flaky six months in, right when order volume actually justifies the automation. If you're building a Linnworks API integration that has to hold up under real order volume, across multiple channels, with warehouse staff depending on the stock numbers being right, it's worth getting the token handling, rate limit strategy and pagination logic right the first time. We've done exactly this kind of work on custom warehouse systems like the one built for LAMA Fulfilment, where API reliability wasn't optional: it was the whole point.
Our API and system integration team builds this kind of resilience in from the start: proper token refresh cycles, shared rate limiters across concurrent jobs, and pagination logic tested per endpoint, rather than retrofitting it after a warehouse team has already lost trust in the stock numbers.
If your Linnworks integration is causing more firefighting than it's saving, get in touch and we'll take a look at what's actually happening under the hood.