NetSuite’s New https.requestSuitelet(options) Method — What You Need to Know

In the evolving landscape of customisation within NetSuite’s SuiteCloud platform, the introduction of the https.requestSuitelet(options) method marks a meaningful shift in how scripts can invoke Suitelets internally. If you’re a NetSuite developer, integration lead or SuiteScript specialist, here’s what you should understand — and prepare for.

What is https.requestSuitelet(options)?

Within the N/https module of NetSuite’s SuiteScript 2.x API, the https.requestSuitelet(options) method allows a script (client- or server-side) to send an HTTPS request to a Suitelet and receive the response object.

Key details:

• You must supply scriptId (the Script record ID) and deploymentId (the Script Deployment record ID) in the options object.
• Additional optional parameters: method, body, headers, urlParams.
• The method returns a https.ClientResponse object.

Why this matters for developers

For many years, scripts calling Suitelets would often resort to url.resolveScript() to build external URLs or to https.request() for generic HTTP calls. The dedicated https.requestSuitelet() method brings in several benefits:

• Cleaner, purpose-built API for Suitelet invocation (within NetSuite authenticated context).
• Reduced risk of external endpoint issues (since this is internal calling).
• Better alignment with governance and security policies.

If you are working on custom logic (such as a Suitelet acting as a “middle-man” for integrations or internal dashboards), this method helps you formalise the invocation pattern.

Important changes — What has shifted (and what you’ll need to do)

As of the release notes for NetSuite 2024.2, the behaviour of this API has changed significantly.

Key change items:

• Effective June 13 2024, https.requestSuitelet() will be supported only for internal URLs in “trusted contexts”. The option.external parameter is no longer required and will default to internal behaviour.
• As of July 30 2024, the option.external=true setting will stop functioning — calls relying on an external URL to a Suitelet marked “Available Without Login” will fail
• The deprecation of using external URLs via https.requestSuitelet() in an unauthenticated or “untrusted” context: Links to Suitelets meant for public access (customers/shoppers) via external URL should instead rely on appropriate alternatives (e.g., RESTlets, or separate public pages).

What you should do:

• Audit your codebase for any usage of https.requestSuitelet(options) where options.external = true or where you are invoking an external URL for a Suitelet.
• Convert those calls to internal-URL contexts where possible (i.e., authenticated users only).
• For truly external/public Suitelet access (e.g., “Available Without Login”), consider using url.resolveScript() and redirecting clients to the Suitelet’s External URL or switch to a RESTlet if appropriate (since RESTlets are designed for external integrations).
• Update documentation and internal coding-standards so that future scripts avoid the deprecated patterns.
• Make sure any hard-coded external Suitelet URL (with &h= parameter) is reviewed — the format changed (to &ns-at=) as part of the same release.

Practical code snippet

Below is a simple example of how you might use https.requestSuitelet(options) in SuiteScript 2.x (server-side):

define(['N/https'], function(https) {

  function callMySuitelet() {
    const response = https.requestSuitelet({
      scriptId: 'customscript_my_suitelet',
      deploymentId: 'customdeploy_my_suitelet_deploy',
      urlParams: {
        recordId: 123,
        action: 'getData'
      },
      headers: {
        'Content-Type': 'application/json'
      }
      // No option.external needed for internal context
    });
    const body = response.body;
    // handle the response accordingly
    log.debug('Suitelet Response', body);
  }

  return {
    execute: callMySuitelet
  };
});
        

Note: If you were previously using option.external:true to call a Suitelet in a “public/un-login” scenario, you’ll need to review and refactor.

Why this change is beneficial — and what to watch out for

Benefits:

• Improved security: by restricting requestSuitelet to authenticated/internal calls, NetSuite strengthens the boundary around what can be invoked programmatically.
• Better governance: you avoid creating “public” Suitelets that your code calls without login — reducing risk of loops, unauthorized access, API mis-use.
• Clarity of intent: using a specific API for Suitelet invocation makes the architecture more explicit (rather than general HTTP calls).

Cautions/Watch-outs:

• If you have integrations or automation that were using Suitelets externally (or via external URL) and now call them via https.requestSuitelet, you may face runtime failures after July 30 2024 if not updated.
• For truly external consumers (e.g., website forms, external systems), consider whether a RESTlet or SuiteTalk integration is more appropriate (Suitelets are not designed for high-volume, public integration endpoints). See the Help topic note: “Suitelets are not intended for use in systems-integration use cases. RESTlets are intended for this.”
• Hard-coded URLs (with &h= token) must be evaluated and replaced — otherwise link breaks may happen.

Final thoughts

The update to https.requestSuitelet(options) is a subtle but important change in how NetSuite customisations should be architected. By moving toward internal-only invocations for Suitelets and deprecating external invocation via this method, NetSuite is nudging developers toward clearer boundaries between internal logic, public forms, and integration endpoints.

For your team, this is an opportunity to review and strengthen your Suitelet patterns, clean up legacy URL usage, and ensure that your payment-proposal Suitelet remains robust, secure and future-proof.