Skip to main content
Use the @bijection/connectors/netsuite entrypoint to declare NetSuite resources.

​
Availability

This page describes the pinned source package. Published availability is unestablished for this artifact. Source build and package availability.

​
Resources and modes

Declare a resource in application code, then bind deployment-specific settings and credentials. See typed resources, connections and source inspection.

​
Captured REST record

​
captured: Account-specific metadata, discovery and exact detail observations

The following example matches configuration customer.
The function references identify application policy queries. Implement those policies in your application; the references alone grant no authority.

​
Configuration: customer

Case: netsuite/record/captured/customer. Connection and resource configuration are declared by this exact case. Credential kind: netsuite. Keep credential material in the private credential inventory.
Native admission analysis is available for this exact declaration. Collection: records
Commands
Recorded checks Hosted qualification: unestablished for this catalog configuration. Installed connections report their own identity, authority and current status.

​
Configuration: vendor

Case: netsuite/record/captured/vendor. Connection and resource configuration are declared by this exact case. Credential kind: netsuite. Keep credential material in the private credential inventory.
Native admission analysis is available for this exact declaration. Collection: records
Recorded checks Hosted qualification: unestablished for this catalog configuration. Installed connections report their own identity, authority and current status.

​
Configuration: salesOrder

Case: netsuite/record/captured/salesOrder. Connection and resource configuration are declared by this exact case. Credential kind: netsuite. Keep credential material in the private credential inventory.
Native admission analysis is available for this exact declaration. Collection: records
Recorded checks Hosted qualification: unestablished for this catalog configuration. Installed connections report their own identity, authority and current status.

​
Configuration: invoice

Case: netsuite/record/captured/invoice. Connection and resource configuration are declared by this exact case. Credential kind: netsuite. Keep credential material in the private credential inventory.
Native admission analysis is available for this exact declaration. Collection: records
Recorded checks Hosted qualification: unestablished for this catalog configuration. Installed connections report their own identity, authority and current status.

​
SuiteQL table

​
observed: Keyset walk by last modification with deleted records

The following example matches configuration standard.

​
Configuration: standard

Case: netsuite/table/observed/standard. Connection and resource configuration are declared by this exact case. Credential kind: netsuite. Keep credential material in the private credential inventory.
Native admission analysis is available for this exact declaration. Collection: records
Recorded checks Hosted qualification: unestablished for this catalog configuration. Installed connections report their own identity, authority and current status.

​
Configuration: recordsOnly

Case: netsuite/table/observed/recordsOnly. Connection and resource configuration are declared by this exact case. Credential kind: netsuite. Keep credential material in the private credential inventory.
Native admission analysis is available for this exact declaration. Collection: records
Recorded checks Hosted qualification: unestablished for this catalog configuration. Installed connections report their own identity, authority and current status.

​
Provider guidance

​
Captured REST records

source metadata capture netsuite captures account-specific JSON Schema for customer, vendor, salesOrder and invoice. Generated capturedObject factories select typed custom fields and explicit customer create/updateContact commands. netsuite.record.captured is the underlying recipe. It requires the exact captured metadata, field validators and application policies. The registered cases are synthetic. Native discovery pins the provider clock, traverses a modification window ordered by (second, internal ID) and rereads five minutes of overlap on later windows. Initial and daily repair scans read from the profile floor. Deletion is a separate phase with its own continuation; a same-query live-record exclusion prevents an old delete log overriding a visible recreated record. Every query uses bound parameters and exact-text IDs. Native admission checks the query against retained progress, and checkpoints commit with publication only after the window finishes without gaps. Daily known-record verification uses refresh-only point reads; 403/404 stays unresolved. A native 403 holds source disclosure until the role is checked and the binding explicitly reconfigured. Configure the integration user in GMT. The 64-row query bound works with the existing native fanout and byte limits. No pass claims coverage or a snapshot. A captured resource selects at most sixteen fields including id. REST detail projection retains original decimal tokens as text, distinct business dates/timestamps, optional presence and scalar reference IDs. Metadata retains reference targets and reviewed monetary currency dependencies; application relationships are explicit. Read-side 429/503 is transient. Creation sends POST with the occurrence ID as externalId and confirms only a GET by that marker returning the same marker and native customer ID. Contact updates send asynchronous PATCH, retain the same-origin job Location and sole task ID, then read that task’s /result endpoint. Successful task result responses settle delivery; job/task status alone does not. A documented 400 IDEMPOTENCY_ERROR with a confined Location retains the original job as pending. Failed results, ambiguous work and lost send replies remain unknown. Commands are unconditional and single-attempt, with no automatic resend. Source observations establish resulting record state. Binding setup requires baseUrl, accountId and an explicit incarnation. All captured resources can use the same connection returned by metadata connect. Within a deployment, two native in-flight slots are shared by account origin, with one available to commands while acquisition occupies the other. Requests have a 30-second transport bound and 60-second capacity leases. This does not constrain other clients of the account. Metadata responses assert neither account identity nor the certificate’s mapped role. The incarnation is an operator attestation, not a fabricated provider assertion. Sandbox credential replacement requires a new incarnation. Native admission refuses changing it while old sources remain; explicitly withdraw them before binding the replacement. These observed profiles cannot support complete-population rebaseline. Use a private oauth_client_credentials envelope with protocol: { authentication: "private_key_jwt", body: "form" }, client_assertion: { key_id, private_key, algorithm: "ps256" | "es256", claims: { scope: ["rest_webservices"] } }, the account-specific OAuth token endpoint and exact allowed_resource_origins. Keys must be PKCS#8 PEM. Native custody signs and exchanges the assertion and coordinates cached token renewal. Authorization-code refresh credentials use the existing owner. Role visibility, deletion history, task-result retention and custom validation remain provider contracts; live qualification is separate.

​
SuiteQL tables

netsuite.table.observed({ table, columns, deletedRecordType? }) reads one SuiteQL table through POST /services/rest/query/v1/suiteql on the account named by the binding’s account setup, written as it appears in the REST host (https://<account>.suitetalk.api.netsuite.com, such as 1234567 or 1234567-sb1). Every request sends Prefer: transient. SuiteQL returns values as text and omits null columns, so each selected column is string | null. Each acquisition pass is two keyset walks ordered by (second, internal id):
  1. With deletedRecordType, the deletedrecord rows whose recordtype equals it, by deleteddate, published as explicit deletions of recordid.
  2. The table’s rows by lastmodifieddate.
Each page asks for rows strictly after the last (TO_CHAR(time), id) it read and continues while NetSuite states hasMore; no offset is followed. The rendered modification second (bijection_modified) is the row’s opaque version. The first pass walks both tables from the floor. Each finished pass carries the highest (second, id) each walk read (sync.carry), and the next pass walks from five minutes before each of them, so a row committed late with an earlier modification second is still read within that lag. Re-read rows deduplicate by version; two changes inside one second are indistinguishable. A pass that fails or leaves a gap hands nothing on. No pass claims coverage, and a row missing from a listing is never a deletion. Requirements and limits:
  • TO_CHAR renders in the integration user’s time zone. Give that user a zone without daylight saving (GMT): a repeated autumn hour renders out of order and a walk could step over rows inside it.
  • The deletedrecord column names and recordtype vocabulary are taken from NetSuite’s records catalog and have not been probed against an account.
  • A 429 (account concurrency exhausted) or 503 is a transient failure. Requests of one acquisition are sequential; concurrency shared with other integrations of the account is not coordinated.
  • This table mode declares no write.
Bind a netsuite credential whose allowed_resource_origins names the REST host: an oauth_client_credentials envelope with a client_assertion and private_key_jwt protocol (OAuth 2.0 machine-to-machine: a PS256 or ES256 key whose certificate is registered on the integration, its certificate id as kid, and the rest_webservices scope as a claim), or an oauth_refresh grant from the authorization-code flow.

​
Provider references

Provider references and prerequisites are maintained in the connector guidance above. No separate provider-documentation review date is recorded.

​
Source and evidence

Canonical connector source, native analysis and check receipts. Connector artifact: 905888ea276a2a28e36981a79e8142b2547ea451c3e63162cb6915ad4a7d1305. The resource declaration examples above are compiled and compared with exact catalog declarations. Recorded checks apply only to their source, declaration and runtime identities. Configure a connection and inspect its status to establish deployment-specific readiness.