NetSuiteFree referencePDF, Excel, Word exportNetSuiteAll NetSuite tools

NetSuite Sandbox vs Production: Differences and What to Change

A NetSuite sandbox is a separate account copied from production for development and testing, with its own account ID, hostnames, tokens and settings. This table lists what differs and what to change so integrations, scripts and email behave correctly in each.

Download:

Area	Production	Sandbox	What to do
Account ID (realm, SuiteQL, SDF)	1234567	1234567_SB1 (SB2, SB3 for further sandboxes)	Store the account ID per environment in integration config. Use upper case _SB1 in OAuth 1.0 realm.
Account ID in hostnames	1234567	1234567-sb1 (lower case, hyphen)	Never derive the hostname by string replace on the realm; read Company URLs.
UI URL	https://1234567.app.netsuite.com	https://1234567-sb1.app.netsuite.com	Bookmark both; check the account name banner before editing.
REST and SOAP Web Services host	https://1234567.suitetalk.api.netsuite.com	https://1234567-sb1.suitetalk.api.netsuite.com	Parameterise the host; Company URLs under Setup > Company > Company Information lists it.
RESTlet host	https://1234567.restlets.api.netsuite.com	https://1234567-sb1.restlets.api.netsuite.com	Use the External URL from the sandbox deployment, not a copied production URL.
SuiteAnalytics Connect host	1234567.connect.api.netsuite.com	1234567-sb1.connect.api.netsuite.com	Separate ODBC/JDBC DSNs per environment; confirm the sandbox host on Company URLs.
Data	Live	Copy of production as of the refresh, then diverges	Expect stale data between refreshes; do not reconcile sandbox to production.
Configuration and customizations	Live	Copied on refresh: setup, custom fields, records, scripts, workflows, forms	Anything built only in sandbox is overwritten at the next refresh; deploy it to production or export it with SDF first.
Internal IDs	Source	Same as production right after refresh	Records created later in each account get different IDs; avoid hard-coded IDs in scripts and use parameters.
Token-based authentication tokens	Active tokens	Must be created in the sandbox after refresh	Recreate access tokens for each integration user and update secrets after every refresh.
OAuth 2.0 client and certificates	Configured	Check after refresh	Confirm the integration record, redirect URI and certificate mappings; reauthorise.
Web store and website domains	Live domains	Not carried over as live domains	Use sandbox-specific test domains or the default system domain for SuiteCommerce testing.
Outbound email	Sent to recipients	Controlled by sandbox email options in Email Preferences: redirect to the logged-in user or listed addresses, or suppress	Check the option right after each refresh so customers and vendors never receive test emails.
Scheduled and Map/Reduce scripts	Running on schedule	Deployments copied with the account	Review scheduled deployments after refresh and set status deliberately; jobs that call external systems must point at test endpoints.
Integrations and outbound calls	Live endpoints	Same endpoints as copied from production unless parameterised	Point script parameters and integration settings to test endpoints before enabling any job.
Payments	Live gateway	Should not process real payments	Set payment processing profiles to the gateway's test mode or disable them.
Governance and concurrency	Per service tier and SuiteCloud Plus licences	Sandbox has its own limits; check Integration Governance in the sandbox	Do not assume load tests in sandbox predict production throughput; check Setup > Integration > Integration Management > Integration Governance in each account.
Users and login	All users	Access is granted per user; users log in with their NetSuite credentials and pick the sandbox role	Give sandbox access only to people who need it; review after each refresh.
SSO (SAML)	Configured with the IdP	Needs its own IdP app or configuration because the sandbox host differs	Register the sandbox as a separate service provider in your identity provider and test SSO after refresh.
Refresh request	Source account	Requested from production at Setup > Company > Sandbox Accounts	Schedule refreshes around testing cycles; anything unsaved in sandbox is lost.
Release upgrades	Upgraded on the account's release schedule	Has its own scheduled upgrade date	Check the upgrade dates for each account in the release schedule and plan regression tests between them.

Refresh scope and email options follow NetSuite help topics on Sandbox Accounts and the NetSuite Sandbox FAQ. Hostnames follow account-specific domains. Refresh durations and sandbox pricing depend on your agreement, so they are not stated here. For moving changes from sandbox to production, see the deployment runbook template.

Get a post-refresh checklist for your account

Tell us your integrations, scheduled jobs and email workflows and we will return a sandbox refresh checklist specific to your account.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

What is a NetSuite sandbox

A sandbox is a non-production NetSuite account linked to your production account. A refresh copies production data and configuration, including customizations and scripts, into the sandbox, which then runs independently until the next refresh. It is not a release preview account: release preview is a separate account Oracle provides before major upgrades. Sandboxes are bought as part of your subscription, and admins request refreshes from production at Setup > Company > Sandbox Accounts. Because a refresh overwrites the sandbox, any work done only in sandbox must be moved to production or saved in an SDF project before you request one.

How to use this table

Use the rows as a post-refresh checklist and as the environment section of your integration design. The first six rows are the ones that break integrations: account ID and realm format, and the four hostnames. Store each as configuration per environment rather than deriving one from another. Then work through tokens, email, scheduled jobs and outbound endpoints in that order, because those are the rows where a sandbox can affect the real world: emails to customers, payments, or a test job posting to a live 3PL. The What to do column gives the action; record who did it and when in your release log.

Worked example: integration after a refresh

An MES integration calls a RESTlet and SuiteQL. After the sandbox refresh, the integration user's tokens from before no longer work, so the admin creates a new access token in the sandbox for the same integration record and role and stores it in the sandbox secret store. The integration config uses account ID 1234567_SB1 for the OAuth realm, 1234567-sb1.restlets.api.netsuite.com for the RESTlet and 1234567-sb1.suitetalk.api.netsuite.com for SuiteQL. The scheduled Map/Reduce that pushes shipments to the carrier has a script parameter for the endpoint; the admin sets it to the carrier's test URL before setting the deployment back to Scheduled. Email is redirected to the logged-in user before anyone tests.

Gotchas

A frequent failure is mixing 1234567_SB1 and 1234567-sb1: the underscore form is for the realm and account ID fields, the hyphen form is for hostnames. The second is hard-coded internal IDs that matched right after a refresh and drift as each account creates new records. The third is assuming a sandbox load test shows production throughput; concurrency depends on licences and the sandbox's own limits. Also remember that work built only in sandbox disappears at the next refresh, and that SSO needs a sandbox-specific setup in the identity provider because the host and entity values differ.

Frequently Asked Questions

What is the NetSuite sandbox URL?

The UI is at https://<accountid>-sb1.app.netsuite.com, for example 1234567-sb1.app.netsuite.com for the first sandbox. Web services use 1234567-sb1.suitetalk.api.netsuite.com and RESTlets 1234567-sb1.restlets.api.netsuite.com. The exact URLs for your account are listed under Setup > Company > Company Information on the Company URLs subtab.

Do API limits differ between sandbox and production?

Script governance units per execution are the same, because they are set by script type. Account-level concurrency for web services and RESTlets depends on the service tier and SuiteCloud Plus licences of each account, so check Integration Governance in the sandbox itself before planning load tests or parallel workers.

Why do my integration tokens stop working after a sandbox refresh?

A refresh replaces the sandbox with a copy of production, and access tokens are account specific. Create new tokens in the sandbox for each integration user, role and integration record after every refresh, and update your sandbox secrets. Plan this as a standard post-refresh step.

Will a sandbox send emails to my customers?

It can if email is not controlled. Sandbox accounts have email options in Email Preferences that redirect outgoing email to the logged-in user or a list of addresses, or stop it. Check the setting right after each refresh and before running workflows or scripts that send email.

If you want an AI assistant that works in sandbox and production with the right environment settings, read-only by default and running on your own infrastructure, we can set that up.

Talk to an Expert Explore More Free Tools