SuiteCommerce Developer cheat sheet

SuiteCommerce runs on NetSuite's SCA (SuiteCommerce Advanced) bundle: a Commerce web store plus SSP (Site Builder) applications served through a CDN-fronted domain, with NetSuite as the system of record for items, pricing, customers, and orders.

Three delivery models share one platform: SuiteCommerce Standard (Site Builder only, no source customization), SuiteCommerce Advanced (full source access, extension developer workflow), and SuiteCommerce MyAccount (B2B portal without a public storefront).

Request flow: browser → CDN (cached static assets and cached pages) → Commerce web application (Node/SSP) → SuiteScript service calls → NetSuite records. Any record change that must appear immediately requires cache invalidation, not just a save.

Commerce categories, items, and facets are NetSuite records surfaced as 'Commerce' fields on item/category records; presentation is controlled by the site's catalog configuration and the SuiteCommerce Configuration record, not by hard-coded templates.

The SuiteCommerce Configuration record centralizes checkout settings, search settings, CDN/cache settings, domains, and feature flags; source files must not hard-code values that exist there.

Extensions are the unit of customization: a bundle of modules, templates, and assets mounted into the application; multiple extensions can be enabled per site and their Sass/JS are compiled into the deployed distribution.

Environments: Sandbox for build and test, Production for release; deployment is a versioned bundle activated per domain, and rolling back means activating the prior version rather than editing live files.

SCA uses Backbone.js + jQuery + Handlebars on the frontend and SuiteScript 2.x service files on the backend; SSP (the server-side rendering layer) executes the same view/template code to produce initial HTML for SEO and performance.

Site Builder is the tabbed admin UI (Setup > SuiteCommerce > ... and the Site Builder tabs) for content: tabs include Setup, Appearance, Content, Publishing, and Configuration; each tab edits records, not code.

A theme in Site Builder is a set of Sass variables plus fonts/colors; changing the theme recompiles CSS, so theme edits are safe for Standard sites but SCA theme changes must go through the source theme variables and a fresh deploy.

Content types: pages (HTML/free-form), tabs and tab groups, category and item templates, product lists, carousels, and landing pages; each is a record that can be scheduled and targeted to a touchpoint.

Touchpoints bind a domain, a site, and a presentation (theme/layout) together; multiple touchpoints per site allow different look-and-feel per domain or per B2B vs B2C audience.

Publishing is explicit: content changes are staged and must be published to the active site; unpublishing or scheduling uses the Publishing tab with start/end dates.

SEO controls live per page and per category: URL components, meta title/description, canonical tags, and sitemap generation; URL components must be unique or routing collisions occur.

Themes and layouts are separate: layout controls regions and the placement of content (header, footer, sidebar), theme controls colors/typography; swapping a theme does not move content between regions.

Site Builder search settings (facets, field sets, sort order) come from the SuiteCommerce Configuration record and the search field set on items; changing facets requires reindexing before results reflect the change.

Service files follow the SCA naming convention: .ServiceController.js is the server entry point, dispatching to a module's ServiceController with methods like get, post, put, and remove; the client-side twin is .View.js.

Use the Commerce API (require('SuiteScript/...') equivalents: 'N/commerce/recordView', 'N/currentRecord') to mount a view: RecordView.getView(options) returns a view model that the ServiceController passes to SSP for rendering.

SuiteScript 2.x entry points: define([...], function(...) { return { get: function(context) {...} }; }); context carries request, response, and the parameters passed from the client via the AJAX call.

Server-side calls from the frontend go through the SCA AJAX/SSP layer (e.g., the Profile/Commerce API service endpoints), not direct RESTlets, unless you deliberately add a custom endpoint; respect authentication and CSRF handling.

Search on the backend uses 'N/search' with the item's commerce field set; for storefront search prefer the Commerce search API and the configured search field set so facets and sorting stay consistent with Site Builder.

Performance rules: batch with search result sets and map/reduce for large data, avoid per-line record loads in loops, and keep service responses small because they cross the SSR boundary on every uncached request.

Custom records and fields used by the storefront must be exposed in the appropriate field set and permissioned for the Commerce role, otherwise the service returns empty data rather than an error.

Deployment of backend changes is part of the extension bundle: service files must be included in the extension's manifest and the bundle redeployed; editing a file in the file cabinet alone does not activate it.

The extension developer toolchain is Node-based: create the extension, run the local dev server against a NetSuite account (via a token/settings file), and use the local server to iterate before deploying.

Extension structure: manifest.json (name, vendor, version, dependencies), a JavaScript entry (extension.js) that mounts modules, plus Modules/, Templates/, Sass/, and Assets/ folders; the manifest declares which files ship.

Modules are AMD (define/require) and extend Backbone views/models/collections; override a core module by declaring a dependency on it in the extension and patching its prototype or by mounting a new view into a CompositeView.

Templates are Handlebars (.tpl) compiled at build time; use the LiveOrder/context helpers and never inline logic that belongs in the view; escaping is on by default with {{ }}, so use {{{ }}} only for trusted HTML.

Frontend data access uses the SCA AJAX helpers against service endpoints (e.g., the item/search/profile services); the returned JSON is the view model, so the client never queries NetSuite records directly.

Sass customization: override variables in the extension's _variables or a theme file; the build compiles all enabled extensions' Sass into the distribution, so selector specificity conflicts must be resolved in the extension, not in the deployed CSS.

The local dev server proxies to the NetSuite account for data but serves your local files; changes to manifest dependencies require restarting the server and, in some cases, a fresh 'extension install' against the account.

Deployment: activate the extension in the account, then deploy the bundle to the target domain; verify with the deployed version number and a cache-busted browser session, since CDN caching can mask a successful deploy.