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.

Route	Best for	How to get it
Apideck temporary shared sandbox	Getting your first API call working quickly	Available to customers on an enterprise contract — request access via Apideck Support.
Apideck-assisted NetSuite account	You need your own long-lived NetSuite environment	See section 2 below — Apideck can introduce you to NetSuite.
A consumer's own sandbox	End-to-end integration testing against real configuration	Your 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 and an expected timeline before you commit to a plan.

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

There is no NetSuite app for you to register. NetSuite authenticates with Token-Based Authentication (TBA), which has no OAuth app-registration screen, no consent redirect and no callback URL — so there is no developer-portal application on your side, and nothing for you to create before onboarding your first consumer. Your own setup is limited to enabling and configuring the connector in the Apideck Dashboard.

Credentials come from two places:

• Apideck supplies the Integration Record credentials. On the recommended bundle route (below), the Consumer Key and Consumer Secret come from the pre-configured Apideck Unify Integration Record that the Apideck Integration Connectivity bundle installs — your consumers leave both fields blank, and you never handle them.
• Each consumer supplies their own account credentials. The Account ID, Token ID and Token Secret (labeled "Access token ID" / "Access token secret" in the connection form) always come from the consumer's own NetSuite account. Apideck holds no shared production NetSuite login, so every connection is scoped to that consumer's account and role.

Requirement	Detail
Account	A NetSuite account
Features	Token-Based Authentication and SuiteTalk (Web Services) both enabled on the account
Permissions	Administrator, 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-subsidiary	OneWorld (multi-subsidiary) accounts are served by a single connection, scoped with the Default Subsidiary setting — 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.

Under-permissioning is worth designing against, because it does not always look like an error: a filtered list call made by a role that is missing the per-resource transaction permission returns 200 OK with an empty data array rather than failing. If a consumer's connection validates but one resource stays persistently empty, check that role's permissions before you look at anything else.

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.

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

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

Path	Credentials 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.
Manual	5 — 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. On either path the access token itself is created by hand in the consumer's NetSuite UI.

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.

Once created, a TBA token does not expire on a clock, so your integration needs no token-refresh logic. It can still be invalidated: the consumer regenerating or revoking the token, deleting the integration record, or a sandbox refresh (tokens do not survive one) all end the connection and require re-onboarding.

SuiteTax accounts

SuiteTax is supported, through a connection setting. Because SuiteTax replaces NetSuite's legacy tax records, the connector has to know which model an account uses: the connection carries a SuiteTax enabled (suitetax_enabled) setting, and when it is on, tax-rate operations are served from NetSuite's sales tax items instead of the legacy tax records.

Treat this as an onboarding question rather than a runtime detail — a connection on a SuiteTax account that leaves the setting off will not return correct tax data. Ask the consumer (or their NetSuite administrator) whether SuiteTax is enabled on the account, and set the value accordingly.

The connection carries a few other optional settings you may want to collect while onboarding: the integration user's time zone, a default File Cabinet folder for attachment uploads (see the attachments guide in this section), and the RESTlet script and deployment IDs required for the opt-in bank-feed resources. All of them are listed, with the screens to find them in, in the Connection Guide.

NetSuite governs by concurrency, not request rate

NetSuite meters SOAP, REST and RESTlet traffic against a single per-account limit on concurrent requests rather than a requests-per-minute quota, and that budget is shared with every other integration, script and user session in the consumer's account. Two consequences for how you design your integration:

• Tune parallelism, not delay. Burst fan-out — a page of invoices followed by a wave of simultaneous per-ID reads — is what reaches the ceiling; a steady, low-concurrency stream generally does not.
• The ceiling belongs to the consumer. It follows their NetSuite service tier and SuiteCloud Plus licensing, so it differs per consumer and cannot be raised from the Apideck side. The per-tier figures are on the Overview tab, and Oracle documents the model in its concurrency governance documentation.

Apideck retries a request that NetSuite rejects for exceeding the limit, so an occasional collision typically shows up as latency rather than as an error — though sustained overload can still surface failures to handle.

OneWorld (multi-subsidiary) accounts

One connection can serve a whole OneWorld account. Which legal entity a connection reads is a setting rather than a separate connection: the connection carries an optional Default Subsidiary (subsidiary_id) that scopes list reads and the two financial reports to a single subsidiary, and your integration can override it per request.

Precedence, highest first:

Where the scope comes from	What it scopes
filter[subsidiary_id] on the request	that subsidiary, for that one call
The x-apideck-company-id header	that subsidiary, for that one call
The connection's Default Subsidiary setting	that subsidiary, for every call on the connection
None of the above, or All subsidiaries	every subsidiary in the account

That gives you two designs, and they compose: set a Default Subsidiary at onboarding when a consumer works in one entity, and send x-apideck-company-id per request when your product lets them switch entities. Discover the ids to send with GET /accounting/companies, which lists every subsidiary in the account regardless of the connection's own scope. The subsidiaries resource remains available too, and carries the hierarchy.

Four behaviours to design around:

• A parent subsidiary does not include its children. For transactions and entities NetSuite matches the selected subsidiary exactly, so scoping to a regional parent returns only what is booked to that parent, not the entities beneath it. For group-wide data, leave the scope as All subsidiaries rather than selecting the top of the tree. Four reference-data lists are the exception, and they run the other way: a department, location, class (tracking category) or expense category marked "include children" in NetSuite is returned for every descendant subsidiary, so a child-scoped connection still sees those parent-level records.
• company-info always resolves to the root subsidiary — the one with no parent — whatever the setting or the header says. Read a specific entity through subsidiaries instead — companies is a list-only view that returns each entity's id and name.
• Writes are never scoped. The subsidiary of a record you create or update comes from the request body, or is derived by NetSuite from the record's customer or vendor. A scoped connection can therefore create a record its own list requests will not return, so set the subsidiary explicitly on writes rather than relying on the connection's scope.
• The subsidiary picker needs saved credentials first. The Default Subsidiary options are loaded live from the consumer's own NetSuite account, so the Account ID and token fields must be saved before a subsidiary can be chosen. Order your onboarding steps accordingly if you build your own UI over Vault.

Scoping covers transactions, entities, reference data and the financial reports. A few lists NetSuite keeps at account level — currencies, payment methods, accounting periods, subsidiaries, attachments, server time and the bank-feed resources — always come back in full, and tax-rates and expenses are exceptions as well. The per-resource detail lives on the Gotchas tab; check it for any resource where per-entity isolation is a requirement you are committing to.

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

• Send consumers to the Connection Guide.
• Review the connector's limitations on the Overview and Gotchas tabs before scoping, and confirm the suitetax_enabled value for every account you onboard.
• Questions about access or the NetSuite introduction: partners@apideck.com. Technical questions: Apideck Support.