Verdict
Use the REST Record API for straightforward native CRUD. Use a RESTlet when the integration needs business logic, multi-step orchestration, custom payloads, or stronger contract control.
Comparison Table
| Criterion | Option A | Option B | Recommendation |
|---|---|---|---|
| Custom contract control | Limited to the native surface. | Strong. You own the API shape. | RESTlet when contract design matters. |
| Maintenance burden | Lower. Fewer custom moving parts. | Higher. You own the endpoint behavior. | REST Record API when native fit is good enough. |
| Business-logic orchestration | Limited. | Strong for integration-specific flows. | RESTlet when the endpoint is more than CRUD. |
| Time to first delivery | Often faster for simple integrations. | More setup but more control. | Choose by long-term fit, not only the first sprint. |
Decision Criteria
- How close the external need is to native record CRUD
- Whether the integration contract must be custom-shaped
- How much validation and orchestration belongs server-side
- How much long-term control the integration team needs
Choose REST Record API When
Best when your use case aligns closely with NetSuite’s native record surface.
Good Fit
- The integration mostly needs standard CRUD
- You want to minimize custom code ownership
- The native contract is acceptable for the external system
Avoid It When
- The integration needs workflow-like orchestration or aggregation
- Payloads must be shaped differently from the native record model
- You need integration-specific validation or behavior
Choose RESTlet When
Best when the integration is really an application boundary, not just a record endpoint.
Good Fit
- You need custom validation, orchestration, or transformation
- Multiple records or operations belong behind one endpoint
- You need to design a stable contract for external callers
Avoid It When
- Native REST already fits the job
- The team cannot sustain custom endpoint ownership
- You would only be recreating CRUD with extra maintenance cost
Where Native Ends and Custom Begins
This decision becomes easy once you stop thinking in NetSuite terms and start thinking in integration-boundary terms. If the external system wants native records in mostly native shapes, the REST Record API is usually enough. If the external system really needs a business workflow, enrichment layer, or translation boundary, you are no longer choosing CRUD. You are choosing whether to build an application surface, which is what RESTlets are for.
Avoid vanity customization
Do not build a RESTlet just to feel in control. Custom endpoints are only worth the maintenance cost when they actually solve a contract or orchestration problem native REST does not solve well.
Governance and Performance
Governance
A RESTlet lets you centralize expensive operations, but it also makes you responsible for every inefficiency inside the endpoint. Native REST avoids some custom cost because less logic lives in your code.
Performance
Performance problems usually appear when teams fake an application boundary with native CRUD alone or, inversely, build an over-engineered RESTlet that only mirrors standard record actions.
Frequently Asked Questions
- Should new integrations default to REST Record API?
- Usually yes, if the integration is mostly native CRUD. That gives you the lowest custom maintenance burden. Move to a RESTlet when the use case clearly needs custom orchestration or contract control.
- When is a RESTlet clearly the right answer?
- A RESTlet is clearly the right answer when the endpoint must combine records, apply custom business validation, reshape payloads, or hide NetSuite-specific complexity from the caller.