Compare

Cin7 API vs SKU.io API: Six Checks Applied (2026)

Cin7 sells two products, Cin7 Core and Cin7 Omni, and they do not share an API. Core allows 60 calls per minute per application. Omni allows 3 per second, 60 per minute and 5,000 per day. Those are different systems with different authentication, different documentation, and different ways of telling you that you have gone too fast, and which one you get depends on which Cin7 the salesperson sold you.

This page runs the six checks against both, using Cin7’s own published documentation, and answers the same six about SKU.io. It also adds a seventh that was not on my list when I started, because checking Cin7 is what taught me to ask it: does reaching your own data cost extra? Every Cin7 source is linked in the text so you can read it yourself rather than take my word for any of it.

Every Cin7 figure here was read from Cin7’s own documentation and pricing page, first on August 31, 2026 and re-checked on September 4, 2026. Vendor limits and prices move; the URLs are in the text so you can re-run this yourself.

Which Cin7 API are you actually getting?

Ask this before anything else, because the answer changes every other answer on this page.

Cin7 Core is the product that used to be DEAR Systems. Its API still runs at inventory.dearsystems.com, its V2 documentation still sits at dearinventory.docs.apiary.io, and dearsystems.com/API now redirects to the Cin7 marketing homepage. Cin7 Omni is the original Cin7, documented separately at api.cin7.com/API.

I keep finding this pattern and it keeps being useful. The marketing site gets renamed in a quarter; the things developers actually touch keep the dead brand for years. I wrote it up when Linnworks bought SkuVault and its API docs stayed put, and again when Skubana became Extensiv and its docs did the same. Cin7 is the third instance in a row, which by now says something about the category rather than about any one company.

The practical consequence is small but real: every integration guide, forum answer and internal runbook written before the rename points somewhere that no longer explains anything.

What are Cin7’s API rate limits?

Core and Omni both land on 60 calls a minute. They disagree about almost everything else.

Cin7 Core (V2)Cin7 Core (V1)Cin7 OmniSKU.io
Per minute60 per application60 per application601,000 platform limit
Per secondNot publishedNot published3Not published
Per dayNot publishedNot published5,000Not published
Signaled by429 Too Many Requests503 Service Unavailable429 Too Many Requests429 Too Many Requests
Per-token capsNoNoNoOptional, set by you

The same limit, four different answers. Rate limits per minute: Cin7 Core V2 60 per app, Cin7 Core V1 60 per app, Cin7 Omni 60, SKU.io 1,000. Per second: only Cin7 Omni publishes one, at 3. Per day: only Cin7 Omni publishes one, at 5,000. The limit is signaled by 429 on Cin7 Core V2, by 503 on Cin7 Core V1, by 429 on Cin7 Omni and by 429 on SKU.io. Read from Cin7's published documentation, September 4 2026

Two things in that table are worth more than the headline numbers.

The first is the V1 row. Cin7 Core V1 reports a rate limit as 503 Service Unavailable; the V2 blueprint reports the same limit, in the same words, as 429 Too Many Requests. If you wrote an integration against V1 and handled throttling by catching 503, then migrated to V2 as Cin7’s documentation asks you to, your backoff logic silently stops matching. A 503 and a 429 mean different things to most HTTP libraries, and only one of them conventionally carries retry semantics. Nothing in the migration notes flags this. It’s the kind of detail that costs somebody a weekend eighteen months from now.

The second is Omni’s daily cap. Sixty calls a minute sustained is 3,600 an hour, so the documented per-minute rate exhausts the documented daily allowance of 5,000 in about 83 minutes. Those two numbers weren’t set by the same conversation. Whichever one you plan against, plan against the day.

There is a third number that is not in the table, because Cin7 does not publish it. Cin7 sells a faster tier called Flex API, which their help center describes as “optionally available if you contact Cin7 Core Support” and their pricing page aims at “clients processing high volumes of sales.” So 60 a minute is the documented rate on a normal subscription, and going faster is a commercial conversation rather than a published limit. If throughput is the reason you are on this page, that is the conversation that decides it, and you can’t price it from the website.

Our number in that table needs a caveat too, because a platform limit isn’t a promise about any single endpoint. Some individual operations in our API are throttled harder than the platform ceiling: sending a customer statement is capped at 60 a minute on its own, because it sends email. A rate limit table is a summary, and the endpoint you care about may have its own.

Does Cin7 charge extra for API access?

Yes. I had this section written the other way around for four days, and checking it again before publishing is the only reason it says what it says now.

An e-commerce systems consultant I work with mentioned in August that some vendors in this category bill separately for API access. I went to check whether that described Cin7, read the three plan cards on the pricing page, saw no API line, and wrote “no.” The answer was further down the same page. Under Additional Options, the feature matrix lists API as an Add-on in all four columns (Standard, Pro, Advanced and Omni), with Flex API as a second add-on beside it. It applies to both products on this page.

Cin7’s help center is plainer still. Their list of available add-ons and integrations, under the integrations that “each require an Integration add-on in your subscription”, contains this row:

“Cin7 Core API — Add an API connection to Cin7 Core. Flex API is optionally available if you contact Cin7 Core Support.”

So on Cin7 Core, reaching your own data through the API is a line item on the subscription rather than something the plan includes, and the faster tier is a phone call. Neither is priced publicly, on the pricing page or in the help center, so I can’t tell you what either costs and I’m not going to guess. Core’s three published plans run $349, $599 and $1,199 a month as of today; the Advanced plan was $999 when the Internet Archive last captured the page in May, so these move.

One nuance in Cin7’s favor, and it is the reason this is easy to get wrong. Their connection guide says “Trial accounts are also allowed to access the API.” You can build and test against a trial without buying anything. The add-on is what you need when the thing you built goes to production, which is a fine way to run a trial and an expensive way to find out about a cost.

I’m not repeating my consultant’s figure, because he named it about a different vendor and I haven’t verified it there. What he described as a pattern is real, and Cin7 is an instance of it.

Our answer here is short, and it is the same one we published on the six checks page: API access is in every plan, we have never charged extra for it, and personal access tokens are self-serve in settings. No ticket, no tier change.

Can you scope a Cin7 API key?

No, and Cin7 says so more clearly than I could.

From their connection guide:

“Your Account ID and API Application Key are equivalent to a login and password. They must be kept secret and not shared in any way.”

That’s an accurate description of what you’re being handed. Not a scoped token but a login, able to do whatever the account behind it can do.

There is a real mitigation, and it deserves credit. Cin7 lets you create multiple API Applications on one account, and their documentation explains why: “API limits are applied on per API Application basis.” So a reporting script and a 3PL connector can hold separate keys and stop competing for the same 60 calls a minute. That is a sensible design.

What it isolates is throughput rather than permission, so both of those keys can still delete a sales order. If a contractor builds you a dashboard and you hand them a key so it can read stock levels, you have handed them the ability to write to everything, and the only way to take it back is to rotate a credential that other integrations may also be using.

This is the check I care most about, and I’ll admit that’s partly because it’s the one where our answer is strongest. Our tokens carry named permissions. A token can hold purchase_orders.update and nothing else, and you can set a per-token rate cap when you mint it. A read-only agent gets a read-only token. I’d still be making this argument if we scored badly on it, but you should discount it accordingly.

Are the docs public, complete, and current?

Mostly yes. Two things complicate it, one I measured and one that is baked into how Cin7 has versioned the thing.

The V2 documentation is genuinely open. No login, no sales call, and the whole thing is available as a machine-readable API Blueprint. I pulled the full 1.7 MB document with a single command while writing this. That’s better than a lot of this category manages, and Cin7 deserves the credit.

The caveat turned out smaller than I thought, and the correction is worth more than the original finding. I requested the V2 portal ten times over about two minutes on August 31: seven came back 200, three came back 502 Bad Gateway, and the successful ones took between 2.0 and 36.4 seconds. Before publishing I ran the same probe again on September 4 and got ten 200s, none slower than 1.1 seconds. That was a bad morning, not a pattern, and publishing the first set of numbers alone would have been unfair. A documentation portal is infrastructure and worth watching during an integration; on the evidence I have, Cin7’s is fine.

The structural caveat is version drift. V1 and V2 are both live, both documented, and V1’s pages still appear in the help center with a banner asking you to migrate. Meanwhile the V1 endpoint list covers 20 endpoints; the V2 blueprint documents 102 resources and 295 operations. Those are different products wearing the same name, and search engines have been indexing both for years, so there’s a decent chance the first Cin7 API page you land on describes the one you shouldn’t be using.

For comparison, our published collection documents 5,269 operations across 4,568 paths. The like-for-like number there is operations, 295 against 5,269, because that is the one both formats define identically; Cin7’s API Blueprint calls its groupings resources and our OpenAPI file calls them paths, and they are not quite the same unit. I count both from the live specs rather than quoting a round number, because the round number on our own site went stale once and I would rather publish something regenerable.

A bigger number isn’t automatically a better API. Ours is large for a structural reason rather than a virtuous one: our UI is itself a consumer of the same API, so every screen action necessarily has an operation behind it. Cin7’s API is an integration surface attached to a UI-first product, which is the normal way these get built. What the count actually predicts is what happens when you need something unusual.

Does it return stock levels, or only stock changes?

Both platforms return absolute stock, which is the answer you want and not one to take for granted.

Cin7 Core V2 publishes a /ref/productavailability resource, along with stock takes, stock adjustments and stock transfers. So you can ask what you have, not merely what changed. That matters more than anything else in this comparison, and I said as much on the six checks page where the whole test came from. A wholesale distributor described an enterprise platform to me that only told him “you have 5 less than you had before,” and his counts could never be trusted again.

Where we differ is what sits under the number. We keep a perpetual ledger, so the API serves the current position and every movement behind it, each with its date, quantity, unit cost, warehouse and source document. Cin7 gives you availability and the transaction lists separately. For most integrations that distinction is academic. It stops being academic the first time a number is wrong and somebody has to explain why.

A product's Movements view in SKU.io: each movement row carries its type, quantity, unit cost, warehouse, the FIFO cost layer it created, and a Source link back to the document that created it, the attribution the API returns behind a stock number

Can you get all of your data out?

Yes, on both. Core V2 puts GET operations on essentially every resource and paginates the list endpoints, and Omni is the same shape.

I check this because of a date rather than a feature. TradeGecko customers needed a complete export on June 10, 2022, and QuickBooks Commerce customers needed one again on August 31, 2023. Nobody plans for that in month one, and the operators who got out cleanly were the ones who could pull everything through an API they already understood.

The agent test

Paste the vendor’s docs URL into Claude Code or a similar terminal agent, ask it to plan a real task, and watch.

Cin7 Core passes this for V2, with an asterisk. The Apiary blueprint is fetchable and machine-readable, so an agent can read it. Cin7’s help center, where the authentication guide, the V1 documentation and the status codes live, sits behind a bot challenge. Headless requests get a challenge page instead of an article; I read those pages by driving a full browser, which is how the credential quote further up this page got here. A person browsing normally clears it without noticing it happened, which is presumably why nobody has minded. The result is that the authoritative explanation of how to authenticate is human-readable and machine-blocked, which is an odd place for it to be in 2026.

I have been saying a version of this on demos for a year:

“We actually primed ourselves really well for the AI age because right from the get-go every single thing you could do on our site is driven by API… You may not read this, but your agents will.”

That’s the whole bet, and it isn’t a costless one. Shipping API changes weekly has broken an integration at a bad moment before, which is why the docs carry a mechanical changelog that counts every addition, change, deprecation and removal per release, a breaking-changes-only RSS feed, and alerts you can subscribe to. We also publish an MCP server, so an agent can query the documentation directly rather than scraping it: npx -y @skuio/docs-mcp. Our open-source agent skills are the worked examples.

Who should not choose on API strength

Plenty of people. If you’re under about $1M on a single channel, you’ll never call either API, and buying structural depth you will not use is how people end up resenting software. Zoho Inventory or inFlow will serve you better and cost less. If your requirement list opens with SOC 2 and a big-firm implementation program, neither of us is your lane today. And if Cin7 Core is running your business and you’re not fighting it, a rate limit you’re nowhere near isn’t a reason to migrate. Migrations cost more than the quote says, every time.

The checks earn their keep when there is a developer in the building, or when your operation has the shape that breaks simple tools: multiple channels, bundles and kits, FBA plus a 3PL, wholesale alongside DTC.

Where to go from here

If you’re evaluating Cin7 more broadly than its API, what Cin7 switchers actually choose is built from recorded calls with operators who left. NetSuite API vs SKU.io API runs these same six checks against Oracle’s documentation, and inventory management API: what to check first is where the checks came from.

Then go run them on us. The docs are open at developer.sku.io, the spec is downloadable, and in a demo I will pull up the ledger and show you the movements behind a number rather than describe them. Book a demo.

Ready to see SKU.io in action?

Bring your real numbers and the messy questions — we'll walk the system against an operation like yours, not a slide deck.

Book a Demo

Founder-led demo · 2-day onboarding · no onboarding fees