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