NetSuite

This page records how composerID publishes into NetSuite: the vendor’s API posture, the publish target and field mapping, and the documentation each claim rests on. It is for anyone evaluating the connection or building against it. NetSuite is the dominant mid-market cloud ERP - a financial-commitment system of record for the outsourced work-order channel. composerID creates the Purchase Order through SuiteTalk REST, carries the Intent ID in a custom body field, and reconciles with SuiteQL reads (and SuiteScript-relayed events, since NetSuite has no native webhooks).

Category: ERP. Coverage status: Specification mapped. Vendor documentation: public developer portal.

Integration path

How composerID connects to this destination, at a glance.

Step	Detail
Authentication	OAuth 2.0 (client credentials at /services/rest/auth/oauth2/v1/token, or authorization code) tied to an Integration Record + Role; legacy Token-Based Auth (OAuth 1.0a HMAC) still works but is being phased out and cannot be used with 2FA roles.
composerID publishes	Purchase Order: POST /services/rest/record/v1/purchaseOrder
Intent ID lands on	`purchase_order` `custbody_intent_id`, written into the destination record
Back-sync	Reads at onboarding: no event mechanism is documented; reconciliation is arranged per tenant.

Vendor documentation

OAuth 2.0 for REST web services

NetSuite documentation (Oracle Help)

API posture

Aspect	Detail
Authentication	OAuth 2.0 (client credentials at /services/rest/auth/oauth2/v1/token, or authorization code) tied to an Integration Record + Role; legacy Token-Based Auth (OAuth 1.0a HMAC) still works but is being phased out and cannot be used with 2FA roles. Tokens inherit the role’s permissions and subsidiary restrictions.
Style	SuiteTalk REST (record/v1 CRUD: GET/POST/PATCH/DELETE) + SuiteQL (query/v1/suiteql, SQL-like reads with Prefer: transient); SOAP is legacy (deprecation trajectory ~2028)
Base URL	https://{accountId}.suitetalk.api.netsuite.com/services/rest (sandbox accounts use {accountId}_SB1)
Webhooks	None native - relay events with SuiteScript user-event scripts posting outbound, or reconcile by polling SuiteQL on lastModifiedDate.
Events posture	Reads at onboarding
Rate limits	~10 concurrent requests per account on REST plus volume throttling; batch reads through SuiteQL.
Objects	purchaseOrder, vendor, vendorBill, item/expense lines, subsidiaries; custom body/column fields (custbody_/custcol_); REST record browser at /record/v1/metadata-catalog

Publish target and field mapping

Each object below pairs the canonical intent fields with the destination’s own fields and operations. The mapping is indicative until it is confirmed against a tenant at onboarding.

Purchase Order

Commit the spend

Mapping	Detail
Canonical to destination	supplier (entity), lines (items/expenses), dates, subsidiary
Target	POST /services/rest/record/v1/purchaseOrder
Requirement	Required
Notes	PATCH for partial updates; role must span the target subsidiary in OneWorld

Status & bill read-back

Track receipt and billing

Mapping	Detail
Canonical to destination	PO status, vendor bills, amounts
Target	POST /services/rest/query/v1/suiteql
Requirement	Recommended
Notes	SuiteQL is the read layer (transaction/transactionLine)

Intent ID + back-sync

Correlate and reconcile

Mapping	Detail
Canonical to destination	intent_id (custbody field); changes since last sync
Target	custbody_intent_id + SuiteScript event relay or lastModifiedDate polling
Requirement	Required
Notes	No native webhooks - plan the relay or the poll from day one

Every NetSuite account’s schema diverges: custom fields, forms and scripts differ per tenant, so mapping needs the tenant’s record model (custbody_ field for the Intent ID agreed up front). Tokens inherit role permissions and OneWorld subsidiary restrictions - provision a dedicated integration role. OAuth 2.0 authorizations are not copied into sandbox refreshes; re-authorize after each refresh. Deep record catalogs sit behind the NetSuite Help Center login.

Next steps

How composerID connects

The five ways composerID reaches a destination, and the minimum a destination must offer.

Publishing

Plan, preflight and publish: how a decision becomes a valid record in a destination.

All destinations

Every destination composerID documents, with its category and coverage status.

⌘I

Get started

Concepts

Guides

Destinations

Upstream connectors

API reference

Endpoints

Manuscript API (Triage)

Manuscript endpoints

Resources

Integration path

Vendor documentation

OAuth 2.0 for REST web services

NetSuite documentation (Oracle Help)

API posture

Publish target and field mapping

Next steps

How composerID connects

Publishing

All destinations

​Integration path

​Vendor documentation

OAuth 2.0 for REST web services

NetSuite documentation (Oracle Help)

​API posture

​Publish target and field mapping

​Next steps

How composerID connects

Publishing

All destinations

Integration path

Vendor documentation

API posture

Publish target and field mapping

Next steps