Development Considerations Overview
Note that SOAP web services follow the same role-based permissions as the NetSuite UI. A SOAP web services application's permissions depend on the role used to log in, like in a browser session. For example, an application logging in with the Accountant role has the same permissions as logging in through the browser with that role.
See Roles and Permissions in SOAP Web Services for additional details.
SOAP web services behave similarly to the NetSuite UI. The workflow mimics the browser interface, with a similar SOAP exchange. For example:
-
You must log in successfully to get a session for further operations. (See the documentation on SOAP web services Authentication for SOAP Web Services for more details.)
-
Some add operations are done in a tandem, such as loading an existing sales order to gain the context and then adding a new item fulfillment record. The loading of the sales order (using the initialize API) is the first operation; adding the item fulfillment record is the second.
-
SOAP web services respect custom form restrictions and requirements. Therefore, attempting to set a hidden field results in a permission error. Required fields must be set, like in the UI.
-
Elements in web services calls are handled sequentially.
This consistency between SOAP web services and the NetSuite UI creates a predictable platform for developers, making it easier to work with.
When you are unsure of how to achieve something with SOAP web services, try observing how it is done in the UI, then replicate it programmatically.
A SOAP web services application should use the response object to handle any errors, if any, generated by a Web service operation.
SOAP web services use the HTTP protocol, therefore service interruptions can occur from time to time. If you receive an HTTP 503 error (Service Unavailable), try sending your SOAP web services request later.