@celigo/api-specs 0.2.183 → 0.2.185

package/dist/api.yml

@@ -2961,6 +2961,192 @@ components:
           - Expected parameters (path, query, headers)
           - Request body schema
           - Optional request transformation logic
+    ResponseMapping:
+      type: object
+      description: |
+        Merges fields from a step's response back onto the in-flight record so
+        downstream steps can read them. Applies to both lookup steps
+        (`type: "export"`) and import steps (`type: "import"`); without it, the
+        step's response is discarded after the call.
+
+        `fields` and `lists` are plain arrays — exactly the shape GET returns.
+
+        Extract paths do NOT read the raw application response — the platform
+        wraps every response in a canonical per-record envelope first, and
+        extracts evaluate against that envelope:
+
+        - **Lookup steps**: `{"statusCode": 200, "data": [<result records>],
+          "errors": []}` — `data` holds the records the lookup step returns,
+          AFTER the export's own `transform` and output `filter` have run, so
+          extracts must start from it and name transformed fields by their
+          transformed name: `data[0].name` copies a field of the first result,
+          `data` copies the whole result array. A bare result-record field name
+          (e.g. `name`) resolves to nothing and merges nothing, and so does the
+          raw response path a transform consumed. A lookup that groups its
+          results returns each group as an array inside `data`
+          (`"data": [[<row>, <row>]]`): `data[0][0].name` (or `data.0.0.name`)
+          reads the first row of the first group, and `data[0]` copies the group.
+        - **Import steps**: `{"id": "<destination record id>", "statusCode": 200,
+          "ignored": false, "errors": [], "_json": <raw destination response>,
+          ...<response body fields flattened at the root>}` — use `id` for the
+          destination-assigned id and `_json.<path>` (or the flattened
+          `<path>`) for fields inside the destination's response body. The full
+          envelope (including `id`) is present on real runs and in flow-builder
+          previews; flow TEST runs never execute imports, and their envelope is
+          built from the import's saved `mockResponse`, or from the placeholder
+          `{"id": "1234567890", "mockResponse": "replace me"}` (numbered
+          `1234567890-1`, `1234567890-2`, … when a page holds several records)
+          — an `extract: "id"` in a test run merges that mock id, never a
+          destination record id.
+
+        An `extract` may also be a Handlebars expression. It evaluates against
+        the same envelope as a plain path, so every path inside `{{ }}` starts
+        where the plain paths start — `{{data.0.name}}`,
+        `{{#compare data.0.count "==" 1}}yes{{else}}no{{/compare}}`,
+        `{{#if data.length}}found{{/if}}` on a lookup; `{{_json.order.id}}` or
+        `{{id}}` on an import. Index arrays with dots inside Handlebars
+        (`data.0.name` or `data.[0].name`; `data[0].name` renders nothing), and
+        expect a string result (`"1"`, `"false"`). There is no `record` object in
+        this context: `{{record.<anything>}}` renders nothing. Prefer a plain
+        path when the value is simply copied.
+      x-celigo-ai-guidance:
+        - |-
+          Handlebars is allowed in `extract` but only rooted at the envelope —
+          `{{data.0.x}}` on a lookup, `{{_json.x}}` / `{{id}}` on an import. The
+          `record.` root belongs to import-mapping templates; here every
+          `{{record.…}}` form renders nothing, silently, and `{{data[0].x}}`
+          (bracket index inside Handlebars) renders nothing too. Use Handlebars
+          only for a derived value (a flag, a concatenation); copy values with a
+          plain path.
+        - |-
+          A lookup's `data[]` is the step's output after its `transform` and
+          `filter`, so author extracts against the transformed records — never
+          against the raw response the transform consumed, and never against a
+          saved `mockOutput` as stored (it is the raw response; the transform
+          runs on top of it in a test run).
+        - |-
+          Send `fields` and `lists` as bare arrays, exactly as GET returns them.
+          Never wrap either in an object (e.g. `"fields": {"type": [...]}`): the
+          API does not reject that shape — it returns 200 and silently persists
+          `fields: [null]` / `lists: [{"fields": []}]`, erasing the step's
+          response mappings.
+        - |-
+          responseMapping is fully replaced on PUT: omitting it resets the step
+          to empty `{"fields": [], "lists": []}`. Always send the complete
+          intended mapping for every step.
+        - |-
+          To carry several lookup results onto the record, use `extract: "data"`
+          (the whole result array) or a `lists` entry whose extracts use
+          `data[*].x` — never `data[*].x` in `fields[].extract`, which merges
+          nothing: the record simply never gains the field.
+      examples:
+        - fields:
+            - extract: id
+              generate: ContactId
+          lists: []
+        - fields:
+            - extract: data[0].customer.name
+              generate: customerName
+          lists:
+            - generate: matchedOrders
+              fields:
+                - extract: data[*].id
+                  generate: orderId
+                - extract: data[*].total
+                  generate: amount
+      properties:
+        fields:
+          type: array
+          description: |
+            Field mappings that copy individual values from the response
+            envelope onto the in-flight record.
+          items:
+            type: object
+            properties:
+              extract:
+                type: string
+                x-celigo-agent:
+                  - handlebars
+                description: |
+                  Path within the canonical response envelope to copy the value
+                  from, or a Handlebars expression over that same envelope. For
+                  lookup steps, paths start from the envelope's `data` array
+                  (`data[0].x` and `data.0.x` are equivalent; `data` alone
+                  copies every result) — a lookup result field written without
+                  the `data` prefix resolves to nothing. For import steps, use
+                  the envelope fields `id`, `statusCode`, `ignored`, `_json.<path>`
+                  for the raw response body, or the body field itself at the
+                  envelope root (`orderNumber` and `_json.orderNumber` read the
+                  same value). A `[*]` wildcard is not honored here — `data[*].x`
+                  merges nothing; iterate arrays with `lists` instead. Inside
+                  Handlebars, index with dots (`{{data.0.x}}`, never
+                  `{{data[0].x}}`) and never use a `record.` root.
+                examples:
+                  - data[0].customer.name
+                  - data.0.fields.Product Name
+                  - data
+                  - id
+                  - _json.orderNumber
+                  - '{{#if data.length}}found{{else}}missing{{/if}}'
+              generate:
+                type: string
+                description: |
+                  Field path on the in-flight record where the extracted value
+                  is stored, using dot notation for nesting. Downstream steps
+                  read the value at this path.
+                examples:
+                  - customerName
+                  - supplierDetails.supplierName
+                  - netsuite_order_id
+        lists:
+          type: array
+          description: |
+            Array mappings that build a target array on the in-flight record
+            from an array inside the response envelope — one output item per
+            element of the array the item extracts mark with `[*]` (`data[*].x`
+            for lookups, `_json.<arrayPath>[*].x` for imports); an empty source
+            array yields an empty target array. Not needed for one-to-many
+            (fan-out) merge-back, which uses plain field mappings.
+          items:
+            type: object
+            properties:
+              generate:
+                type: string
+                description: |
+                  Array field created on the in-flight record to hold the
+                  mapped items.
+                examples:
+                  - orderItems
+                  - addresses
+                  - contacts
+              fields:
+                type: array
+                description: |
+                  Field mappings applied to each item of the source array to
+                  produce the corresponding target-array item.
+                items:
+                  type: object
+                  properties:
+                    extract:
+                      type: string
+                      description: |
+                        Full envelope path to the source value, with `[*]`
+                        marking the array to iterate — `data[*].productId` for a
+                        lookup, `_json.items[*].sku` for an import. A path without
+                        `[*]` (e.g. `statusCode`) repeats the same envelope value
+                        on every item; an item-relative name (`productId`)
+                        resolves to nothing and produces empty objects.
+                      examples:
+                        - data[*].productId
+                        - data[*].quantity
+                        - _json.items[*].sku
+                    generate:
+                      type: string
+                      description: Target field within each mapped array item.
+                      examples:
+                        - itemId
+                        - qty
+                        - unitPrice
     Router:
       type: object
       description: |-
@@ -3138,6 +3324,8 @@ components:
                       description: Import resource reference (when type="import").
                       examples:
                         - 6878f4a43bc01652c09cddee
+                    responseMapping:
+                      $ref: '#/components/schemas/ResponseMapping'
                     hooks:
                       type: object
                       description: Custom scripts for processing
@@ -3283,6 +3471,54 @@ components:
               with `hardcodedValue` saves successfully with the value
               silently dropped — no error, and the target field is then
               simply absent from the API's responses.
+        status:
+          $ref: '#/components/schemas/status'
+    status:
+      type: string
+      description: |
+        **Purpose**
+        Controls whether the mapping is applied. Send it on every mapping entry.
+
+        **Guidance**
+        Only `Active` rows run. `Draft` and `Inactive` rows keep their
+        configuration, are saved with minimal validation, and are skipped at
+        runtime and in preview; a non-Active parent skips its whole subtree
+        whatever its children say. Imports (on save and in the mapper processor)
+        and API response mappings reject a row missing this field (validation
+        error: "Mapping object must have status field present."); a Tool's
+        output mapping saves and runs one, which is why `required` doesn't
+        list it.
+      x-celigo-ai-guidance:
+        - |-
+          Emit `"Active"` for mappings that should run; `"Draft"` is also
+          accepted and saves the mapping while bypassing the Active-only
+          field validations. The value is case-sensitive. The API rejects:
+          - Missing field: `[status_field_absent] Mapping object must have status field present.`
+          - Wrong case (e.g. `"active"`): `[invalid_status_enums] active is not a valid enum for status field.`
+        - |-
+          `"Inactive"` is the user's "Set inactive" on a row: use it only when
+          asked to disable or park a row, never to mean incomplete (that is
+          `"Draft"`). Setting a parent `Inactive` means no `Active` row may
+          remain under it — the save rejects an `Active` row under an
+          `Inactive` parent (`[inactive_parent_active_child]` on `mappings`,
+          no message text) and never cascades or promotes on its own; `Draft`
+          descendants are kept as they are, and a `Draft` parent does not gate
+          its children. The UI's Set inactive on a parent marks the parent and
+          every child `Inactive`. Re-enabling a child
+          means re-enabling its ancestors in the same payload. Edits that keep
+          existing rows must carry their stored status forward — rewriting a
+          `Draft` or `Inactive` row to `Active` turns a row the user parked
+          back on.
+      enum:
+        - Active
+        - Draft
+        - Inactive
+      x-enumDescriptions:
+        Active: The mapping is enabled and applied during processing
+        Draft: In-progress mapping; saved without the Active-only field validations and skipped at runtime
+        Inactive: Disabled by the user; configuration kept, skipped at runtime and in preview
+      examples:
+        - Active
     ApiResponse:
       type: object
       description: |-
@@ -3550,6 +3786,8 @@ components:
                     with `hardcodedValue` saves successfully with the value
                     silently dropped — no error, and the target field is then
                     simply absent from the API's responses.
+              status:
+                $ref: '#/components/schemas/status'
         lookups:
           type: array
           description: Static key-value lookup tables for value transformation.
@@ -6233,6 +6471,17 @@ components:
           minimum: 1
           maximum: 50
           default: 5
+        _tpConnectorId:
+          type: string
+          format: objectId
+          x-celigo-refModel: tradingpartnerconnectors
+          description: |-
+            Trading partner connector this S3 connection was provisioned from during partner
+            onboarding. Stored and returned here, under `s3`, like `ftp._tpConnectorId` and
+            `as2._tpConnectorId` on the other partner transports; a top-level `_tpConnectorId` on
+            the connection body is not stored. Omit for a standalone S3 connection.
+          examples:
+            - 66a1b2c3d4e5f60718293a4b
       if:
         properties:
           authType:
@@ -8334,8 +8583,35 @@ components:
                 sa-east-1: South America (Sao Paulo).
                 ca-central-1: Canada (Central).
               x-lowercase: true
+        useSSL:
+          type: boolean
+          writeOnly: true
+          description: |-
+            When true, the database connection is made over SSL/TLS and the certificate material in
+            `ssl` applies — the connection form's **Use SSL** switch (offered for MySQL, MariaDB and
+            PostgreSQL). Accepted on POST and PUT only: the platform stores it as `ssl.enabled`, which
+            is the field GET returns. A PUT that omits `useSSL` clears the stored `ssl.enabled` — send
+            it on every update that should keep SSL on.
+          examples:
+            - true
+          x-celigo-ai-guidance:
+            - |-
+              A body built from a GET carries `ssl.enabled` but never `useSSL`, so sending it back as a
+              PUT turns SSL off: add `"useSSL": true` to every update of a connection that uses SSL.
+              Setting `ssl.enabled` in the body changes nothing (verified live 2026-10-23 on a PostgreSQL
+              connection: a PUT of the GET body cleared `ssl`, a PUT with `useSSL: true` set it again,
+              and a PUT with `ssl.enabled: true` but no `useSSL` cleared it).
         ssl:
-          $ref: '#/components/schemas/SSL'
+          allOf:
+            - $ref: '#/components/schemas/SSL'
+            - type: object
+              properties:
+                enabled:
+                  type: boolean
+                  readOnly: true
+                  description: |-
+                    When true, SSL/TLS is on for this database connection. Set from `useSSL` on
+                    write and returned here on read; a value sent in this field is ignored.
         options:
           type: array
           description: |

package/dist/connection.yml

@@ -5090,6 +5090,17 @@ components:
           minimum: 1
           maximum: 50
           default: 5
+        _tpConnectorId:
+          type: string
+          format: objectId
+          x-celigo-refModel: tradingpartnerconnectors
+          description: |-
+            Trading partner connector this S3 connection was provisioned from during partner
+            onboarding. Stored and returned here, under `s3`, like `ftp._tpConnectorId` and
+            `as2._tpConnectorId` on the other partner transports; a top-level `_tpConnectorId` on
+            the connection body is not stored. Omit for a standalone S3 connection.
+          examples:
+            - 66a1b2c3d4e5f60718293a4b
       if:
         properties:
           authType:
@@ -7191,8 +7202,35 @@ components:
                 sa-east-1: South America (Sao Paulo).
                 ca-central-1: Canada (Central).
               x-lowercase: true
+        useSSL:
+          type: boolean
+          writeOnly: true
+          description: |-
+            When true, the database connection is made over SSL/TLS and the certificate material in
+            `ssl` applies — the connection form's **Use SSL** switch (offered for MySQL, MariaDB and
+            PostgreSQL). Accepted on POST and PUT only: the platform stores it as `ssl.enabled`, which
+            is the field GET returns. A PUT that omits `useSSL` clears the stored `ssl.enabled` — send
+            it on every update that should keep SSL on.
+          examples:
+            - true
+          x-celigo-ai-guidance:
+            - |-
+              A body built from a GET carries `ssl.enabled` but never `useSSL`, so sending it back as a
+              PUT turns SSL off: add `"useSSL": true` to every update of a connection that uses SSL.
+              Setting `ssl.enabled` in the body changes nothing (verified live 2026-10-23 on a PostgreSQL
+              connection: a PUT of the GET body cleared `ssl`, a PUT with `useSSL: true` set it again,
+              and a PUT with `ssl.enabled: true` but no `useSSL` cleared it).
         ssl:
-          $ref: '#/components/schemas/SSL'
+          allOf:
+            - $ref: '#/components/schemas/SSL'
+            - type: object
+              properties:
+                enabled:
+                  type: boolean
+                  readOnly: true
+                  description: |-
+                    When true, SSL/TLS is on for this database connection. Set from `useSSL` on
+                    write and returned here on read; a value sent in this field is ignored.
         options:
           type: array
           description: |

package/dist/enduser.yml

@@ -3141,6 +3141,17 @@ components:
           minimum: 1
           maximum: 50
           default: 5
+        _tpConnectorId:
+          type: string
+          format: objectId
+          x-celigo-refModel: tradingpartnerconnectors
+          description: |-
+            Trading partner connector this S3 connection was provisioned from during partner
+            onboarding. Stored and returned here, under `s3`, like `ftp._tpConnectorId` and
+            `as2._tpConnectorId` on the other partner transports; a top-level `_tpConnectorId` on
+            the connection body is not stored. Omit for a standalone S3 connection.
+          examples:
+            - 66a1b2c3d4e5f60718293a4b
       if:
         properties:
           authType:
@@ -5242,8 +5253,35 @@ components:
                 sa-east-1: South America (Sao Paulo).
                 ca-central-1: Canada (Central).
               x-lowercase: true
+        useSSL:
+          type: boolean
+          writeOnly: true
+          description: |-
+            When true, the database connection is made over SSL/TLS and the certificate material in
+            `ssl` applies — the connection form's **Use SSL** switch (offered for MySQL, MariaDB and
+            PostgreSQL). Accepted on POST and PUT only: the platform stores it as `ssl.enabled`, which
+            is the field GET returns. A PUT that omits `useSSL` clears the stored `ssl.enabled` — send
+            it on every update that should keep SSL on.
+          examples:
+            - true
+          x-celigo-ai-guidance:
+            - |-
+              A body built from a GET carries `ssl.enabled` but never `useSSL`, so sending it back as a
+              PUT turns SSL off: add `"useSSL": true` to every update of a connection that uses SSL.
+              Setting `ssl.enabled` in the body changes nothing (verified live 2026-10-23 on a PostgreSQL
+              connection: a PUT of the GET body cleared `ssl`, a PUT with `useSSL: true` set it again,
+              and a PUT with `ssl.enabled: true` but no `useSSL` cleared it).
         ssl:
-          $ref: '#/components/schemas/SSL'
+          allOf:
+            - $ref: '#/components/schemas/SSL'
+            - type: object
+              properties:
+                enabled:
+                  type: boolean
+                  readOnly: true
+                  description: |-
+                    When true, SSL/TLS is on for this database connection. Set from `useSSL` on
+                    write and returned here on read; a value sent in this field is ignored.
         options:
           type: array
           description: |

package/dist/export.yml

@@ -7988,6 +7988,12 @@ components:
         sendAuthForFileDownloads:
           type: boolean
           description: When true, includes authentication headers when downloading files.
+        isRest:
+          type: boolean
+          description: |-
+            Internal flag marking an export built with the legacy REST form and stored in the unified
+            HTTP framework. Set by the platform when it converts a legacy `rest` body; not configured
+            directly. Returned on every HTTP export, `false` unless the export was converted.
         _httpConnectorEndpointId:
           type: string
           format: objectId

package/dist/import.yml

@@ -4454,7 +4454,11 @@ components:
                           description: When true, the value is a NetSuite internal ID reference.
                         isKey:
                           type: boolean
-                          description: When true, this field is a key field for matching existing sublist lines.
+                          description: |-
+                            When true, this field is a key for matching the record's existing sublist lines: a
+                            mapped line updates the one existing line whose key fields hold the same values. `lists`
+                            says which records match lines, the keys used when no field sets `isKey`, and what a
+                            line that matches no line, or several, does.
                         immutable:
                           type: boolean
                           description: When true, this field is only set on record creation, not on updates.
@@ -4630,6 +4634,40 @@ components:
                     description: Field mappings for each column in the sublist.
               description: |
                 Sublist (line-item) mappings. Each entry maps source data to a NetSuite sublist.
+
+                Each mapped line updates the one existing line whose key fields hold the same values: its
+                `isKey` fields, or, with none, the sublist's default key. The existing lines are the stored
+                record's on an update, and on a transform (`Created From`: the body field
+                `celigo_nlobjTransformId` holds the source transaction's internal id) the lines the transform
+                fills in. Default keys:
+
+                - the item (`item`, else `itemkey` or `itemname`) on item fulfillments, item receipts,
+                  invoices, cash sales, cash refunds, return authorizations, bin worksheets, inbound shipment
+                  receipts and inventory counts, and on an assembly build's `component` sublist;
+                - the applied transaction (`refnum`) on the `apply`, `credit` and `deposit` sublists of
+                  customer and vendor payments, credit memos, vendor credits and customer refunds;
+                - `docnumber` on a deposit's `payment` sublist;
+                - `vendor` and `language` on an item record's `itemvendor` and `translations` sublists.
+
+                A sublist with neither, such as a sales order's or purchase order's `item`, matches nothing, so
+                an update adds every mapped line after the existing ones. Two matching lines fail the record
+                with `MULTIPLE_LINES_WITH_SAME_KEYS` ("Multiple lines found with keys item=<value> ..."). A
+                line that matches none is added as a new line, which an item fulfillment's `item` sublist
+                refuses with `SSS_INVALID_SUBLIST_OPERATION`: its lines are its order's.
+              x-celigo-ai-guidance:
+                - |-
+                  To make an update replace a sublist's lines, also map the body field
+                  `celigo_replaceAllLines_<sublist id>` (for example `celigo_replaceAllLines_item`) to `true`:
+                  the existing lines no mapped line matched are removed, then the mapped lines are written. Where
+                  lines can't be removed it clears them instead: `itemreceive` false on an item fulfillment or
+                  item receipt, `apply` false on an `apply` sublist. On a sublist with no `isKey` field and no
+                  default key every existing line is unmatched, so all are replaced; with a default key, the lines
+                  it matches stay.
+                - |-
+                  Key an update on a value each line holds once: a line id the record's create wrote to a line
+                  field, or, on a fulfillment, the order line's id mapped to `orderline`. Keying on the item fails
+                  with `MULTIPLE_LINES_WITH_SAME_KEYS` when an order holds the same item on two lines, and records
+                  that already hold repeated lines fail the same way once a key is set.
           x-celigo-agent:
             - mapping
         lookups:

package/dist/mcp-server.yml

@@ -4977,6 +4977,17 @@ components:
           minimum: 1
           maximum: 50
           default: 5
+        _tpConnectorId:
+          type: string
+          format: objectId
+          x-celigo-refModel: tradingpartnerconnectors
+          description: |-
+            Trading partner connector this S3 connection was provisioned from during partner
+            onboarding. Stored and returned here, under `s3`, like `ftp._tpConnectorId` and
+            `as2._tpConnectorId` on the other partner transports; a top-level `_tpConnectorId` on
+            the connection body is not stored. Omit for a standalone S3 connection.
+          examples:
+            - 66a1b2c3d4e5f60718293a4b
       if:
         properties:
           authType:
@@ -7078,8 +7089,35 @@ components:
                 sa-east-1: South America (Sao Paulo).
                 ca-central-1: Canada (Central).
               x-lowercase: true
+        useSSL:
+          type: boolean
+          writeOnly: true
+          description: |-
+            When true, the database connection is made over SSL/TLS and the certificate material in
+            `ssl` applies — the connection form's **Use SSL** switch (offered for MySQL, MariaDB and
+            PostgreSQL). Accepted on POST and PUT only: the platform stores it as `ssl.enabled`, which
+            is the field GET returns. A PUT that omits `useSSL` clears the stored `ssl.enabled` — send
+            it on every update that should keep SSL on.
+          examples:
+            - true
+          x-celigo-ai-guidance:
+            - |-
+              A body built from a GET carries `ssl.enabled` but never `useSSL`, so sending it back as a
+              PUT turns SSL off: add `"useSSL": true` to every update of a connection that uses SSL.
+              Setting `ssl.enabled` in the body changes nothing (verified live 2026-10-23 on a PostgreSQL
+              connection: a PUT of the GET body cleared `ssl`, a PUT with `useSSL: true` set it again,
+              and a PUT with `ssl.enabled: true` but no `useSSL` cleared it).
         ssl:
-          $ref: '#/components/schemas/SSL'
+          allOf:
+            - $ref: '#/components/schemas/SSL'
+            - type: object
+              properties:
+                enabled:
+                  type: boolean
+                  readOnly: true
+                  description: |-
+                    When true, SSL/TLS is on for this database connection. Set from `useSSL` on
+                    write and returned here on read; a value sent in this field is ignored.
         options:
           type: array
           description: |