NetSuite REST API vs SuiteScript RESTlet — Choosing the Right Interface
- The NetSuite REST Record API is the correct first choice for standard record CRUD (read, create, update orders, customers, items) — no custom SuiteScript required.
- SuiteScript RESTlets are the right choice when you need: bulk operations in a single call, custom business logic during the write, or access to record types not yet on the REST Record API.
- Do not use RESTlets as a default for everything — they add SuiteScript deployment overhead, and the REST Record API is lower-maintenance for standard operations.
- The REST Record API has a coverage gap: not all record types are available. Check the supported records list before designing an integration that assumes REST coverage.
Every new NetSuite WooCommerce integration faces the same early decision: use the REST Record API or build RESTlets? The answer is not the same for every operation. Getting this wrong in either direction creates maintenance problems — either a fragile custom SuiteScript codebase for operations that the REST API could have handled, or REST API calls that hit coverage limits and require late-stage refactoring.
Decision Matrix
| Operation | Recommended interface | Why |
|---|---|---|
| Create / read a Sales Order | REST Record API | Fully covered, JSON-native, no SuiteScript needed |
| Read inventory by location across 500 items | SuiteQL via REST | SuiteQL query is more efficient than 500 individual REST calls |
| Create SO + Fulfillment Request in one call | RESTlet | REST API cannot create linked records atomically in one call |
| Apply custom pricing logic on order import | RESTlet | Business logic must run server-side in SuiteScript |
| Update inventory levels from WooCommerce | REST Record API (Inventory Adjustment) | Covered — use PATCH on the InventoryAdjustment record type |
| Retrieve custom record types | RESTlet or REST (if custom records enabled) | Custom records require REST API to be enabled per record type |
When the REST Record API Is the Right Call
The record type is on the supported list. You need standard CRUD — not custom business logic. You value lower long-term maintenance cost over initial development flexibility. You are building a new integration from scratch in 2026 (REST is the supported direction; SuiteTalk SOAP is legacy).
When to Build a RESTlet
You need to create multiple related records in a single API call (SO + line items + fulfilment in one transaction). You need to execute NetSuite business logic during the write (pricing engine, approval workflow trigger). The record type is not on the REST API coverage list. You need to return aggregated data from multiple records in a single call — REST Record API is per-record only.
The Hybrid Pattern for Most Integrations
Most production WooCommerce-to-NetSuite integrations end up using both: REST Record API for order creation and customer reads (simple, low-maintenance), a RESTlet for bulk inventory sync (single call returns all location-level inventory), and SuiteQL for reporting queries. Designing the split deliberately at the start prevents the messy refactor where everything was built as RESTlets and the team is now maintaining 12 custom scripts.
References
- NetSuite REST Record API — Supported RecordsOracle NetSuite Help — full list of record types available via the REST Record API.
- SuiteScript RESTlet ReferenceOracle NetSuite Help — RESTlet framework, request handling, and governance for custom API endpoints.
- SuiteQL DocumentationOracle NetSuite Help — SQL-like query language for bulk data retrieval from NetSuite records.
Leave a Reply