NetSuite package v1.0.0

An OAuth 2.0 access token for the customer's own NetSuite account, held in the client's own secret manager. The stored material must be the complete Authorization header value (scheme included): 'Bearer', one separating space, then the access token — 'Bearer <token>'. The executor injects the stored value verbatim and performs no token lifecycle itself: an external deployment process obtains and renews the token.

For machine-to-machine use NetSuite documents the OAuth 2.0 client credentials flow: an administrator maps an entity, role and application to a certificate on the OAuth 2.0 Client Credentials (M2M) Setup page, and the external process signs a JWT client assertion with the certificate's private key and POSTs it to https://<accountID>.suitetalk.api.netsuite.com/services/rest/auth/oauth2/v1/token; the certificate's private key is itself secret material and must live in the deployment's own custody, outside the executor. customer_vault is the only generally-supported production custody model here — identity_federation and customer_broker are refused at startup and inline is lab-only.

Expiry and revocation: OAuth 2.0 access tokens are short-lived and the external process must re-request them on expiry — Oracle documents the M2M flow as a POST to the token endpoint that returns an access token, with renewal owned by the external process.

An administrator can revoke the certificate mapping on the M2M setup page at any time (a revoked certificate cannot be reused to obtain new tokens), and the mapped role's permissions can be removed at any time, which changes what subsequently issued tokens can do; disabling issuance and changing role permissions are different events from invalidating an already-issued token, and Oracle's documentation does not describe either step as invalidating a token already issued before its natural expiry.

An expired value fails closed.

Least privilege: the integration record should carry only the REST Web Services scope, and the mapped role should hold only the record permissions the registered capabilities need (vendor, customer, purchase order and vendor bill inquiry, plus bill entry for the create) and nothing more — the same identity must not hold permissions for vendor payments or record deletion, which this pack deliberately does not register.

Approval caution: because Oracle documents no field-level restriction preventing a creation POST from carrying an approval status, the bill-entry permission is treated as approve-capable and the create capability is tiered R3 on that basis; a deployment whose role configuration demonstrably prevents setting approval status on creation may record that restriction in its own review, but the tiering here does not rely on it. Token-based authentication (TBA) is a different, per-request-signed scheme that this pack cannot express; see the pack notes.

Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

The endpoint host 'netsuite-account.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's own NetSuite account-specific host, whose documented form is <accountID>.suitetalk.api.netsuite.com, before enabling, in every endpoint, in every resource locator and in every egress allowlist entry. The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step — the reserved host being allowlisted does not make an unsubstituted pack safe to enable.

This pack registers only endpoints the SuiteTalk REST Web Services documentation on docs.oracle.com documents: collection reads on the vendor, vendorBill, purchaseOrder and customer records (GET /services/rest/record/v1/<recordType>, with filtering via the documented q parameter), and creation of a vendor bill (POST /services/rest/record/v1/vendorBill, which the vendor bill record page documents with a worked sample). All reads are collection reads only: single-record reads (GET /services/rest/record/v1/vendor/{id} and the equivalent for the other record types) exist in the API and are deliberately not registered.

Documented exclusions, framed as what this pack does not register: record update (PATCH) and record delete (DELETE) on every record type; upsert (PUT); record actions and transforms (POST .../{id}/action/... and transform operations); the vendorPayment and customerPayment records, which record payments against documents (money moves); the customerRefund record, which returns money; and the vendorCredit record, which is a credit memo — an accounting record that reduces the balance owed rather than a record that moves funds, excluded alongside the money records because this pack registers no money-adjacent writes at all; the SuiteQL query service (POST /services/rest/query/v1/suiteql) and every other query subservice; RESTlets; and the metadata-catalog.

The vendor bill create is registered as create plus approve at the minimum R3 tier: Oracle documents approving a vendor bill by setting its approval status on this same record surface (the Use Case for Approving a Vendor Bill shows PATCH /services/rest/record/v1/vendorbill/{id} setting approvalstatus to 2), and Oracle's record-creation documentation states only that not all record fields can be set with POST, without enumerating which — so no documented provider-side restriction prevents an unrestricted creation POST from carrying an approval status, and this registration does not constrain the request body beyond what the role's own permissions permit.

An unrestricted creation path that can create an already-approved bill is approve-capable and must sit at the approve floor rather than the create floor. A created bill is otherwise a payables record, not a payment: Oracle documents payment against bills through the separate vendorPayment record, which this pack does not register, so object-created is not payment-scheduled and not money-moved. Authentication: SuiteTalk REST supports two credential schemes.

This pack registers OAuth 2.0, whose documented header is 'Authorization: Bearer <access token>' — a stored value the connector can inject verbatim.

NetSuite's other scheme, token-based authentication (TBA), is an OAuth 1.0a-style per-request signed Authorization header; this pack format injects a stored header value verbatim and the connector's only signing mode is aws-v4, so TBA is not expressible in this pack today: a deployment that must use TBA cannot wire it through this pack and must not fake it by storing a static TBA header, because a TBA signature is computed per request and a stored one is not a valid credential.