NetSuite SOAP (SuiteTalk) Is Being Retired: The Timeline and Your Migration Path

If you run a NetSuite integration that talks to SuiteTalk SOAP, you have probably heard that SOAP is going away, and you are now trying to work out two things: how long you actually have, and what the migration involves. The answer to the first is more comfortable than the rumours suggest. The answer to the second is where the real work is.

This post sets out the official retirement timeline, shows you how to find every place SOAP is hiding in your account, and gives you a migration path to REST that you can run before the deadline rather than under it. It is the deprecation deep dive in the broader NetSuite integration guide, which covers how the integration surfaces fit together and how to choose between them today.

What is actually being retired

SuiteTalk SOAP web services is NetSuite's original XML-based API. It has been around since the early 2000s and has the most complete record coverage of any NetSuite integration surface, which is exactly why so many long-running integrations still depend on it. Oracle has now set its end date and named the replacement: REST web services with OAuth 2.0.

The retirement follows a published roadmap. Three milestones matter:

There is an important detail behind that table. SOAP endpoints are supported on a rolling window: when a new NetSuite version is released, the oldest supported endpoint loses support, though it usually stays accessible for a while afterwards. Today the supported WSDL versions run from 2023.1 to 2025.2, and a set of older ones (2019.1 through 2022.2) are still callable but already unsupported. The 2027.1 milestone simply collapses that window down to a single version, and 2028.2 closes it entirely.

A note on dates: this is Oracle's schedule and Oracle's to move. The three milestones above are what the current documentation states. You will see third-party articles citing extra milestones (a specific "no new SOAP from 2026.1" date, for example) that do not appear in Oracle's own roadmap text. Confirm any date against the current release notes before you build a plan around it, and do not let a blog post (including this one) be your single source for a deadline.

What this means right now, and what it does not

The headline is calmer than "SOAP is dead":

• Your existing SOAP integrations keep working until the 2028.2 release. Nothing breaks tomorrow. There is no need to halt operations or rush an unplanned cutover.
• You should target the 2025.2 WSDL. If your integration is pinned to an older version (a NetSuitePort_2021_2 style endpoint, say), it is either already unsupported or will be by 2027.1. Moving to 2025.2 buys you the longest remaining runway on SOAP while you plan the real move.
• Do not start anything new on SOAP. Every new integration, and every meaningful rebuild, should go to REST web services. Building new SOAP today is building something with a known expiry date and a shrinking support window.
• The work is a migration, not a panic. You have time to do this properly: inventory what you have, rebuild with error handling and idempotency designed in, and run old and new in parallel before you cut over.

The risk is not that SOAP stops on a surprise date. The risk is leaving a business-critical integration on SOAP until late 2027, then discovering during the rebuild that REST does not cover one of your record types and you are now doing an unplanned RESTlet project under deadline pressure.

How to tell if you are affected

SOAP is often invisible from the NetSuite UI, because the integration lives in an external system. Here is where to look.

The WSDL URL. Any SOAP integration calls an endpoint shaped like this, with the version baked into the path:

https://{accountId}.suitetalk.api.netsuite.com/services/NetSuitePort_2024_1

If you find that pattern in an integration platform's connection settings, a middleware config, or a piece of in-house code, that is a SOAP integration. The version number tells you which WSDL it is pinned to.

Integration platform connectors. Older Celigo, Boomi, MuleSoft, and Jitterbit flows frequently default to the NetSuite SOAP connector because it predates the REST option and has the widest record coverage. Open each connection and check whether it is the SOAP/SuiteTalk connector or the REST one. Many platforms now offer both.

The request and response shape. SOAP requests are XML wrapped in an envelope, with authentication carried inside a <soap:Header> rather than an HTTP Authorization header:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <tokenPassport>...</tokenPassport>
  </soap:Header>
  <soap:Body>
    <get xmlns="urn:messages.platform.webservices.netsuite.com">
      <baseRef internalId="123" type="salesOrder" xsi:type="RecordRef"/>
    </get>
  </soap:Body>
</soap:Envelope>

If the payloads going to NetSuite look like that, you are on SOAP. Native REST web services use plain JSON over standard HTTP verbs.

Build a short inventory from this: every integration, the system it connects, the WSDL version it targets, and how business-critical it is. That inventory is the input to everything below.

The migration path: SOAP to REST

The destination for most SOAP integrations is REST web services with OAuth 2.0. For the minority of cases where REST does not reach (a record type it does not yet cover, or an operation that needs custom server-side logic), the destination is a RESTlet. The short version: REST for standard records and queries, a RESTlet when you need logic to run inside NetSuite. The integration guide walks through that choice in full.

Three things change in the move, and each is a place migrations go wrong if you treat it as a like-for-like swap.

1. The calls themselves: XML operations become HTTP verbs

A SOAP get, add, update, or search becomes a standard REST request. Reading a sales order, which in SOAP is a get against a RecordRef, becomes:

GET https://{accountId}.suitetalk.api.netsuite.com/services/rest/record/v1/salesOrder/123
Authorization: Bearer {access_token}

Creating a record is a POST with a JSON body instead of a SOAP add:

POST https://{accountId}.suitetalk.api.netsuite.com/services/rest/record/v1/salesOrder
Authorization: Bearer {access_token}
Content-Type: application/json
 
{
  "entity": { "id": "456" },
  "item": {
    "items": [
      { "item": { "id": "789" }, "quantity": 2 }
    ]
  }
}

One genuine improvement: REST supports PATCH, so an update can send only the fields that changed rather than reading, mutating, and resubmitting a whole record the way SOAP update flows often did.

2. Reads: saved searches become SuiteQL

SOAP integrations frequently lean on saved searches run through the search operation. On REST, the equivalent for ad hoc and bulk reads is SuiteQL, a SQL-like query language you POST to a dedicated endpoint:

POST https://{accountId}.suitetalk.api.netsuite.com/services/rest/query/v1/suiteql
Authorization: Bearer {access_token}
Content-Type: application/json
Prefer: transient
 
{
  "q": "SELECT id, tranid, entity, total FROM transaction WHERE type = 'SalesOrd' AND trandate >= '01/01/2026'"
}

SuiteQL gives you multi-table joins, filtering, and paging, and it is usually faster to iterate on than maintaining a library of saved searches. The Prefer: transient header is required. Budget time to rewrite each search as a query and to confirm the results match the old output exactly before you trust it.

3. Authentication: request signing becomes bearer tokens

SOAP integrations authenticate with Token-Based Authentication (TBA), which signs each request. REST web services use OAuth 2.0, where you exchange credentials for a bearer token and send that token on each call. OAuth 2.0 is simpler day to day, but it has its own failure modes (a refresh token that expires after seven days of non-use returning invalid_grant, a role missing the right permission, an integration record without the correct scope). Those are common causes of the "it just stopped working" ticket, and they are covered in how to diagnose a NetSuite integration that fails silently.

When REST does not reach: a RESTlet

If your inventory turns up a record type REST does not cover, or an operation that needs validation or orchestration inside NetSuite, the answer is a RESTlet: a SuiteScript endpoint you control. Keep it thin, just the logic REST cannot do natively:

/**
 * @NApiVersion 2.1
 * @NScriptType Restlet
 * @NModuleScope SameAccount
 */
define(['N/record', 'N/error'], (record, error) => {
  const post = (body) => {
    if (!body.salesOrderId) {
      throw error.create({ name: 'MISSING_PARAM', message: 'salesOrderId is required' });
    }
    // Custom server-side logic REST cannot express: load, validate, transform, save.
    const so = record.load({ type: record.Type.SALES_ORDER, id: body.salesOrderId });
    so.setValue({ fieldId: 'memo', value: body.memo });
    const id = so.save();
    return { id, success: true };
  };
 
  return { post };
});

A migration plan you can actually run

You have until the 2028.2 release, so use the runway to do this in order rather than all at once.

1. Inventory. List every SOAP integration, its WSDL version, the system on the other end, and how critical it is. You built the start of this in the section above.
2. Prioritise. Anything pinned to a WSDL older than 2025.2 is on borrowed time, so move those first. Then order the rest by business risk, not by how easy they look.
3. Check coverage before you commit. For each integration, confirm REST covers the record types and operations it uses. Where it does not, plan a RESTlet now so it does not ambush you mid-cutover.
4. Rebuild with failure designed in. A migration is the moment to add what the original SOAP integration probably lacked: error handling that surfaces the error, alerting so you hear about a failed sync before the business does, and idempotency so a retried message does not create a duplicate record.
5. Run in parallel, then reconcile. Stand the REST integration up alongside the SOAP one, compare their output against real sandbox data, and reconcile until they agree. Only then cut over.
6. Decommission the SOAP path once the REST integration has run clean for a full business cycle.

The single biggest mistake here is treating migration as a mechanical translation of calls. The integrations worth keeping are worth rebuilding properly, because the cutover is the cheapest opportunity you will get to fix the reliability problems the old one carried.

Common pitfalls

• Assuming full REST parity. REST coverage is broad and growing, but it is not yet everything SOAP reached. Check each record type before you assume the swap is clean.
• Translating saved searches one to one. SuiteQL is more capable, but the results are not always byte-identical to the old saved search. Validate against known output.
• Leaving auth to the end. The TBA to OAuth 2.0 change is its own piece of work with its own error modes. Plan it as a first-class task, not a footnote.
• Cutting over without a parallel run. Without running both side by side and reconciling, you find the gaps in production, in front of the business.

Frequently asked questions

When exactly does NetSuite SOAP stop working? With the 2028.2 release, per Oracle's roadmap, SOAP is removed and existing SOAP integrations stop working. Before that, the 2027.1 release narrows support to only the 2025.2 endpoint. Confirm the dates against the current NetSuite release notes when you plan, because the schedule is Oracle's to change.

Do my existing SOAP integrations break now? No. They continue to be supported until the 2028.2 release. The pressing action today is to stop building new SOAP integrations and to start planning the migration of the ones you depend on, not to halt anything that is working.

What replaces SuiteTalk SOAP? REST web services with OAuth 2.0 is the intended replacement for standard records and queries. For operations that need custom server-side logic, or record types REST does not yet cover, a RESTlet fills the gap.

Can I just keep using SOAP until 2028.2 and migrate then? You can, but it is the riskiest option. If you wait, you may discover during the rebuild that REST does not cover one of your record types, turning a planned migration into an unplanned RESTlet project under a hard deadline. Migrating early, with a parallel run, removes that pressure.

If you are running NetSuite integrations on SuiteTalk SOAP and want them inventoried, prioritised, and rebuilt on REST before the deadline, that is one of the core services I offer. New integration, or a tired one rebuilt to last: it starts with a short technical review of what you have today.