@celigo/api-specs 0.2.232 → 0.2.234

package/dist/api.yml

@@ -8720,8 +8720,9 @@ components:
           description: |
             NetSuite TBA token ID (encrypted at rest). Required when authType is "token".
 
-            Generated in NetSuite under Setup > Users/Roles > Access Tokens, for the
-            integrator.io application and the user and role the connection should act as.
+            Generated in NetSuite under Setup > Users/Roles > Access Tokens, for the Application
+            the connection signs its requests with — `integrator.io` unless `_iClientId` names another
+            integration record — and the user and role the connection should act as.
             Must be paired with the corresponding tokenSecret.
           x-celigo-ai-guidance:
             - Not needed when authType is "token-auto" — integrator.io manages the token wiring in that mode.
@@ -8730,6 +8731,11 @@ components:
               (HTTP 200, `errors[].code`, source `application`) and the save sets the connection offline;
               the response carries no detail of what NetSuite refused — that detail is in NetSuite's
               Login Audit Trail (the Detail column), not in the connection's error.
+            - |-
+              A token created for a different Application than the one the connection signs with is
+              refused the same way, so when a freshly created token is refused, which Application it
+              was created for is the first question; a missing iClient is not the cause on a connection
+              that has none — it signs with Celigo's `integrator.io` record.
           writeOnly: true
         tokenSecret:
           type: string
@@ -8748,7 +8754,11 @@ components:
           type: string
           examples:
             - '1234'
-          description: NetSuite entity/user ID associated with the token.
+          description: |-
+            NetSuite internal id of the user (entity) whose access token the connection logs in
+            with. On a token-authenticated connection the platform records it from the token
+            NetSuite accepted, together with `roleId` and `roleName`; a value that still names the
+            previous token's user after a refused login is the symptom of the refusal, not its cause.
         tokenName:
           type: string
           examples:
@@ -8758,11 +8768,19 @@ components:
           type: string
           examples:
             - '3'
-          description: |
-            NetSuite role ID that determines the permissions for this connection.
-
-            The role controls which records, fields, and operations are accessible.
-            Must match the role associated with the access token in NetSuite.
+          description: |-
+            NetSuite internal id of the role the connection's access token logs in as — the role
+            selected when the token was created (`token`) or chosen on NetSuite's consent page during
+            Save & authorize (`token-auto`). The platform records it from the token NetSuite accepted,
+            together with `roleName` and `entityId`; the connection form has no role field for token
+            authentication, and a value that still names the previous token's role after a refused
+            login is the symptom of the refusal, not its cause.
+          x-celigo-ai-guidance:
+            - |-
+              On a token-authenticated connection a value sent on create or update is stored but has no
+              effect on the login — NetSuite applies the role bound to the token — and is replaced from
+              the token at the next successful login; never write it to "match" a new token or offer
+              to. The token is the change.
         requestLevelCredentials:
           type: boolean
           default: false
@@ -8805,7 +8823,9 @@ components:
           type: string
           examples:
             - Administrator
-          description: Human-readable name of the NetSuite role (display purposes only).
+          description: |-
+            Display name of the role in `roleId`, recorded with it from the token NetSuite accepted
+            (display purposes only).
         wsdlVersion:
           type: string
           examples:
@@ -8883,7 +8903,13 @@ components:
           x-celigo-refModel: iclients
           examples:
             - 66a1b2c3d4e5f60718293a4b
-          description: ID of the iClient used for token-based authentication.
+          description: |-
+            iClient holding the consumer key and secret of the NetSuite integration record the
+            connection signs its requests with, when that record is not Celigo's own — an Integration
+            App's record (set by the app's install) or the account's own; access tokens are then created
+            for that record's Application. Absent on a standalone connection, which signs with Celigo's
+            `integrator.io` record (no client ID or secret is entered anywhere) and whose access tokens
+            must be created for Application `integrator.io`.
     Salesforce:
       type: object
       description: |-

package/dist/audit.yml

@@ -153,7 +153,7 @@ paths:
               sync: Sync resource.
               tool: Tool resource for reusable building blocks.
               topic: Event Streams topic resource.
-              user: User access record resource.
+              user: User access record resource. Also carries account-setting changes, each identified by `fieldChanges[].fieldPath` (no separate settings resource type exists) — account-wide settings (company MFA, end-user MFA, API Management setup, execution logging, AI settings, the account alias, the API Builder timeout) with `_resourceId` = the account owner, a member's access settings (`accessLevel`, `disabled`, `accountMFARequired`) with `_resourceId` = that member — and user-level MFA events (setup, trusted devices, secret generated or viewed, reset) with `_resourceId` = the affected user, recorded in the audit log of that user's MFA master account (its "Account to reset MFA"), which is not always the account the change was made from.
           description: |-
             Filter by resource type (singular form). Unsupported values are
             rejected with 422 `audit_not_supported`.
@@ -214,10 +214,28 @@ paths:
             type: string
             examples:
               - http.auth.token.token
+              - authTypeMFA.trustDeviceForPeriod
+              - apim.subdomain
           description: |-
             Restrict the `fieldChanges` of returned entries to changes on this
-            field path. The value is not validated against known paths — an
-            unknown path simply matches nothing.
+            field path. The match is exact on the stored dot-path — `authTypeMFA`
+            does not match `authTypeMFA.trustDeviceForPeriod` — with no prefix or
+            wildcard form, and the filter stands alone or combines with
+            `resourceType`. The value is not validated against known paths — an
+            unknown path simply matches nothing. Account-setting changes are
+            `user` entries reached this way, one stored path each: company MFA
+            `authTypeMFA.dontAllowTrustedDevices` and
+            `authTypeMFA.trustDeviceForPeriod`; end-user MFA `endUserMfa.required`,
+            `endUserMfa.disallowTrustedDevices` and `endUserMfa.trustedDeviceDays`;
+            a user's own MFA
+            `authTypeMFA.enabled`, `authTypeMFA.trustedDevices`,
+            `authTypeMFA.secret` and `authTypeMFA._allowResetByUserId`; API
+            Management setup `apim.subdomain` and `apim.serviceAccountEmail`;
+            execution logging `logging.retentionPeriod` and
+            `logging.storePayload`; AI settings
+            `aiSettings.intelligentDocumentProcessing`; the account alias
+            `accountAlias`; the API Builder timeout `timeoutPeriod`; a member's
+            access `accessLevel`, `disabled` and `accountMFARequired`.
         - name: action
           in: query
           required: false
@@ -590,7 +608,7 @@ paths:
               sync: Sync resource.
               tool: Tool resource for reusable building blocks.
               topic: Event Streams topic resource.
-              user: User access record resource.
+              user: User access record resource. Also carries account-setting changes, each identified by `fieldChanges[].fieldPath` (no separate settings resource type exists) — account-wide settings (company MFA, end-user MFA, API Management setup, execution logging, AI settings, the account alias, the API Builder timeout) with `_resourceId` = the account owner, a member's access settings (`accessLevel`, `disabled`, `accountMFARequired`) with `_resourceId` = that member — and user-level MFA events (setup, trusted devices, secret generated or viewed, reset) with `_resourceId` = the affected user, recorded in the audit log of that user's MFA master account (its "Account to reset MFA"), which is not always the account the change was made from.
           description: Optional filter by resource type (singular form).
         - name: _byUserId
           in: query
@@ -1530,7 +1548,7 @@ components:
             sync: Sync resource.
             tool: Tool resource for reusable building blocks.
             topic: Event Streams topic resource.
-            user: User access record resource.
+            user: User access record resource. Also carries account-setting changes, each identified by `fieldChanges[].fieldPath` (no separate settings resource type exists) — account-wide settings (company MFA, end-user MFA, API Management setup, execution logging, AI settings, the account alias, the API Builder timeout) with `_resourceId` = the account owner, a member's access settings (`accessLevel`, `disabled`, `accountMFARequired`) with `_resourceId` = that member — and user-level MFA events (setup, trusted devices, secret generated or viewed, reset) with `_resourceId` = the affected user, recorded in the audit log of that user's MFA master account (its "Account to reset MFA"), which is not always the account the change was made from.
         _resourceId:
           type: string
           format: objectId
@@ -1744,7 +1762,7 @@ components:
               sync: Sync resource.
               tool: Tool resource for reusable building blocks.
               topic: Event Streams topic resource.
-              user: User access record resource.
+              user: User access record resource. Also carries account-setting changes, each identified by `fieldChanges[].fieldPath` (no separate settings resource type exists) — account-wide settings (company MFA, end-user MFA, API Management setup, execution logging, AI settings, the account alias, the API Builder timeout) with `_resourceId` = the account owner, a member's access settings (`accessLevel`, `disabled`, `accountMFARequired`) with `_resourceId` = that member — and user-level MFA events (setup, trusted devices, secret generated or viewed, reset) with `_resourceId` = the affected user, recorded in the audit log of that user's MFA master account (its "Account to reset MFA"), which is not always the account the change was made from.
           examples:
             - - connection
               - agent
@@ -1965,7 +1983,7 @@ components:
             sync: Sync resource.
             tool: Tool resource for reusable building blocks.
             topic: Event Streams topic resource.
-            user: User access record resource.
+            user: User access record resource. Also carries account-setting changes, each identified by `fieldChanges[].fieldPath` (no separate settings resource type exists) — account-wide settings (company MFA, end-user MFA, API Management setup, execution logging, AI settings, the account alias, the API Builder timeout) with `_resourceId` = the account owner, a member's access settings (`accessLevel`, `disabled`, `accountMFARequired`) with `_resourceId` = that member — and user-level MFA events (setup, trusted devices, secret generated or viewed, reset) with `_resourceId` = the affected user, recorded in the audit log of that user's MFA master account (its "Account to reset MFA"), which is not always the account the change was made from.
         source:
           type: string
           enum:

package/dist/connection.yml

@@ -4532,8 +4532,9 @@ components:
           description: |
             NetSuite TBA token ID (encrypted at rest). Required when authType is "token".
 
-            Generated in NetSuite under Setup > Users/Roles > Access Tokens, for the
-            integrator.io application and the user and role the connection should act as.
+            Generated in NetSuite under Setup > Users/Roles > Access Tokens, for the Application
+            the connection signs its requests with — `integrator.io` unless `_iClientId` names another
+            integration record — and the user and role the connection should act as.
             Must be paired with the corresponding tokenSecret.
           x-celigo-ai-guidance:
             - Not needed when authType is "token-auto" — integrator.io manages the token wiring in that mode.
@@ -4542,6 +4543,11 @@ components:
               (HTTP 200, `errors[].code`, source `application`) and the save sets the connection offline;
               the response carries no detail of what NetSuite refused — that detail is in NetSuite's
               Login Audit Trail (the Detail column), not in the connection's error.
+            - |-
+              A token created for a different Application than the one the connection signs with is
+              refused the same way, so when a freshly created token is refused, which Application it
+              was created for is the first question; a missing iClient is not the cause on a connection
+              that has none — it signs with Celigo's `integrator.io` record.
           writeOnly: true
         tokenSecret:
           type: string
@@ -4560,7 +4566,11 @@ components:
           type: string
           examples:
             - '1234'
-          description: NetSuite entity/user ID associated with the token.
+          description: |-
+            NetSuite internal id of the user (entity) whose access token the connection logs in
+            with. On a token-authenticated connection the platform records it from the token
+            NetSuite accepted, together with `roleId` and `roleName`; a value that still names the
+            previous token's user after a refused login is the symptom of the refusal, not its cause.
         tokenName:
           type: string
           examples:
@@ -4570,11 +4580,19 @@ components:
           type: string
           examples:
             - '3'
-          description: |
-            NetSuite role ID that determines the permissions for this connection.
-
-            The role controls which records, fields, and operations are accessible.
-            Must match the role associated with the access token in NetSuite.
+          description: |-
+            NetSuite internal id of the role the connection's access token logs in as — the role
+            selected when the token was created (`token`) or chosen on NetSuite's consent page during
+            Save & authorize (`token-auto`). The platform records it from the token NetSuite accepted,
+            together with `roleName` and `entityId`; the connection form has no role field for token
+            authentication, and a value that still names the previous token's role after a refused
+            login is the symptom of the refusal, not its cause.
+          x-celigo-ai-guidance:
+            - |-
+              On a token-authenticated connection a value sent on create or update is stored but has no
+              effect on the login — NetSuite applies the role bound to the token — and is replaced from
+              the token at the next successful login; never write it to "match" a new token or offer
+              to. The token is the change.
         requestLevelCredentials:
           type: boolean
           default: false
@@ -4617,7 +4635,9 @@ components:
           type: string
           examples:
             - Administrator
-          description: Human-readable name of the NetSuite role (display purposes only).
+          description: |-
+            Display name of the role in `roleId`, recorded with it from the token NetSuite accepted
+            (display purposes only).
         wsdlVersion:
           type: string
           examples:
@@ -4695,7 +4715,13 @@ components:
           x-celigo-refModel: iclients
           examples:
             - 66a1b2c3d4e5f60718293a4b
-          description: ID of the iClient used for token-based authentication.
+          description: |-
+            iClient holding the consumer key and secret of the NetSuite integration record the
+            connection signs its requests with, when that record is not Celigo's own — an Integration
+            App's record (set by the app's install) or the account's own; access tokens are then created
+            for that record's Application. Absent on a standalone connection, which signs with Celigo's
+            `integrator.io` record (no client ID or secret is entered anywhere) and whose access tokens
+            must be created for Application `integrator.io`.
     Salesforce:
       type: object
       description: |-

package/dist/enduser.yml

@@ -2557,8 +2557,9 @@ components:
           description: |
             NetSuite TBA token ID (encrypted at rest). Required when authType is "token".
 
-            Generated in NetSuite under Setup > Users/Roles > Access Tokens, for the
-            integrator.io application and the user and role the connection should act as.
+            Generated in NetSuite under Setup > Users/Roles > Access Tokens, for the Application
+            the connection signs its requests with — `integrator.io` unless `_iClientId` names another
+            integration record — and the user and role the connection should act as.
             Must be paired with the corresponding tokenSecret.
           x-celigo-ai-guidance:
             - Not needed when authType is "token-auto" — integrator.io manages the token wiring in that mode.
@@ -2567,6 +2568,11 @@ components:
               (HTTP 200, `errors[].code`, source `application`) and the save sets the connection offline;
               the response carries no detail of what NetSuite refused — that detail is in NetSuite's
               Login Audit Trail (the Detail column), not in the connection's error.
+            - |-
+              A token created for a different Application than the one the connection signs with is
+              refused the same way, so when a freshly created token is refused, which Application it
+              was created for is the first question; a missing iClient is not the cause on a connection
+              that has none — it signs with Celigo's `integrator.io` record.
           writeOnly: true
         tokenSecret:
           type: string
@@ -2585,7 +2591,11 @@ components:
           type: string
           examples:
             - '1234'
-          description: NetSuite entity/user ID associated with the token.
+          description: |-
+            NetSuite internal id of the user (entity) whose access token the connection logs in
+            with. On a token-authenticated connection the platform records it from the token
+            NetSuite accepted, together with `roleId` and `roleName`; a value that still names the
+            previous token's user after a refused login is the symptom of the refusal, not its cause.
         tokenName:
           type: string
           examples:
@@ -2595,11 +2605,19 @@ components:
           type: string
           examples:
             - '3'
-          description: |
-            NetSuite role ID that determines the permissions for this connection.
-
-            The role controls which records, fields, and operations are accessible.
-            Must match the role associated with the access token in NetSuite.
+          description: |-
+            NetSuite internal id of the role the connection's access token logs in as — the role
+            selected when the token was created (`token`) or chosen on NetSuite's consent page during
+            Save & authorize (`token-auto`). The platform records it from the token NetSuite accepted,
+            together with `roleName` and `entityId`; the connection form has no role field for token
+            authentication, and a value that still names the previous token's role after a refused
+            login is the symptom of the refusal, not its cause.
+          x-celigo-ai-guidance:
+            - |-
+              On a token-authenticated connection a value sent on create or update is stored but has no
+              effect on the login — NetSuite applies the role bound to the token — and is replaced from
+              the token at the next successful login; never write it to "match" a new token or offer
+              to. The token is the change.
         requestLevelCredentials:
           type: boolean
           default: false
@@ -2642,7 +2660,9 @@ components:
           type: string
           examples:
             - Administrator
-          description: Human-readable name of the NetSuite role (display purposes only).
+          description: |-
+            Display name of the role in `roleId`, recorded with it from the token NetSuite accepted
+            (display purposes only).
         wsdlVersion:
           type: string
           examples:
@@ -2720,7 +2740,13 @@ components:
           x-celigo-refModel: iclients
           examples:
             - 66a1b2c3d4e5f60718293a4b
-          description: ID of the iClient used for token-based authentication.
+          description: |-
+            iClient holding the consumer key and secret of the NetSuite integration record the
+            connection signs its requests with, when that record is not Celigo's own — an Integration
+            App's record (set by the app's install) or the account's own; access tokens are then created
+            for that record's Application. Absent on a standalone connection, which signs with Celigo's
+            `integrator.io` record (no client ID or secret is entered anywhere) and whose access tokens
+            must be created for Application `integrator.io`.
     Salesforce:
       type: object
       description: |-

package/dist/export.yml

@@ -287,6 +287,7 @@ paths:
         |------|------------|-------------|
         | `/debugUntil` | `replace`, `add`, `remove` | Step debug-capture expiry (ISO-8601, at most 3600 seconds from now — a later value is rejected with 422 `update_not_allowed`); `remove` stops capture and succeeds even when the field is absent |
         | `/assistantMetadata` | `replace` | Assistant metadata object |
+        | `/_networkPolicyId` | `add`, `replace`, `remove` | Network policy on a `webhook` or `distributed` listener; `remove` clears the assignment. An id that is not one of the environment's network policies is rejected with 400 `network_policy_not_found` |
 
         All other paths are rejected with `422`.
       operationId: patchExport
@@ -1483,7 +1484,7 @@ components:
       required:
         - verify
       x-celigo-ui-override: 'verify is required by the webhook listener form for every provider (exports/webhook.js: verify required:true; on a connector-backed listener the form pre-fills it from the connector definition before saving). The API enforces it only when provider is custom or absent — 422 missing_required_field on webhook.verify, "verify is required for export type webhook, provider = custom". For the named providers probed (slack, shopify, github) it stores a listener posted with key and no verify (201 each; the GET carries provider, key and formType simple) and requires a credential instead: without key (and no token) each answers 422 missing_required_field on webhook.key — "key is required for slack verification" / "key is required for shopify verification" / "key is required for github verification"; a slack listener posted with token and no key saved. Other named providers are unprobed. The requirement is kept so an authored document matches a form-saved one.'
-      description: Configuration for webhook listeners that receive data through incoming HTTP requests. Required when the export's `type` is `webhook`; omit for other export types. Senders POST to the export's listener URL, `https://api.integrator.io/v1/exports/{_id}/data` (or the same path on the account's regional API host); the platform validates each request using the configured `verify` method, passes the payload to subsequent flow steps, and returns a configurable HTTP response to the caller. A request is answered 204 by default when accepted, 401 when it fails verification, and 403 `unable_to_run_flows` while every flow the export feeds is disabled; a refused request is not queued, so the sender must resend it.
+      description: Configuration for webhook listeners that receive data through incoming HTTP requests. Required when the export's `type` is `webhook`; omit for other export types. Senders POST to the export's listener URL, `https://api.integrator.io/v1/exports/{_id}/data` (or the same path on the account's regional API host); the platform validates each request using the configured `verify` method, passes the payload to subsequent flow steps, and returns a configurable HTTP response to the caller. A request is answered 204 by default when accepted, 401 when it fails verification, 403 `unable_to_run_flows` while every flow the export feeds is disabled, and 403 `access_denied` when the export's `_networkPolicyId` policy does not admit the sender's address (checked before verification, with a valid or an invalid token alike, where enforcement is enabled for the account); a refused request is not queued, so the sender must resend it once the cause is cleared.
       x-celigo-ai-guidance:
         - Configuration object for real-time event listeners that receive data via incoming HTTP requests.
         - |-
@@ -17385,6 +17386,33 @@ components:
             - 'The listener must be an export with `type: "webhook"` and `webhook.provider: "integrator-extension"`; any other export id is rejected with `invalid_post_parse_listener`. On an HTTP export outside file mode the save is rejected with `post_parse_listener_not_supported`: "Listener for functional acknowledgment is only supported for AS2, FTP, S3 and HTTP file export."'
           examples:
             - 60a2c4e6f321d800129a1a3c
+        _networkPolicyId:
+          type:
+            - string
+            - 'null'
+          format: objectId
+          x-celigo-refModel: networkpolicies
+          description: |-
+            Network policy whose IP allow and deny lists gate the requests that deliver data to this
+            listener. Only `type` `webhook` or `distributed` exports accept it; any other type fails
+            with 422 `not_allowed`. An id that is not one of the environment's network policies,
+            including one in the recycle bin, fails with 400 `network_policy_not_found`. Preserved
+            when omitted on PUT; send `null`, or `remove` it with `PATCH /v1/exports/{_id}` (which
+            also accepts `add` and `replace` with an id), to clear it. Deleting the policy with
+            `?force=true` clears it too. Absent from responses when no policy is assigned.
+
+            Where network-policy enforcement is enabled for the account, a webhook delivery to the
+            listener's `/data` route from an address the policy does not admit is refused with 403
+            `access_denied` — with a valid verification token or an invalid one alike, never 401 —
+            before the listener's verification runs and before the payload is read, so nothing is
+            queued and no flow run starts; an authenticated `GET` or `HEAD` of that route from such an
+            address is refused the same way. Enforcement on listeners is enabled per account. The
+            assignment is recorded in the export's audit as a `_networkPolicyId` field change carrying
+            the policy id.
+          x-celigo-ai-guidance:
+            - 'Assign by sending the whole export document with `_networkPolicyId` set (the form''s own save does the same) and clear it with an explicit `null` — a PUT that omits the field keeps the current policy, so a removed key is a silent no-op, not an unassignment. Resolve the policy id from `GET /v1/networkpolicies` in the same environment first: an unknown or recycled id is refused only at save time with 400 `network_policy_not_found`.'
+          examples:
+            - 6ab1ebbfb9e4547494ff7558
         externalId:
           type:
             - string

package/dist/iclient.yml

@@ -3005,59 +3005,18 @@ components:
                   and can be referenced by resources within integrator.io through the iClient.
         netsuite:
           type: object
-          description: NetSuite token-based authentication credentials.
+          description: |-
+            Consumer key and consumer secret of a NetSuite integration record, for a connection that
+            signs its requests as that record rather than as Celigo's own `integrator.io` record — an
+            Integration App's record (its install creates the iClient) or one the account created. A
+            standalone NetSuite connection references no iClient; its access tokens are created for
+            Application `integrator.io`.
           x-celigo-ai-guidance:
             - |-
-              Configuration settings and credentials required to integrate with the NetSuite platform,
-              enabling seamless data synchronization and interaction with NetSuite's ERP and CRM services.
-              This property typically includes authentication details, API endpoints,
-              and any necessary parameters for establishing a secure connection.
-            - |-
-              ## IMPORTANT NOTES:
-              - Incorrect or outdated credentials will prevent successful integration.
-              - NetSuite API limits and governance should be considered to avoid throttling.
-              - Regularly review and rotate credentials to maintain security.
-              - Integration may require specific permissions within NetSuite roles.
-            - |-
-              ## IMPLEMENTATION GUIDANCE:
-              - Ensure sensitive credentials are stored securely and encrypted.
-              - Validate all required fields before attempting connection to NetSuite.
-              - Support environment-specific configurations (e.g., sandbox vs. production).
-              - Handle error responses gracefully to maintain integration stability.
-              - Keep the configuration up to date with NetSuite API version changes.
-            - |-
-              ## TECHNICAL DETAILS:
-              - Typically includes OAuth 1.0a or token-based authentication parameters.
-              - May require JSON or XML formatted configuration data.
-              - Supports both REST and SOAP API protocols depending on use case.
-              - Configuration format should align with NetSuite's API specification requirements.
-            - |-
-              ## FIELD BEHAVIOR:
-              - Holds all necessary information to authenticate and communicate with NetSuite APIs.
-              - Used to configure integration settings such as account ID, role, and environment.
-              - Enables data exchange between the application and NetSuite for operations like record creation, updates, and queries.
-              - May support multiple authentication methods, including token-based and OAuth.
-            - |-
-              ## EXAMPLES:
-              - API credentials including consumer key, consumer secret, token ID, and token secret.
-              - Account ID and role ID for specifying the NetSuite account and user role.
-              - URLs for NetSuite REST or SOAP API endpoints.
-              - Flags or settings indicating sandbox or production environment.
-            - |-
-              ## DEPENDENCY CHAIN:
-              - Dependent on secure storage mechanisms for credentials.
-              - Relies on network connectivity to NetSuite services.
-              - May depend on other configuration properties like logging or retry policies.
-            - |-
-              Configuration settings and credentials required to integrate with the NetSuite platform,
-              enabling seamless data synchronization and interaction with NetSuite's ERP and CRM services.
-              This property typically includes authentication details, API endpoints,
-              and any necessary parameters for establishing a secure connection.
-            - |-
-              Configuration settings and credentials required to integrate with the NetSuite platform,
-              enabling seamless data synchronization and interaction with NetSuite's ERP and CRM services.
-              This property typically includes authentication details, API endpoints,
-              and any necessary parameters for establishing a secure connection.
+              A connection that references a NetSuite iClient needs access tokens created for that
+              record's Application; a connection without one needs tokens created for `integrator.io`.
+              A missing iClient is not why a connection that has none is refused with
+              `invalid_login_attempt`.
           properties:
             consumerKey:
               type: string

package/dist/mcp-server.yml

@@ -5605,8 +5605,9 @@ components:
           description: |
             NetSuite TBA token ID (encrypted at rest). Required when authType is "token".
 
-            Generated in NetSuite under Setup > Users/Roles > Access Tokens, for the
-            integrator.io application and the user and role the connection should act as.
+            Generated in NetSuite under Setup > Users/Roles > Access Tokens, for the Application
+            the connection signs its requests with — `integrator.io` unless `_iClientId` names another
+            integration record — and the user and role the connection should act as.
             Must be paired with the corresponding tokenSecret.
           x-celigo-ai-guidance:
             - Not needed when authType is "token-auto" — integrator.io manages the token wiring in that mode.
@@ -5615,6 +5616,11 @@ components:
               (HTTP 200, `errors[].code`, source `application`) and the save sets the connection offline;
               the response carries no detail of what NetSuite refused — that detail is in NetSuite's
               Login Audit Trail (the Detail column), not in the connection's error.
+            - |-
+              A token created for a different Application than the one the connection signs with is
+              refused the same way, so when a freshly created token is refused, which Application it
+              was created for is the first question; a missing iClient is not the cause on a connection
+              that has none — it signs with Celigo's `integrator.io` record.
           writeOnly: true
         tokenSecret:
           type: string
@@ -5633,7 +5639,11 @@ components:
           type: string
           examples:
             - '1234'
-          description: NetSuite entity/user ID associated with the token.
+          description: |-
+            NetSuite internal id of the user (entity) whose access token the connection logs in
+            with. On a token-authenticated connection the platform records it from the token
+            NetSuite accepted, together with `roleId` and `roleName`; a value that still names the
+            previous token's user after a refused login is the symptom of the refusal, not its cause.
         tokenName:
           type: string
           examples:
@@ -5643,11 +5653,19 @@ components:
           type: string
           examples:
             - '3'
-          description: |
-            NetSuite role ID that determines the permissions for this connection.
-
-            The role controls which records, fields, and operations are accessible.
-            Must match the role associated with the access token in NetSuite.
+          description: |-
+            NetSuite internal id of the role the connection's access token logs in as — the role
+            selected when the token was created (`token`) or chosen on NetSuite's consent page during
+            Save & authorize (`token-auto`). The platform records it from the token NetSuite accepted,
+            together with `roleName` and `entityId`; the connection form has no role field for token
+            authentication, and a value that still names the previous token's role after a refused
+            login is the symptom of the refusal, not its cause.
+          x-celigo-ai-guidance:
+            - |-
+              On a token-authenticated connection a value sent on create or update is stored but has no
+              effect on the login — NetSuite applies the role bound to the token — and is replaced from
+              the token at the next successful login; never write it to "match" a new token or offer
+              to. The token is the change.
         requestLevelCredentials:
           type: boolean
           default: false
@@ -5690,7 +5708,9 @@ components:
           type: string
           examples:
             - Administrator
-          description: Human-readable name of the NetSuite role (display purposes only).
+          description: |-
+            Display name of the role in `roleId`, recorded with it from the token NetSuite accepted
+            (display purposes only).
         wsdlVersion:
           type: string
           examples:
@@ -5768,7 +5788,13 @@ components:
           x-celigo-refModel: iclients
           examples:
             - 66a1b2c3d4e5f60718293a4b
-          description: ID of the iClient used for token-based authentication.
+          description: |-
+            iClient holding the consumer key and secret of the NetSuite integration record the
+            connection signs its requests with, when that record is not Celigo's own — an Integration
+            App's record (set by the app's install) or the account's own; access tokens are then created
+            for that record's Application. Absent on a standalone connection, which signs with Celigo's
+            `integrator.io` record (no client ID or secret is entered anywhere) and whose access tokens
+            must be created for Application `integrator.io`.
     Salesforce:
       type: object
       description: |-

package/dist/networkpolicy.yml

@@ -2,12 +2,13 @@ openapi: 3.2.0
 info:
   version: 1.0.0
   title: Network Policies
-  description: Manage IP allow and deny lists that restrict where API tokens, MCP servers, and users may connect from.
+  description: Manage IP allow and deny lists that restrict where API tokens, MCP servers, webhook listeners, and users may connect from.
   x-celigo-ai-guidance:
     - |-
       API for managing network policies — named IP allow/deny lists that are assigned to API tokens
-      (`_networkPolicyId`), MCP servers (`_networkPolicyId`), or account sign-in settings to restrict
-      the source addresses a caller may connect from. A policy restricts nothing until it is assigned.
+      (`_networkPolicyId`), MCP servers (`_networkPolicyId`), webhook and distributed listener exports
+      (`_networkPolicyId`), or account sign-in settings to restrict the source addresses a caller may
+      connect from. A policy restricts nothing until it is assigned.
 servers:
   - url: https://api.integrator.io
     description: Production (US / default region)
@@ -22,11 +23,11 @@ security:
 tags:
   - name: Network Policies
     description: |-
-      Network policies are named IP allow and deny lists that control where API tokens, MCP servers, and users may connect from. A policy takes effect only once it is assigned — through `_networkPolicyId` on an API token or MCP server, or in account settings for workspace-user and end-user sign-in — and each environment (production or sandbox) keeps its own library of policies. Network policies must be enabled for the account, and only the account owner and administrators can manage them.
+      Network policies are named IP allow and deny lists that control where API tokens, MCP servers, webhook listeners, and users may connect from. A policy takes effect only once it is assigned — through `_networkPolicyId` on an API token, an MCP server, or a webhook or distributed listener export, or in account settings for workspace-user and end-user sign-in — and each environment (production or sandbox) keeps its own library of policies. Network policies must be enabled for the account, and only the account owner and administrators can manage them.
 
-      Every policy that applies to a call must admit the caller. An API token's policy is checked when the token authenticates, before the request runs; an MCP server's policy is checked on every request to it, so a call to an MCP server passes both its token's policy and the server's. A personal access token has no policy of its own: it is checked against the workspace-user sign-in policy of the environment it belongs to. Sign-in policies are checked when a workspace user signs in or switches account or environment, and when an end user signs in to an MCP server.
+      Every policy that applies to a call must admit the caller. An API token's policy is checked when the token authenticates, before the request runs; an MCP server's policy is checked on every request to it, so a call to an MCP server passes both its token's policy and the server's. A personal access token has no policy of its own: it is checked against the workspace-user sign-in policy of the environment it belongs to. Sign-in policies are checked when a workspace user signs in or switches account or environment, and when an end user signs in to an MCP server. A webhook listener's policy is checked on every delivery to its `/data` route — the source system's deliveries carry no Celigo identity, so the listener's own policy is the only one that applies to them — before the listener's verification runs and before the payload is read, and on authenticated reads of that route; enforcement on listeners is enabled per account.
 
-      A refused call gets HTTP 403 with `{"errors": [{"code": "access_denied", "message": "Access denied."}]}` and nothing that names the policy or the address. An MCP server endpoint speaks JSON-RPC, so its 403 carries the MCP server's access-denied error (`-32006`) in a JSON-RPC envelope instead — `{"jsonrpc": "2.0", "error": {"code": -32006, "message": "Access denied."}, "id": <request id>}`, with `id` echoed when the request had one — and the server's request log records the call as blocked.
+      A refused call gets HTTP 403 with `{"errors": [{"code": "access_denied", "message": "Access denied."}]}` and nothing that names the policy or the address. An MCP server endpoint speaks JSON-RPC, so its 403 carries the MCP server's access-denied error (`-32006`) in a JSON-RPC envelope instead — `{"jsonrpc": "2.0", "error": {"code": -32006, "message": "Access denied."}, "id": <request id>}`, with `id` echoed when the request had one — and the server's request log records the call as blocked. A refused listener delivery is not queued and starts no flow run.
 
       ## Network policy schema
 
@@ -128,7 +129,7 @@ paths:
         validated and stored in normalized form — a bare address becomes `/32` or
         `/128`, IPv6 is compressed — and the response shows the stored values. The new
         policy restricts nothing until it is assigned to an API token, an MCP server,
-        or account sign-in.
+        a webhook or real-time listener export, or account sign-in.
       operationId: createNetworkPolicy
       tags:
         - Network Policies
@@ -243,7 +244,8 @@ paths:
         omitted `description` is removed and an omitted `ipAllowList` or `ipDenyList`
         becomes empty, which lifts every restriction that list imposed. Entries are
         validated and normalized exactly as on create. The change applies to every
-        token, MCP server, and sign-in setting the policy is assigned to.
+        token, MCP server, listener export, and sign-in setting the policy is
+        assigned to.
       operationId: updateNetworkPolicy
       tags:
         - Network Policies
@@ -399,8 +401,8 @@ paths:
       summary: Delete a network policy
       description: |-
         Moves the policy to the recycle bin, where it is retained for 30 days and can
-        be restored. A policy that is still assigned to an API token, MCP server, or
-        account sign-in setting is not deleted: the request fails with 409
+        be restored. A policy that is still assigned to an API token, MCP server,
+        listener export, or account sign-in setting is not deleted: the request fails with 409
         `network_policy_in_use` and `info` lists every assignment. Repeat with
         `force=true` to clear those assignments and delete the policy — every principal
         it was assigned to loses the restriction. Use `GET /v1/networkpolicies/{_id}/dependencies`
@@ -423,9 +425,9 @@ paths:
           in: query
           required: false
           description: |-
-            When true, clears the policy from every API token, MCP server, and account
-            sign-in setting it is assigned to, then deletes it. Without it, an assigned
-            policy returns 409 and nothing changes.
+            When true, clears the policy from every API token, MCP server, listener
+            export, and account sign-in setting it is assigned to, then deletes it.
+            Without it, an assigned policy returns 409 and nothing changes.
           schema:
             type: boolean
             default: false
@@ -448,8 +450,8 @@ paths:
         - Network Policies
       summary: List assignments of a network policy
       description: |-
-        Returns every API token, MCP server, and account sign-in setting the policy is
-        assigned to within its own environment. Call it before `DELETE` to see what a
+        Returns every API token, MCP server, listener export, and account sign-in setting
+        the policy is assigned to within its own environment. Call it before `DELETE` to see what a
         `force=true` delete would clear. Unlike other `/dependencies` endpoints, the
         response is a fixed object rather than a map keyed by resource type.
       parameters:
@@ -472,12 +474,15 @@ paths:
                 $ref: '#/components/schemas/NetworkPolicyDependencies'
               examples:
                 assigned:
-                  summary: Assigned to an MCP server
+                  summary: Assigned to an MCP server and a webhook listener
                   value:
                     mcpservers:
                       - _id: 6ab1f4a95af4c5a3ea6b0a28
                         name: Order lookup MCP server
                     accesstokens: []
+                    exports:
+                      - _id: 6aeb0ddf1f97adaf3db4152b
+                        name: Orders webhook listener
                     account:
                       workspaceUsers: false
                       workspaceUserEnvironments: []
@@ -488,6 +493,7 @@ paths:
                   value:
                     mcpservers: []
                     accesstokens: []
+                    exports: []
                     account:
                       workspaceUsers: false
                       workspaceUserEnvironments: []
@@ -1033,6 +1039,7 @@ components:
       required:
         - mcpservers
         - accesstokens
+        - exports
         - account
       properties:
         mcpservers:
@@ -1045,6 +1052,11 @@ components:
           description: API tokens whose `_networkPolicyId` is this policy. Personal access tokens never appear here; they inherit the account's workspace-user policy instead.
           items:
             $ref: '#/components/schemas/NetworkPolicyDependencyRef'
+        exports:
+          type: array
+          description: Webhook and distributed (real-time) listener exports whose `_networkPolicyId` is this policy. Each one is also listed under `info.exports` when a `DELETE` without `force=true` is refused.
+          items:
+            $ref: '#/components/schemas/NetworkPolicyDependencyRef'
         account:
           type: object
           description: Account sign-in assignments of this policy, resolved per environment.
@@ -1199,8 +1211,8 @@ components:
                     message: The requested resource was not found.
     409-in-use:
       description: |-
-        Conflict. The policy is still assigned to at least one API token, MCP server, or
-        account sign-in setting, so it was not deleted. `info` lists every assignment;
+        Conflict. The policy is still assigned to at least one API token, MCP server,
+        listener export, or account sign-in setting, so it was not deleted. `info` lists every assignment;
         repeat the request with `force=true` to clear them and delete the policy.
       content:
         application/json:
@@ -1224,6 +1236,7 @@ components:
                   accesstokens:
                     - _id: 6ab1f6a338d7733b4599ec83
                       name: Warehouse sync token
+                  exports: []
                   account:
                     workspaceUsers: false
                     workspaceUserEnvironments: []

package/dist/tool.yml

@@ -8087,8 +8087,9 @@ components:
           description: |
             NetSuite TBA token ID (encrypted at rest). Required when authType is "token".
 
-            Generated in NetSuite under Setup > Users/Roles > Access Tokens, for the
-            integrator.io application and the user and role the connection should act as.
+            Generated in NetSuite under Setup > Users/Roles > Access Tokens, for the Application
+            the connection signs its requests with — `integrator.io` unless `_iClientId` names another
+            integration record — and the user and role the connection should act as.
             Must be paired with the corresponding tokenSecret.
           x-celigo-ai-guidance:
             - Not needed when authType is "token-auto" — integrator.io manages the token wiring in that mode.
@@ -8097,6 +8098,11 @@ components:
               (HTTP 200, `errors[].code`, source `application`) and the save sets the connection offline;
               the response carries no detail of what NetSuite refused — that detail is in NetSuite's
               Login Audit Trail (the Detail column), not in the connection's error.
+            - |-
+              A token created for a different Application than the one the connection signs with is
+              refused the same way, so when a freshly created token is refused, which Application it
+              was created for is the first question; a missing iClient is not the cause on a connection
+              that has none — it signs with Celigo's `integrator.io` record.
           writeOnly: true
         tokenSecret:
           type: string
@@ -8115,7 +8121,11 @@ components:
           type: string
           examples:
             - '1234'
-          description: NetSuite entity/user ID associated with the token.
+          description: |-
+            NetSuite internal id of the user (entity) whose access token the connection logs in
+            with. On a token-authenticated connection the platform records it from the token
+            NetSuite accepted, together with `roleId` and `roleName`; a value that still names the
+            previous token's user after a refused login is the symptom of the refusal, not its cause.
         tokenName:
           type: string
           examples:
@@ -8125,11 +8135,19 @@ components:
           type: string
           examples:
             - '3'
-          description: |
-            NetSuite role ID that determines the permissions for this connection.
-
-            The role controls which records, fields, and operations are accessible.
-            Must match the role associated with the access token in NetSuite.
+          description: |-
+            NetSuite internal id of the role the connection's access token logs in as — the role
+            selected when the token was created (`token`) or chosen on NetSuite's consent page during
+            Save & authorize (`token-auto`). The platform records it from the token NetSuite accepted,
+            together with `roleName` and `entityId`; the connection form has no role field for token
+            authentication, and a value that still names the previous token's role after a refused
+            login is the symptom of the refusal, not its cause.
+          x-celigo-ai-guidance:
+            - |-
+              On a token-authenticated connection a value sent on create or update is stored but has no
+              effect on the login — NetSuite applies the role bound to the token — and is replaced from
+              the token at the next successful login; never write it to "match" a new token or offer
+              to. The token is the change.
         requestLevelCredentials:
           type: boolean
           default: false
@@ -8172,7 +8190,9 @@ components:
           type: string
           examples:
             - Administrator
-          description: Human-readable name of the NetSuite role (display purposes only).
+          description: |-
+            Display name of the role in `roleId`, recorded with it from the token NetSuite accepted
+            (display purposes only).
         wsdlVersion:
           type: string
           examples:
@@ -8250,7 +8270,13 @@ components:
           x-celigo-refModel: iclients
           examples:
             - 66a1b2c3d4e5f60718293a4b
-          description: ID of the iClient used for token-based authentication.
+          description: |-
+            iClient holding the consumer key and secret of the NetSuite integration record the
+            connection signs its requests with, when that record is not Celigo's own — an Integration
+            App's record (set by the app's install) or the account's own; access tokens are then created
+            for that record's Application. Absent on a standalone connection, which signs with Celigo's
+            `integrator.io` record (no client ID or secret is entered anywhere) and whose access tokens
+            must be created for Application `integrator.io`.
     Salesforce:
       type: object
       description: |-
@@ -28018,7 +28044,7 @@ components:
       required:
         - verify
       x-celigo-ui-override: 'verify is required by the webhook listener form for every provider (exports/webhook.js: verify required:true; on a connector-backed listener the form pre-fills it from the connector definition before saving). The API enforces it only when provider is custom or absent — 422 missing_required_field on webhook.verify, "verify is required for export type webhook, provider = custom". For the named providers probed (slack, shopify, github) it stores a listener posted with key and no verify (201 each; the GET carries provider, key and formType simple) and requires a credential instead: without key (and no token) each answers 422 missing_required_field on webhook.key — "key is required for slack verification" / "key is required for shopify verification" / "key is required for github verification"; a slack listener posted with token and no key saved. Other named providers are unprobed. The requirement is kept so an authored document matches a form-saved one.'
-      description: Configuration for webhook listeners that receive data through incoming HTTP requests. Required when the export's `type` is `webhook`; omit for other export types. Senders POST to the export's listener URL, `https://api.integrator.io/v1/exports/{_id}/data` (or the same path on the account's regional API host); the platform validates each request using the configured `verify` method, passes the payload to subsequent flow steps, and returns a configurable HTTP response to the caller. A request is answered 204 by default when accepted, 401 when it fails verification, and 403 `unable_to_run_flows` while every flow the export feeds is disabled; a refused request is not queued, so the sender must resend it.
+      description: Configuration for webhook listeners that receive data through incoming HTTP requests. Required when the export's `type` is `webhook`; omit for other export types. Senders POST to the export's listener URL, `https://api.integrator.io/v1/exports/{_id}/data` (or the same path on the account's regional API host); the platform validates each request using the configured `verify` method, passes the payload to subsequent flow steps, and returns a configurable HTTP response to the caller. A request is answered 204 by default when accepted, 401 when it fails verification, 403 `unable_to_run_flows` while every flow the export feeds is disabled, and 403 `access_denied` when the export's `_networkPolicyId` policy does not admit the sender's address (checked before verification, with a valid or an invalid token alike, where enforcement is enabled for the account); a refused request is not queued, so the sender must resend it once the cause is cleared.
       x-celigo-ai-guidance:
         - Configuration object for real-time event listeners that receive data via incoming HTTP requests.
         - |-
@@ -39670,6 +39696,33 @@ components:
             - 'The listener must be an export with `type: "webhook"` and `webhook.provider: "integrator-extension"`; any other export id is rejected with `invalid_post_parse_listener`. On an HTTP export outside file mode the save is rejected with `post_parse_listener_not_supported`: "Listener for functional acknowledgment is only supported for AS2, FTP, S3 and HTTP file export."'
           examples:
             - 60a2c4e6f321d800129a1a3c
+        _networkPolicyId:
+          type:
+            - string
+            - 'null'
+          format: objectId
+          x-celigo-refModel: networkpolicies
+          description: |-
+            Network policy whose IP allow and deny lists gate the requests that deliver data to this
+            listener. Only `type` `webhook` or `distributed` exports accept it; any other type fails
+            with 422 `not_allowed`. An id that is not one of the environment's network policies,
+            including one in the recycle bin, fails with 400 `network_policy_not_found`. Preserved
+            when omitted on PUT; send `null`, or `remove` it with `PATCH /v1/exports/{_id}` (which
+            also accepts `add` and `replace` with an id), to clear it. Deleting the policy with
+            `?force=true` clears it too. Absent from responses when no policy is assigned.
+
+            Where network-policy enforcement is enabled for the account, a webhook delivery to the
+            listener's `/data` route from an address the policy does not admit is refused with 403
+            `access_denied` — with a valid verification token or an invalid one alike, never 401 —
+            before the listener's verification runs and before the payload is read, so nothing is
+            queued and no flow run starts; an authenticated `GET` or `HEAD` of that route from such an
+            address is refused the same way. Enforcement on listeners is enabled per account. The
+            assignment is recorded in the export's audit as a `_networkPolicyId` field change carrying
+            the policy id.
+          x-celigo-ai-guidance:
+            - 'Assign by sending the whole export document with `_networkPolicyId` set (the form''s own save does the same) and clear it with an explicit `null` — a PUT that omits the field keeps the current policy, so a removed key is a silent no-op, not an unassignment. Resolve the policy id from `GET /v1/networkpolicies` in the same environment first: an unknown or recycled id is refused only at save time with 400 `network_policy_not_found`.'
+          examples:
+            - 6ab1ebbfb9e4547494ff7558
         externalId:
           type:
             - string

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@celigo/api-specs",
-  "version": "0.2.232",
+  "version": "0.2.234",
   "private": false,
   "description": "Public OpenAPI bundles (dist/) and the celigo-cli lint schema pack (schemas.json).",
   "keywords": [

package/schemas.json

@@ -1,7 +1,7 @@
 {
 	"provenance": {
 		"repo": "celigo/integrator-api-specs",
-		"iasCommit": "fb204127",
+		"iasCommit": "afd36585",
 		"generatedAt": "2026-11-04"
 	},
 	"roots": {
@@ -5793,6 +5793,7 @@
 				"_ediProfileId": 0,
 				"_id": 0,
 				"_integrationId": 88,
+				"_networkPolicyId": 88,
 				"_postParseListenerId": 0,
 				"_sourceId": 0,
 				"_templateId": 0,