Announcement: n8n NetSuite Community Node is now LIVE! 🎉

[refactor_monkey]

Hey Community!

NetSuite Community Node has graduated from BETA and is now an n8n Verified Community Node!

It is now available for all editions of n8n:

• n8n Cloud
• Self Hosted n8n instances

Features

• Connect to NetSuite using REST API credentials
• Full support for 150+ NetSuite standard record types like Customers, InventoryItems, SalesOrders, etc…
• Handles required/optional fields and nested collections
• Automatically extracts new record IDs from NetSuite responses
• Includes debug mode for detailed request/response output
• Custom Fields support - Work with custom entity fields (custentity_*) and body fields (custbody_*)
• Custom Records integration - Create, read, update, and delete custom record types
• SuiteQL queries - Execute powerful SQL-like queries against NetSuite data with full SuiteQL syntax support

Screenshots of NetSuite REST node in Action

150+ NetSuite Standard Record types with all the fields including custom fields:

SuiteQL and Debug Mode:

Custom Records and Custom Fields:

Upcoming Features

• Custom Fields support for line fields like Sales Order line items
• Triggers

n8n Cloud Installation

NOTE: Only instance owners and admins can enable and install verified community nodes. Once installed, all members of your n8n Cloud instance can use the node in their workflows

1. Go to your n8n Cloud Admin Panel and ensure Verified Community Nodes is toggled on.
   
   
   
   
   
2. Open your workflow in n8n Cloud and open the Nodes Panel (click + or press n).
3. Search for NetSuite REST (or n8n-nodes-netsuite-rest).
4. Under the More from the community section at the bottom, select the NetSuite REST node.

n8n Self-Hosted Installation

NOTE: Only owner can install and manage community nodes from npm. The instance owner is the person who sets up and manages user management.

To install a community node from npm:

1. Go to Settings > Community Nodes.
2. Select Install.
3. Enter the npm package name ‘n8n-nodes-netsuite-rest’.
4. Agree to the risks of using community nodes: select I understand the risks of installing unverified code from a public source.
5. Select Install. n8n installs the node, and returns to the Community Nodes list in Settings.

Full n8n Installation Instructions

Usage

1. Install and configure your NetSuite REST API credentials in n8n.
2. Add the NetSuite REST Test node to your workflow.
3. Select the resource and operation (e.g., Customer > Insert record).
4. Fill in required fields and run the workflow.
5. The node will return NetSuite API responses, including new record IDs for POST operations.

Example

Add a new customer:

1. Set resource to Customer and operation to Insert record.
2. Provide required, optional and custom fields (e.g., Email).
3. On success, the response will include the new customer ID extracted from the NetSuite location header.

NetSuite Connector Config

NetSuite Integration Record

You must create an integration record in NetSuite and enable OAuth 2.0.

For Redirect URI use the OAuth Redirect Url from n8n Credentials. See next section.

N8n NetSuite Credential Fields Explained

Note: For NetSuite sandboxes, your account ID is usually formatted as 1234567_SB1 in the NetSuite UI, but in URLs it must be lowercase and use a dash: 1234567-sb1.

When creating your NetSuite REST API credential in n8n for OAuth 2.0, fill in the following fields:

• Client ID: Your NetSuite application (integration record) Client ID
• Client Secret: Your NetSuite application (integration record) Client Secret
• Account Subdomain: Get account subdomain from NetSuite url after login into your NetSuite account. Usually https://[account-subdomain].app.netsuite.com

Configuration Tips

• Ensure your NetSuite account has SuiteTalk REST Web Services enabled.
• Permissions for the integration user must include access to the required records and REST web services.

Known Issues and workarounds

• Entering date into date field and submitting operation may throw error. NetSuite expects dates in ISO 8601 format (like ‘2025-09-25T14:00:00Z’), but n8n field with Date Selector returns format like ‘2025-09-25T14:00:00’

  Workaround: use n8n expression to format date to conform to ISO

{{ '2025-09-25T14:00:00'+'Z' }}   --> 2025-09-25T14:00:00Z
{{ DateTime.fromISO('2025-09-25T14:00:00').toUTC().toISO() }}  --> 2025-09-25T18:00:00.000Z
{{ DateTime.fromISO('2025-09-25T14:00:00').toISO() }} --> 2025-09-25T14:00:00.000-04:00

• Search is not available when adding new step using ". This seems to be limitation for community N8n Nodes.

Workaround: use browser search, for example in chrome press Ctrl-F and name of operation.

• When filling Custom Fields - can’t auto select field type based on NetSuite meta data. It is related to n8n bug where loadOptionsDependsOn is not working inside FixedCollection

  Workaround: select field type manually

  

As always, feedback is welcome!

Package: https://www.npmjs.com/package/n8n-nodes-netsuite-rest

[liuxueqi0044]

Congratulations — supporting 150+ record types and reaching Verified Community Node status is no tiny milestone. The custom records and SuiteQL support make this much more useful than a thin REST wrapper.

One reliability question: how does the node currently surface NetSuite governance/rate-limit responses and ambiguous POST timeouts? The awkward case is a Sales Order being created successfully, while the response is lost before n8n receives it. A blind workflow retry can then create a second order. APIs do enjoy saving their most charming gremlins for production

A few additions that could make recovery safer over time:

• Preserve the HTTP status, Retry-After/governance details, and request or correlation identifiers in a structured error output.
• Where a NetSuite record supports it, make externalId easy to use as an idempotency-friendly business key.
• You already extract the ID from the Location header; optionally returning the raw Location/request metadata as well would help reconciliation after uncertain results.
• For long SuiteQL exports, expose enough pagination state that a workflow can checkpoint and resume instead of restarting from page one.

None of these need to block the release, of course. They would just make the node especially strong for production workflows where retries and partial failures eventually stop being theoretical. Nice work.

[refactor_monkey]

Thanks - really appreciate the thoughtful, specific feedback. I went through each of these against the actual code rather than just the feature list, so here’s where things genuinely stand:

1. Structured errors with retry/rate-limit info - this is a real gap, not currently covered by anything (including Debug Mode, which just dumps the raw error object rather than extracting HTTP status, Retry-After, etc. into a clean shape). On the roadmap.
   One correction to make on our end too: NetSuite’s REST API doesn’t actually return any kind of correlation/request-ID header - so if you need something to cross-reference calls in your own logs, that’d have to be something we generate and echo back ourselves, which we’re also considering alongside the above.

2. Duplicate order prevention on retry - this is already fully solved today, just not obvious. NetSuite exposes a dedicated “Insert or update record” operation per resource (including Sales Order) that upserts by external ID rather than internal ID. Set your own external ID on the order, use that operation instead of plain “Insert record,” and a retry with the same external ID updates the existing record instead of creating a duplicate - this is REST-standard idempotent behavior (tied to PUT on NetSuite’s side), not a workaround. I’ll make sure this is called out more clearly in the README, since right now you’d only find it by exploring the operation list.

3. Raw metadata for reconciliation - partially available today: Debug Mode captures full response headers/status for every call. Two honest caveats: it has to be turned on before the run (so it won’t help retroactively for something you need to reconcile later), and when it’s on without continueOnFail, the node stops after the first item that errors - a side effect worth knowing about before relying on it. Making this available by default, without those tradeoffs, is something we’re planning.

4. Resumable SuiteQL pagination - also already fully supported. limit/offset are available as request parameters, and the response passes through NetSuite’s own hasMore, offset, totalResults, and links fields untouched. Nothing to build here.

Appreciate you pushing on the production-hardening side of this - genuinely useful signal for what to prioritize next.

[liuxueqi0044]

Thanks for taking the time to check every point against the actual code — your response was genuinely helpful. The clarification on external-ID upserts and SuiteQL pagination helped me understand the node better, and I appreciate the correction about correlation IDs.
I’m still early in my career and trying to turn my projects and reliability work into my first serious remote opportunity. It has been harder than I expected, so having an experienced maintainer take the analysis seriously was genuinely encouraging.
The structured error output seems like the most valuable remaining gap. From your perspective, what would be most useful as a next contribution: a concrete error-contract proposal and tests, clearer documentation around safe upserts and pagination, or a small reference reliability workflow?
I’d really value your advice, and I’d be glad to stay in touch.

[refactor_monkey]

Of the three, documentation is the one I’d point to as most valuable right now. The error-contract work has open questions on our end we haven’t resolved yet (what NetSuite actually returns on a failed/rate-limited request), so that’s premature to build on. The docs gap is real and unblocked.

Two things worth covering: (1) using “Insert or update record” with an external ID for safe retries - worth explaining why it’s safe (tied to PUT semantics, same external ID updates instead of duplicating), maybe using Sales Order as the example since that’s what you raised; (2) SuiteQL pagination - that limit/offset are available as parameters and the response passes through NetSuite’s own hasMore/offset/totalResults untouched.

Appreciate you asking - good luck with the search either way.

[refactor_monkey]

Quick update:

n8n-nodes-netsuite-rest 0.1.15 is now on npm. It only changes the package description, keywords and README, so there’s nothing to upgrade for.

We also wrote a setup guide for connecting n8n to NetSuite: how the OAuth 2.0 connection works, running SuiteQL queries, and outlines of a few common workflows (Shopify order sync, a daily inventory alert, overdue invoice escalation):

n8n NetSuite Integration: TBA Auth, SuiteQL & Workflows

It works on n8n Cloud and self-hosted, as before. If you hit something the guide doesn’t cover, reply here or open an issue on GitHub:

Issues · entech-code/n8n-nodes-netsuite-rest