SuiteScript 2026.1: Custom Tool overhaul, PATCH in N/http(s), binary uploads, and a 2.0-as-2.1 runtime toggle

2026.1 is a meaty SuiteScript release. The biggest churn is around custom tool scripts (the script type that backs the NetSuite AI Connector Service) — the SDF object is renamed, the scriptid prefix changes, and entry points must now be async. There are also several smaller but useful runtime additions: PATCH support in N/http and N/https, binary uploads via https.post, an SFTP existence-check fallback, a company-wide toggle to execute 2.0 server scripts on the 2.1 engine, and GPT-OSS in N/llm.

Custom Tool Scripts: breaking SDF + script changes

If you have any existing custom tool scripts, they will need to be updated to keep working with the new tooling and to gain execution log support (which previously was not available for this script type). The changes are not additive — the SDF object itself is renamed.

Script-side changes:

• Add the JSDoc tag @NScriptType CustomTool at the top of the script.
• Declare every entry point function for tool methods as async.

SDF XML changes:

• Rename the SDF object element from tool to toolset.
• Change the scriptid prefix from customtool_ to custtoolset_.
• Rename the attribute exposeto3rdpartyagents to exposetoaiconnector.

Once updated, executions show up under Customization > Scripting > Script Execution Logs, the same place every other script type logs to. There is also a new Customization > Scripting > Custom Tools page that lists toolsets from both SuiteApps and account customization projects (ACPs), shows the individual tools and their required permissions, and lets you delete ACP toolsets directly. SuiteApp toolsets must still be removed by uninstalling the SuiteApp.

Oracle has published an updated sample project in the MCP-Sample-Tools directory of the SuiteCloud Project Repository on the Oracle Samples GitHub, and a SuiteAnswers walkthrough at ID 1024036.

N/http and N/https now support PATCH

The Method enum on both modules now includes PATCH. You can pass http.Method.PATCH or https.Method.PATCH to:

• http.request(options)
• https.request(options)
• https.requestSuitelet(options)
• clientCertificate.request(options)

This finally unblocks calls to REST APIs that require PATCH semantics (including NetSuite's own /services/rest/record/v1/ endpoints) without having to fall back to a workaround. If the target API doesn't allow PATCH on a given resource, NetSuite surfaces the standard HTTP 405 Method Not Allowed back to the script.

Binary file uploads via N/https

You can now POST a binary file from SuiteScript using N/https. The pattern is:

1. Convert the file's contents to a Uint8Array using Uint8Array.fromBase64().
2. Pass the resulting Uint8Array as options.body to https.post(options).

Limit: one file per request. The release note doesn't mention multipart support, so if you need to combine a binary payload with form fields you'll still need to construct the multipart body yourself. The note also doesn't specify a new size limit — verify against your existing N/https payload caps before relying on this for large files.

New SFTP preference: use LIST instead of STAT

If you've ever hit a phantom FILE_ALREADY_EXISTS error when uploading to a third-party SFTP server with N/sftp, this is the fix. The N/sftp module's existence check defaults to the SFTP STAT command, and some servers respond incorrectly to it.

A new General Preference, SFTP: Use LIST to Test That a File Exists, switches the check from STAT to LIST. Set it at Setup > Company > General Preferences. The Set Up Company permission is required. Oracle's note says LIST is used "without sacrificing performance," but treat that as marketing — only enable it on accounts where you've actually seen the false-positive errors.

Run SuiteScript 2.0 server scripts on the 2.1 runtime

A new company preference, Execute SuiteScript 2.0 Server Scripts as 2.1, also lives at Setup > Company > General Preferences. When enabled, any 2.0 server script that the platform recognizes as 2.1-compatible will be executed by the 2.1 runtime engine instead of the 2.0 engine.

Important caveats from the release note:

• Only scripts recognized as compatible are affected. Incompatible scripts continue to run as 2.0 silently.
• Script records whose Execute As field is explicitly set to 2.0 are unaffected and continue running as 2.0.
• The release note does not document how compatibility is determined, nor does it mention any per-script log signal indicating which engine actually ran a given execution. Verify behavior in a sandbox before flipping this in production.

This is best treated as a validation tool: turn it on in a sandbox, run your regression suite, and if a script behaves correctly, update its @NApiVersion annotation to 2.1 to lock in the runtime.

N/llm gains GPT-OSS

The N/llm module now accepts OpenAI's GPT-OSS model in llm.generateText(options), llm.generateTextStreamed(options), and their promise variants. The model is exposed through llm.ModelFamily. The release note does not state governance cost, token limits, or whether GPT-OSS counts against the same free-monthly-usage allotment as the existing models — check llm.ModelFamily documentation before budgeting against it.

What to do

1. Audit custom tool scripts. Grep your SDF projects for customtool_ scriptids and exposeto3rdpartyagents. Every match needs the rename. Update the script files to add @NScriptType CustomTool and convert tool entry points to async functions. Redeploy via SDF.
2. Verify the new Custom Tools page at Customization > Scripting > Custom Tools after redeploying, and confirm execution logs now appear under Script Execution Logs.
3. Replace any PATCH workarounds. If you have scripts that fake PATCH via X-HTTP-Method-Override headers or other hacks against REST APIs, switch them to https.Method.PATCH.
4. Refactor binary upload code. If you currently chunk or base64-embed binaries through Suitelet proxies, evaluate whether the new Uint8Array body on https.post can replace it. Remember the one-file-per-request limit.
5. Only flip the SFTP LIST preference if you have an open ticket about FILE_ALREADY_EXISTS on a specific server. Don't enable it account-wide as a precaution.
6. Pilot the 2.0-as-2.1 preference in a sandbox. Run your full server-script regression suite. For any script that passes, change its @NApiVersion to 2.1 and remove it from the implicit-upgrade pool.
7. If you use N/llm, review llm.ModelFamily for the GPT-OSS identifier and confirm pricing/limits before pointing production workloads at it.