All endpoints disabled at 2028.2. This is a removal, not a deprecation.
Of the three clocks running against a NetSuite account, this is the least ambiguous. Oracle has published a staged retirement, and at the end of it every remaining SOAP integration stops working. Nothing is grandfathered and nothing keeps limping along.
Four releases, in order.
Stop building new SOAP integrations. Advisory rather than enforced.
You can no longer create new SOAP integrations at all.
Only the 2025.2 endpoint remains supported. Everything older is off-support — still running, but no longer standing on anything.
All endpoints disabled. Every remaining SOAP integration stops working.
It doesn't disable older endpoints. It stops supporting them.
Integrations pinned to a 2019 or 2021 endpoint keep running for another year, unsupported, and then stop. That's a long time to be carrying a risk nobody is tracking, and it's a full year in which everything looks fine.
Here is the part that makes this harder than it looks. NetSuite does not store which endpoint version an integration is coded against. There is no field to read, no record to query, no setting to check.
The version lives in the integration's own code — in the WSDL it was built against and the namespace it sends. Which means the honest answer to "which endpoint are we on?" is usually nobody here knows, and the confident answer you'll get from whoever wrote it is a memory rather than a fact.
It can only be established by observing actual traffic: what request URIs are hitting the account, from what, and how often. That's inference rather than lookup — but it is real evidence, and it beats asking around.
The consequence for planning: you cannot scope this from a configuration screen. Someone has to look at what the account is actually doing.
SOAP is old enough that the things still using it tend to be things you bought rather than things you wrote — middleware platforms, warehouse and 3PL feeds, tax engines, bank and payment integrations, older connector products.
That's mostly good news. For each one, remediation is a conversation: confirm the vendor's roadmap, confirm they'll be on REST before 2028.2, confirm which of their versions you're running, and schedule the upgrade. Not a rewrite.
It's also the reason to start earlier than the date suggests. You control your own code and can move it when you choose. You do not control a vendor's release schedule, and neither does anyone else queuing behind the same deadline.
Where it is your code, the replacement is REST — which for most operations is a smaller job than SOAP-era integrations lead people to expect.
25 August 2026, against Oracle's NetSuite Help Center — the SOAP web services removal plans FAQ.
I re-check this each release and change the date above whether or not anything moved. If a date here has shifted and I haven't caught it yet, tell me and I will fix it the same day.
SOAP remediation isn't something I offer yet — I'm working on a strategy for it. If it's what you need, say so; that's how I decide what gets built next. What I do work on is your SuiteScript estate, from $2,000.
Tell me what you need