NetSuite API vs SKU.io API: Six Checks Applied (2026)
I run six checks on any inventory API before I watch a demo. This page runs them on NetSuite, using Oracle’s public documentation, and on SKU.io, which I built. NetSuite passes more of them than its reputation suggests. It fails one in a way that costs real money, and the failure is not the one people expect.
The short version: NetSuite’s REST API Browser is fully public, lists 417 record types, and needs no login. That is better documentation than most of this category ships. But API throughput is a purchased license. Your account gets a base of 5 to 20 concurrent requests depending on service tier, and Oracle’s own words are that “the base limit is increased by 10 for each SuiteCloud Plus license.” SKU.io includes API access in every plan and does not meter concurrency by license.
Checked against Oracle’s live documentation on 21 August 2026, NetSuite release 2026.1. Quotes are verbatim from recorded calls, lightly cleaned of transcription artifacts, attributed by role with names withheld.
Is NetSuite’s API actually any good?
Yes. I want to say that clearly before anything else, because I sell against NetSuite and you should discount me accordingly.
I expected to find gated documentation. That is the usual story with enterprise software, and I have repeated it myself in demos. It is wrong. The REST API Browser for release 2026.1 loads in a logged-out browser, and I counted 417 record types in it: account, assemblyBuild, binTransfer, blanketPurchaseOrder, salesOrder, and on down. Oracle also publishes the concurrency governance rules, the authentication flows, and the record schemas, in public, before you sign anything.
That is a genuine pass on the check most enterprise vendors fail. If you are evaluating NetSuite, read the docs. They are right there, and they will tell you more than the demo will.
Can the API do everything the UI can?
For record CRUD, NetSuite’s coverage is broad. For anything that is not record CRUD, you write and deploy SuiteScript.
That is the architectural difference, and it is not a small one. NetSuite’s REST Web Services handle creating, reading, updating and deleting records across that 417-type surface. When you need business logic, meaning a calculation, a validation against your own rules, or something that touches several record types in one call, the documented path is a RESTlet, which is a SuiteScript file you write, deploy, and then maintain forever.
So the honest answer to “can the API do what the UI does” is: the API can do what the records do, and a developer you employ can do the rest. Whether that is a problem depends entirely on whether you have that developer. An agency lead told me why he was leaving his own bespoke system in 2022, and it is the sentence I think about whenever someone tells me a platform is infinitely extensible:
“I don’t want to have a bunch of developers tuning on that because I’ve done that before and just hundreds of thousands of dollars on endless software and it’s like, what do I have for that?”
We built the other way around. The SKU.io front end is a consumer of the same public API you get, which is why our spec counts 5,269 documented operations rather than the couple of hundred endpoints a bolt-on API tops out at.
Do not read that against NetSuite’s 417 as a score. They count different things: 417 is record types, and each one carries its own set of verbs, so the comparable number on their side is larger than 417 and I have not seen Oracle publish it. The two figures are not on the same axis and I am not going to pretend they are. What the 5,269 tells you is about our side only — that the surface is wide enough to have been built for the app itself rather than bolted on afterwards. A consultant who does e-commerce accounting for a living put the same point more concisely than I ever have, on a call in February 2024:
“You wrote your app against your own API. That’s the right way to do it, in my opinion.”
The test that settles it on either platform: pick the most obscure thing you do in your current system, and search the vendor’s docs for it.
Does it report stock levels, or only stock changes?
Both platforms report levels, so this check is a pass for NetSuite and the interesting question is one level down: can you find out how the number got there?
NetSuite can. It is a full accounting system with transaction records underneath the balances, and that is one of the genuine reasons people buy it. SKU.io is perpetual for the same reason. Here is how I explained the distinction to a channel partner’s integration team in April 2026, when they offered us a stock-level endpoint and I asked for an events one instead:
“We’re perpetual. We want inventory to be accurate at all times, which is why we can’t just get an inventory level, because there’s no attribution as to how that inventory got there… if we get 95, we don’t know if you received all 100 and shipped five already, or received all 100 and lost five.”
If a platform can only tell you the number, you find out at the physical count that it was wrong, and you have nothing to reconstruct. Ask any vendor for the events, not the balance. NetSuite has a good answer here. Most of the mid-market does not.
That screenshot is what attribution looks like in practice: every movement on the product names its type, the warehouse it happened in, the cost layer it created, and the source document it traces back to. The API returns the same rows.
Is API access included in the price?
This is the check NetSuite fails, and it fails on throughput rather than access.
Reaching the API is not the upsell. Being able to reach it fast enough is. Concurrency is governed per account across SOAP, REST and RESTlets together, and the base limit depends on your service tier. Oracle’s “Concurrency Governance Limits Based on Service Tiers and SuiteCloud Plus Licenses” page publishes the ladder: 5 for Standard, 15 for Premium, 20 for Enterprise and Ultimate, with a separate older table for legacy tiers. Go and read that page rather than taking my word for the numbers, because it is the one place this is written down plainly and it is public. To raise the limit you buy SuiteCloud Plus licenses, and the same page is unambiguous about the mechanism:
“The base limit is increased by 10 for each SuiteCloud Plus license.”
And about how you get one:
“Generally, you can purchase one SuiteCloud Plus license per NetSuite account. Contact your sales representative to discuss any need for additional licenses.”
Read that as an operator. Your integration load grows. A new channel, a 3PL, a nightly sync, an AI agent doing catalog work. At some point the fix for “our syncs are queueing” is a phone call with a salesperson. That is a purchasing decision attached to a technical limit, and it recurs every time the load steps up again.
I want to be careful not to overstate it. Ten concurrent requests is a lot for most operations, and plenty of NetSuite accounts will never touch the base limit. The point is not that the ceiling is low. It is that the ceiling is a line item, so capacity planning and procurement are the same conversation.
SKU.io includes API access in every plan and does not sell concurrency as a licensed unit. I will be precise about what that is and is not. It is not unlimited throughput: we rate-limit, to keep the platform healthy for everyone. What it means is that there is no per-account concurrency SKU on our price list to be sold one more of, so adding an integration is a technical conversation rather than a commercial one.
Are the docs public, complete and current before you sign?
Both pass, which was the surprise of this exercise.
developer.sku.io is public with no login. Oracle’s REST API Browser is public with no login. If you are comparing either of us against a vendor whose API documentation arrives after an NDA, that vendor is the outlier, and gated docs are usually gated for a reason.
One caveat I hit while checking, worth knowing if you go looking yourself: NetSuite’s help URLs are versioned, and old ones return a page that says “Page Not Found” while still serving an HTTP 200. The 2024.1 and 2025.1 browser links are dead in exactly that way. Make sure you are reading the current release before you conclude anything about coverage.
Can you mint tokens scoped to one job?
Both pass. NetSuite has token-based authentication and OAuth 2.0 with its role and permission model behind them, which is genuinely mature. It is an accounting system, and auditors have opinions.
SKU.io issues personal access tokens carrying explicit scopes, and every token can be inspected with a single call to /api/me, which returns the tenant it belongs to and exactly what it is allowed to do. I use that constantly: the first thing any script or agent of mine does is confirm which account it is pointed at, because the expensive mistakes in this job are the ones where the code was right and the target was wrong.
What I will not claim: we do not have SOC 2. What we have is scoped tokens, a full audit trail and tenant isolation, and if that is not enough for your compliance team, NetSuite is a reasonable answer to that question.
Can you get all of your data back out?
Both pass, with an asterisk on NetSuite’s that I could not resolve from public documentation.
SuiteQL lets you run SQL-like queries through the REST API and is included. The older bulk path, SuiteAnalytics Connect, is the ODBC/JDBC route, and Oracle’s documentation describes it as something to be turned on, “if your company enables the Connect Service”, without saying anywhere public what enabling it costs. Third parties quote a monthly figure. I am not going to repeat a number Oracle does not publish; ask your rep and get it in writing.
SKU.io’s export path is the same API as everything else, on every plan.
I check this one because of a date. TradeGecko customers needed a complete export on 10 June 2022, and QuickBooks Commerce customers needed one again on 31 August 2023. Nobody plans for that in month one.
The six checks, side by side
| Check | NetSuite | SKU.io |
|---|---|---|
| UI parity | Broad record CRUD across 417 record types; anything beyond that is a RESTlet you write and maintain in SuiteScript | The front end runs on the same public API, so parity is structural rather than a coverage target |
| Absolute stock | Yes, balances with transaction records underneath | Yes, a perpetual ledger with inventory events carrying attribution |
| Included in price | Access yes, throughput no. Base 5–20 concurrent requests by tier, +10 per purchased SuiteCloud Plus license | Included in every plan; concurrency is not a licensed unit |
| Real documentation | Public, no login, current release 2026.1 | Public, no login, at developer.sku.io |
| Scoped access | Token-based auth and OAuth 2.0 over NetSuite's role and permission model | Scoped personal access tokens, inspectable via /api/me |
| Export path | SuiteQL included; SuiteAnalytics Connect is enabled separately and Oracle publishes no price for it | Same API, every plan |
What about handing the API to an AI agent?
This is where the two architectures stop resembling each other, and it is the part of my own job that changed most in the last year.
Because everything SKU.io’s interface does is an API call, an agent can do it too. I keep a library of open-source agent skills for building a catalog from a supplier price list, raising purchase orders, and adjusting inventory. A terminal-based agent like Claude Code drives them against the documented API. They are MIT-licensed at github.com/skuio/sku-skills, and they work because the docs are public and the operation surface is complete. I said the mechanism out loud on a demo in June:
“Every single thing you could do in the front end we have an API call for, which means that Claude could do as well.”
On NetSuite, an agent can work the record surface, and for anything past it you are back to writing SuiteScript, which an agent can also write, and which someone then owns. The other constraint is the one from the pricing check: agents are chatty, and chatty runs into a concurrency ceiling that costs a license to raise.
An Amazon seller said the useful version of this after a demo in February 2025, about what an open API is actually for:
“I was really impressed with the API, so I think that’s going to give a lot of flexibility to your users.”
The flexibility is the point. It means not waiting on my roadmap for something you could build yourself in an afternoon.
When is NetSuite’s API the right answer?
When you have people to spend on it, and a load you can predict.
Two questions decide it, and neither is about features. Do you have in-house developers or a NetSuite partner on retainer? If yes, the SuiteScript requirement is a Tuesday rather than a wall, and the record surface underneath is genuinely deep. Second, can you forecast your integration load a year out? If your connected systems are a known set that changes rarely, the concurrency ceiling is a one-time purchase and then it is invisible. If you are adding channels and agents and cannot say what next year looks like, you are buying a variable cost with a sales call attached to every increment.
The broader question of which platform fits — cost, implementation, whether you need an ERP at all — is a different evaluation, and I wrote it up separately in SKU.io vs NetSuite with the real 2026 numbers on both sides. This page is only about what the API will let you do.
On our side, the API is for multichannel operators who want the inventory, purchasing and order layer reachable without a licensing conversation. If you are under $1M on a single channel, none of this is your problem yet, and you should be looking at Zoho Inventory or inFlow rather than at either of us.
Where to go from here
If you want the pricing comparison rather than the API one, SKU.io vs NetSuite has the real 2026 numbers on both sides. If you are earlier than that and still deciding whether an ERP is the right shape at all, ERP inventory system vs. inventory software is the place to start. The methodology behind this page, and the recorded calls that produced each check, is at inventory management API: what to check first.
Or send me the most awkward integration you have and I will run these six checks against it live, including the ones where we come off worse. Book a demo.