SuiteCloud Integration and Deployment
This domain covers how external systems reach NetSuite and how code travels from development to production: authentication, integration surfaces, and the deployment mechanisms that keep environments consistent.
Authentication and surfaces
SuiteTalk SOAP and REST web services expose standard records; RESTlets expose custom logic through script and deployment IDs; Suitelets serve pages and lightweight endpoints. Token-Based Authentication (TBA) uses a consumer key/secret plus a token ID/secret, signs each request with HMAC-SHA256, and identifies the account as the realm. OAuth 2.0 uses an integration record and either an authorization-code flow for user context or client credentials for machine-to-machine calls, with short-lived access tokens refreshed as needed. Every integration runs as a role, so permissions and login audit trail matter.
Deployment
SDF is the source-of-truth path: suitecloud project:validate catches problems before project:deploy writes objects. Bundles distribute to other accounts, but their components arrive read-only. Sandbox refresh copies production, and internal IDs can differ between accounts, so configuration belongs in script parameters or custom records, never hard-coded.
Worked example. An external system calls a RESTlet with TBA in sandbox, then fails in production after SDF deployment. Reasoning: the tokens, consumer key, and realm are account-specific, so sandbox credentials cannot authenticate against production; regenerate them from the production integration record and role. Then verify the RESTlet's deployment status and that any hard-coded internal IDs were replaced with parameters resolved at runtime.
Traps
- Reusing sandbox tokens or integration records in production.
- Hard-coding internal IDs that differ across accounts and sandboxes.
- Assuming bundled objects are editable in the target account.
- Skipping validation and deploying a SuiteApp project that references account-specific objects.