NetSuite API & Technical FAQs
Straight answers on NetSuite’s technical layer: SuiteScript versions, the API surface, SuiteQL, middleware options and how to get through the twice-yearly releases without surprises.
Find your query
Jump straight to your question.
What is the difference between SuiteScript 1.0 and 2.0?
SuiteScript 2.x is the modern JavaScript standard for NetSuite development, while 1.0 is legacy tech. The real-world differences are huge: 2.x uses modular design to keep code organised and clean, whereas 1.0 relies on messy global variables. Map/reduce scripts in 2.x easily process massive data volumes that choke old 1.0 scheduled scripts, and all new NetSuite capabilities land on 2.x APIs first. If you still have 1.0 code running, don’t panic because NetSuite still executes it. Build all new customisations in 2.x and gradually convert legacy scripts starting with the ones causing performance bottlenecks or frequent errors.
What actually changed between the versions?
- Architecture2.x is modular where 1.0 was global soup. Maintainability is the daily difference.
- Map/reduceVolume processing with checkpointing and parallelism – the pattern that replaces struggling 1.0 scheduled scripts.
- API currencyNew platform capability lands in 2.x. Version 1.0 is functionally frozen.
- Estate policyWrite new work in 2.x, convert legacy scripts by risk and retire the ones nobody uses.
Can NetSuite be customised?
Yes, NetSuite can be customised to do almost anything. The secret is choosing the right tool for the job. You can tweak standard fields and forms through point-and-click configuration, automate processes with SuiteFlow, create entirely new data structures with custom records, or write custom SuiteScript for full programmatic control.
Because every customisation you build sticks around for future upgrades, discipline is everything. Always exhaust simple configuration and workflows before turning to custom code; jumping straight to scripting just because it feels familiar is how messy, “haunted” accounts are made. Built properly with supported APIs and managed through SDF, your customisations will pass through NetSuite’s twice-yearly updates smoothly, with no need for emergency weekend fixes.
What are the customisation layers?
- ConfigurationFields, forms, roles and preferences – the zero-code layer, and it covers more than most people assume.
- Workflows & custom recordsProcess logic and data structures without code, visible and auditable.
- SuiteScriptFull programmatic control where it is genuinely required, kept documented and governed.
- SDF deploymentSource-controlled, environment-managed change. This is customisation treated as engineering.
Does NetSuite have an API?
Yes, NetSuite has several APIs, making nearly every piece of data in the system accessible. You can use the REST API for modern JSON-based record updates and complex SuiteQL queries, rely on the older SOAP API for existing integrations (it’s being retired in the 2028.2 release), or write a custom RESTlet when you need a single, purpose-built endpoint.
Regardless of which API you choose, two key factors dictate integration performance: authentication and platform limits. NetSuite requires token-based authentication or OAuth 2.0 rather than simple passwords. More importantly, every account has strict API usage limits; integrations that batch data and poll efficiently run smoothly for years, while overly frequent API calls fail under heavy data volumes.
What does the API surface look like?
- REST records & SuiteQLModern JSON record operations plus SQL-style querying over HTTP. The default for new builds.
- SuiteTalk SOAP (retiring)Still runs many existing integrations, but Oracle disables it in the 2028.2 release.
- RESTletsCustom scripted endpoints: your operation, your contract, your validation.
- Governance limitsUsage tiers shape architecture. Design for them, or discover them in production.
What is iPaaS for NetSuite?
iPaaS – integration platform as a service – is managed middleware: platforms like Celigo, Boomi, Workato and Jitterbit that connect NetSuite to your other systems through prebuilt connectors, visual flow builders and centralised monitoring, instead of hand-built point-to-point code.
Why use middleware instead of custom code?
Choosing middleware over custom point-to-point code comes down to speed, visibility and reliability. Platforms like Celigo provide prebuilt connectors for systems like Shopify, Amazon and 3PLs that get you most of the way to go-live on day one. Instead of having custom scripts silently fail in isolation, middleware centralises error handling, automated retry logic and performance tracking inside a single dashboard. You trade the ongoing burden of maintaining custom code for a configurable platform designed to handle volume and API changes automatically.
What does iPaaS really cost?
iPaaS software isn’t free, and the real cost goes beyond the software licence. Subscription fees scale with your transaction volume and the number of connected systems, which adds up fast as you grow. You also need to account for labour – either training your team or paying an outside consultant to manage the platform. A simple, custom point-to-point script is still cheaper for one static connection. However, iPaaS pays for itself as soon as you have two or three integrations running at once, saving you from the high cost of maintaining scattered custom code.
When middleware wins
- Connector head-startPackaged NetSuite flows for common endpoints compress weeks of build into days.
- Operational visibilityOne error queue and one dashboard, instead of scripts failing privately.
- The volume economicsSubscriptions scale with usage, so model the five-year cost against building and owning the integration.
- The thresholdFor one simple integration, point-to-point is fine. For an estate of them, you are in platform territory.
Stuck on a technical question?
Talk it through with a solution architect. It’s free, it takes 30 minutes and there’s no sales pitch.
What are NetSuite SuiteApps?
SuiteApps are purpose-built add-ons that expand what NetSuite can do, covering everything from local tax compliance to payroll, EDI and warehouse logistics. Some are created directly by NetSuite, while others come from third-party partners. The “Built for NetSuite” (BFN) badge means an app passed Oracle’s technical review standards, but you shouldn’t rely on that badge alone.
How should you evaluate a SuiteApp?
Before installing one, treat it like a serious operational commitment: check how quickly the vendor updates their app for NetSuite’s twice-yearly releases, verify where and how it stores data in your account, and map out your exit costs ahead of time. A good SuiteApp saves months of custom coding, but a bad one becomes permanent technical debt with an annual subscription attached.
The evaluation checklist
- Badge as baseline‘Built for NetSuite’ verification is the floor. References and support responsiveness are the real test.
- Release-cycle fitnessAsk how the vendor has tracked NetSuite’s releases historically – the record tells you more than the roadmap.
- Footprint clarityKnow what records it creates and touches, and understand the uninstall cost before you install.
- Build-versus-buyCost the app against configuration or a targeted custom build. Sometimes lighter wins.
What is SuiteQL?
SuiteQL is basically SQL for NetSuite. It lets you write standard SELECT queries – complete with joins, subqueries and aggregates – directly against your account’s database. You can run SuiteQL queries through the REST API to pull data into external applications, write them inside custom scripts, or use them within NetSuite Analytics Workbooks. It’s the ultimate tool for complex data questions, easily handling advanced logic and deep record relationships that would make a standard saved search stall out.
What can SuiteQL do that saved searches can’t?
SuiteQL steps in where the standard search builder has limitations. It comfortably handles multi-table joins, complex aggregations, query unions and precisely shaped data outputs that are instantly ready for external reporting or export. It has quickly become the go-to tool for serious reporting pipelines and integration builds. In fact, sending a REST API call with a SuiteQL query body is the cleanest, most reliable way to perform bulk data reads out of NetSuite today.
What are SuiteQL’s limits?
SuiteQL is strictly a read-only query language; it cannot execute INSERT, UPDATE or DELETE operations. It queries the NetSuite Analytics Data Model, which covers most core records but omits certain legacy system tables. Additionally, SuiteQL queries are governed by standard NetSuite script and API execution limits. Developers should review NetSuite’s Analytics Schema documentation and Record Browser to verify table availability before building complex query pipelines.
Where SuiteQL earns its place
- Joins beyond searchesMulti-table questions expressed directly. This is the saved-search ceiling, removed.
- Integration extractsREST plus SuiteQL is the bulk-read pattern: paged, predictable and clean.
- Script-side queriesThe query module replaces search gymnastics inside SuiteScript.
- Read-only by designUse it for analysis and extraction. Writes stay with the records APIs and scripts.
Does NetSuite support REST or SOAP APIs?
NetSuite supports both today, but SOAP is being retired. Oracle’s 2025.2 SOAP endpoint is the last planned one, new integrations should be built on REST from 2026.1, new SOAP integrations can’t be built from 2027.1, and all SOAP endpoints are disabled in the 2028.2 release. Use the REST API for new work, with RESTlets where REST can’t do what you need – and plan the migration of any existing SOAP integration now.
How do you choose between them?
Choosing the right NetSuite API comes down to what you are trying to build. New, lightweight integrations and anything requiring complex database queries should use the REST API for its simple JSON payloads and easy developer workflow. Existing SOAP integrations and SOAP-based connectors keep working until 2028.2, but they need a migration plan – check which API your connector vendor uses.
When your business logic gets complicated – like needing to validate data upfront or bundle multiple actions into a single call – a custom RESTlet is usually better than trying to force-fit standard REST or SOAP endpoints. Oracle recommends OAuth 2.0 for all new integrations, and platform governance limits should shape your design more than protocol choice.
Is NetSuite SOAP being deprecated?
Yes. Oracle’s SOAP removal plan sets the timeline: 2025.2 is the last planned SOAP endpoint; from 2026.1 new integrations should use REST; from 2027.1 new SOAP integrations can’t be built; from 2027.2 only the last endpoint is supported; and in the 2028.2 release all SOAP endpoints are disabled. Oracle names SuiteTalk REST web services as the replacement, with RESTlets where REST can’t be used.
Choosing per job
- REST as defaultModern record operations and SuiteQL queries – the starting assumption for new builds.
- SOAP: plan the exitExisting SOAP integrations work until the 2028.2 release. Migrate them to REST or RESTlets before then.
- RESTlets for bespoke shapesYour operation delivered as one governed endpoint – the custom-fit option.
- Governance over protocolUsage limits shape design more than REST-versus-SOAP ever will.
How does NetSuite handle bi-annual releases?
NetSuite ships two releases a year – 20xx.1 in spring, 20xx.2 in autumn – rolled out to all accounts in phased waves. Upgrades are mandatory and automatic. What you control is preparation: a release preview account appears weeks ahead, so you can test your customisations against the new version before it arrives.
How does the release cycle work?
Your upgrade date arrives by notification, the release notes land earlier (2026.2 is the current set), and the preview account gives you a window of typically a few weeks to run your critical processes and customisations against the incoming release. Standard functionality rarely breaks; the risk concentrates in customisation – scripts against changed behaviour, integrations against deprecations.
How do you prepare for a NetSuite release?
Preventing unexpected issues during NetSuite’s twice-yearly platform releases requires four core operational practices: maintaining an updated inventory of all custom code and configurations, executing a standardised regression test checklist for critical workflows, actively testing inside the Release Preview account, and reviewing NetSuite’s release notes for feature deprecations that impact your account. Accounts that skip these steps risk business interruptions in production twice a year.
The release survival kit
- Preview testingRun your critical flows in the preview account. The window exists to be used.
- Customisation inventoryKnowing what you have is the precondition for testing it.
- Deprecation watchRead the release notes against your integrations and scripts – the quiet breakers live there.
- Regression checklistThe dozen processes that must work, tested every cycle.
Last reviewed: 25 September 2026 · Written by the SuiteGeneration team
SuiteGeneration is an independent, senior-led NetSuite consultancy. Every project is designed and delivered by consultants at or close to solution-architect level. We don’t resell licences or carry partner targets. Our advice is ours, whether you’re implementing NetSuite, rescuing a stalled project or fixing a system that never delivered.
