NetSuite – Configuration Guide

Service ID: netsuite

NetSuite is the leading integrated cloud business software suite, including business accounting, ERP, CRM and ecommerce software.

Getting a NetSuite account to build against

This guide is for you, the application owner — the team integrating NetSuite through Apideck. It covers how to obtain a NetSuite environment to develop and test against, including the route where Apideck can help, and what each of your consumers needs before they can connect.

The step-by-step screens your consumers work through live in the Connection Guide — this guide does not repeat them.

1. Choosing a NetSuite environment for development

NetSuite does not offer self-service developer trials: Oracle does not hand out direct trial accounts, so you cannot simply sign up. There are three practical routes.

RouteBest forHow to get it
Apideck temporary shared sandboxGetting your first API call working quicklyAvailable to customers on an enterprise contract — request access via Apideck Support.
Apideck-assisted NetSuite accountYou need your own long-lived NetSuite environmentSee section 2 below — Apideck can introduce you to NetSuite.
A consumer's own sandboxEnd-to-end integration testing against real configurationYour consumer creates credentials in their sandbox and supplies them to you.

A NetSuite Partner Trial account is also possible if you join the (optional) NetSuite Partner Program — these are time-limited and are obtained through NetSuite, not through Apideck.

Partnership with NetSuite is not required to use the connector. The Partner Program matters only if you want an extended trial environment of your own.

2. Getting a NetSuite account or sandbox through Apideck

Apideck is in contact with NetSuite, and we can assist if you don't have access to a NetSuite account or need your own sandbox environment for testing the integration.

If you're interested, email partners@apideck.com with:

  • your company's legal name
  • the name of the primary contact
  • that contact's email address

NetSuite applies a fee for sandbox accounts. This is charged by NetSuite, not by Apideck, and is separate from your Apideck subscription. Ask us for the current terms before you commit to a timeline.

This route is distinct from the temporary shared sandbox in section 1: that sandbox is an Apideck environment made available to enterprise customers for evaluation, while this route gets you your own NetSuite environment.

3. What each of your consumers needs

Every consumer connects with credentials from their own NetSuite account — there is no shared production credential, and Apideck does not provide production credentials for NetSuite.

RequirementDetail
AccountA NetSuite account with SuiteTalk (Web Services) enabled
FeaturesToken-Based Authentication and SuiteTalk (Web Services) both enabled on the account
PermissionsAdministrator, or a role carrying Log in using Access Tokens, SOAP Web Services and REST Web Services, plus the Accounting Lists, Accounting Management, Deleted Records and Other Lists setup permissions, and Lists → Subsidiaries
Multi-subsidiaryOneWorld (multi-subsidiary) accounts need extra planning — see the note below

Both web-services permissions are needed, not just SOAP: Apideck validates every connection with a SOAP call, while filtered list calls run as SuiteQL over REST. Financial reports (Profit & Loss, Balance Sheet) additionally need Financial Statements under Reports. Lists → Subsidiaries is required on every account, not only OneWorld ones — company-info is served by a subsidiary search, so omitting it breaks that endpoint on a single-subsidiary account too. The full permission set, and the screens to set it in, are in the Connection Guide.

If either feature cannot be enabled, it is a question for the consumer's own NetSuite administrator or account team — Apideck cannot enable NetSuite features on their behalf.

OneWorld (multi-subsidiary) accounts

Scope this one carefully before promising it. The NetSuite connector does not support switching company context per request: Apideck models NetSuite as one connection per subsidiary, so a connection covers whatever the credentials' role can see rather than one selectable subsidiary. Note this is an Apideck modelling choice — a top-level NetSuite token can itself span subsidiaries.

Two practical consequences:

  • On a OneWorld account, company-info normally resolves to the root subsidiary (the one with no parent), not to a subsidiary of your choosing.
  • If a consumer needs data isolated per subsidiary, plan for one connection per subsidiary, under a role whose subsidiary access is scoped accordingly in NetSuite.

The subsidiary hierarchy itself is readable — subsidiaries is a supported resource — so you can list a consumer's subsidiaries even though you cannot switch between them on a single connection.

Point consumers at the bundle — it reduces what they hand over

Apideck publishes an Integration Connectivity bundle (ID 705521) that installs a pre-configured Apideck Unify role and Integration Record in about a minute. Which path your consumers take changes how many credentials they need to produce:

PathCredentials the consumer supplies
Bundle (recommended)3 — Account ID, Token ID, Token Secret. Consumer Key and Secret are left blank; they come from the Apideck Unify Integration Record the bundle installs.
Manual5 — Account ID, Token ID, Token Secret, plus Consumer Key and Consumer Secret from an Integration Record they create themselves.

Both paths are documented for consumers in the Connection Guide, which also covers installing the bundle. Recommending the bundle is worth doing: it is the shorter path, it installs a role scoped to exactly the permissions the connector needs, and it removes the two credentials that NetSuite displays only once.

NetSuite shows the Consumer Key/Secret and the Token ID/Secret once each, at creation. They cannot be retrieved afterwards — a consumer who loses them has to regenerate them in NetSuite. Build your onboarding flow so these are captured at the moment they appear.

4. Moving from sandbox to production

There is no separate credential type for sandbox and production — the Account ID decides which instance is reached, and sandbox IDs carry a suffix such as _SB1, _SB2 or _SB3. Promoting an integration is therefore a matter of swapping the connection's credentials for ones generated in the production account, not requesting a different kind of key.

Two consequences worth planning for:

  • Your consumers will go through token creation twice if they test in a sandbox first, so the onboarding flow needs to handle re-entering credentials for an existing connection.
  • Tokens do not survive a sandbox refresh — see the Overview tab's environment notes. If a consumer refreshes sandboxes on a schedule, expect to re-onboard that connection each time.

The full task split between you, your consumers and Apideck is on the Overview tab.

Next steps