AAES
Evaluate AAES →Request a demo

Capability Library · Pack detail

netsuite v1.0.0

NetSuite SuiteTalk REST web services on the customer's own account: read vendors, vendor bills, purchase orders and customers, and create vendor bills.

Review state: draft· Not in the distributable release manifest

Release identity

SHA-256 of the pack file bytes: e7142e93108901c2d4bbc10cc93506436cd50494d0dd189d99888a8940785d95

Not in the distributable release manifest. The binary carries a digest-bound manifest of the distributable library; a pack whose bytes differ from its manifest entry — endpoint, tier, allowlist, or credential edited, with provider, version, and review block preserved — fails the digest check, loses distributability, and renders MODIFIED rather than as the shipped reviewed artifact. Review state and artifact status are different facts: the first is a documentation-review declaration, the second is the identity of the exact bytes.

Capabilities (5)

netsuite.vendors.read v1.0.0R0

Action
read
Endpoint
GET https://netsuite-account.invalid/services/rest/record/v1/vendor
Connector
http
Custody
customer_vault
Credential ref
secret-ref-netsuite-oauth2-access-token
Data class
pii

Read the vendor record collection. Payload precision: Oracle's collection-paging documentation shows a collection response whose items array carries only each record's id and a self link (with count, hasMore, offset and totalResults paging fields) — the full vendor fields (names, legal names, addresses, emails, phone numbers, tax registration details) come only from the single-record read GET /services/rest/record/v1/vendor/{id}, which this pack deliberately does not register, so this capability returns record references and no unregistered detail read happens automatically. A vendor can be an individual person, so the read is registered at the pii class on the strength of the records it references (a deployment whose policy classifies vendor master data differently may change it). The registered path covers the collection read only — single-vendor reads (GET /services/rest/record/v1/vendor/{id}) and every sublist and subresource are not registered by this pack. The host is a reserved placeholder: substitute the customer's account-specific host before enabling.

netsuite.vendorbills.read v1.0.0R0

Action
read
Endpoint
GET https://netsuite-account.invalid/services/rest/record/v1/vendorBill
Connector
http
Custody
customer_vault
Credential ref
secret-ref-netsuite-oauth2-access-token
Data class
financial

Read the vendor bill record collection, registered at the financial class. Oracle's own use-case documentation shows collection reads on this resource filtered with the q parameter (GET .../record/v1/vendorBill?q=entity EQUAL <id>). Payload precision: Oracle's collection-paging documentation shows a collection response whose items array carries only each record's id and a self link (with count, hasMore, offset and totalResults paging fields) — the bill header fields (vendor, amounts, currencies, terms, statuses) come only from the single-record read, which this pack deliberately does not register, so this capability returns record references and no unregistered detail read happens automatically. The registered path covers the collection read only — single-bill reads, the billingAddress subrecord and the expense and item sublists are not registered by this pack. The host is a reserved placeholder: substitute the customer's account-specific host before enabling.

netsuite.vendorbills.create v1.0.0R3

Actions
create, approve
Endpoint
POST https://netsuite-account.invalid/services/rest/record/v1/vendorBill
Connector
http
Custody
customer_vault
Credential ref
secret-ref-netsuite-oauth2-access-token
Data class
financial

Create one vendor bill record; Oracle documents POST /services/rest/record/v1/vendorBill with a worked creation sample. Registered as create plus approve at the R3 floor: Oracle documents approving a vendor bill by setting its approval status on this same record surface (PATCH /services/rest/record/v1/vendorbill/{id} with approvalstatus set to 2), and Oracle's creation documentation states only that not all record fields can be set using 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 restrict which writable fields a request may carry beyond what the role's own permissions permit. An unrestricted creation path that can create an already-approved bill is approve-capable, so it sits at the approve floor rather than the create floor. Effect-level precision: the request is accepted and a payables document is created; the call itself schedules no payment and moves no money — Oracle documents payment against bills through the separate vendorPayment record, which this pack does not register. The host is a reserved placeholder: substitute the customer's account-specific host before enabling.

netsuite.purchaseorders.read v1.0.0R0

Action
read
Endpoint
GET https://netsuite-account.invalid/services/rest/record/v1/purchaseOrder
Connector
http
Custody
customer_vault
Credential ref
secret-ref-netsuite-oauth2-access-token
Data class
financial

Read the purchase order record collection, registered at the financial class. The Purchase Orders feature must be enabled for this record to be accessible, per Oracle's record documentation. Payload precision: Oracle's collection-paging documentation shows a collection response whose items array carries only each record's id and a self link (with count, hasMore, offset and totalResults paging fields) — the order header fields (vendors, buyers, amounts, currencies, statuses) come only from the single-record read, which this pack deliberately does not register, so this capability returns record references and no unregistered detail read happens automatically. The registered path covers the collection read only — single-order reads, the billingAddress and shippingAddress subrecords and the item and expense sublists are not registered by this pack. The host is a reserved placeholder: substitute the customer's account-specific host before enabling.

netsuite.customers.read v1.0.0R0

Action
read
Endpoint
GET https://netsuite-account.invalid/services/rest/record/v1/customer
Connector
http
Custody
customer_vault
Credential ref
secret-ref-netsuite-oauth2-access-token
Data class
pii

Read the customer record collection. Payload precision: Oracle's collection-paging documentation shows a collection response whose items array carries only each record's id and a self link (with count, hasMore, offset and totalResults paging fields) — the customer fields (names, company names, emails, addresses, phone numbers) are personal data held on the single record, read via GET /services/rest/record/v1/customer/{id}, which this pack deliberately does not register, so this capability returns record references and no unregistered detail read happens automatically; the read is still registered at the pii class on the strength of the records it references. The registered path covers the collection read only — single-customer reads (GET /services/rest/record/v1/customer/{id}) and every sublist (addressbook, currencylist, partners, salesteam and the rest) are not registered by this pack. The host is a reserved placeholder: substitute the customer's account-specific host before enabling.

Credential reference

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference
secret-ref-netsuite-oauth2-access-token
Custody
customer_vault
Injection
header (Authorization)

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.

Resources

  • netsuite-vendors (api, pii): https://netsuite-account.invalid/services/rest/record/v1/vendor
  • netsuite-vendorbills (api, financial): https://netsuite-account.invalid/services/rest/record/v1/vendorBill
  • netsuite-purchaseorders (api, financial): https://netsuite-account.invalid/services/rest/record/v1/purchaseOrder
  • netsuite-customers (api, pii): https://netsuite-account.invalid/services/rest/record/v1/customer

Pack notes and exclusions

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 R3 floor: 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 wiring reality, stated honestly: 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 (the same position packs/aws.json was in before SigV4 landed): 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.

Review record

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.

← Back to the Capability Library