Custom should describe the requirement, not an excuse for complexity.
A bespoke connection may be justified by a distinctive process, an unsupported record, a specialized application or a control that a standard connector cannot provide. Start by documenting that gap and the alternatives considered. The design should solve a defined problem without creating unnecessary responsibility.
We start by proving the uncertain operation in the target account. Can the required record be created, changed and read back with the intended permissions? What happens if the request times out after creation? Establishing that behaviour early prevents a full build from depending on an untested assumption.
Specify the behavior that matters in production.
| Production requirement | Behavior to specify |
|---|---|
| Record and operation support | Check which NetSuite interfaces support the required records and actions. Native REST services and custom RESTlets serve different needs; the appropriate choice depends on the actual operation and constraints. |
| Identity and permission | Use an appropriate authentication design and least-privilege access. Define ownership of credential lifecycle and review, without distributing secrets through ordinary project notes or support messages. |
| Validation and recovery | Decide how incomplete, invalid, repeated or out-of-sequence requests are handled. Make the response useful to the calling system and the person responsible for resolving an exception. |
Prove the uncertain parts early.
- 01
Confirm the interface fit
Review authoritative API documentation and the target account’s capabilities. Validate record support, permissions and the behavior of important operations before estimating the complete build.
- 02
Define the data contract
Document payloads, mappings, identifiers and error responses. Agree versioning and how changes will be communicated between system owners.
- 03
Implement and test
Use representative volumes and business scenarios. Test retries, authorization failures, malformed inputs, timeouts and partial outcomes, alongside the ordinary flow.
- 04
Deploy with operating guidance
Record environments, dependencies, monitoring and recovery procedures. Establish responsibility for maintenance when either system or its API changes.
Design within the account’s operating limits.
NetSuite applies concurrency governance across relevant integration requests. The design should account for competing work, expected volume and the behavior of the calling application. Queueing, pacing and retry choices need to fit those constraints rather than assuming unlimited request capacity.
Observe the business result as well as the interface. A request can fail before any action, succeed completely or leave a partial outcome that requires investigation. Define safe recovery using the transaction’s actual state, with stable references and reconciliation where needed.