@celigo/api-specs 0.2.143 → 0.2.145

package/dist/enduser.yml

@@ -195,7 +195,9 @@ paths:
         '409':
           description: |-
             An end-user record already exists for this user in the account.
-            Error code: `enduser_ashare_exists`.
+            Error code: `enduser_ashare_exists`. A revoked record doesn't count:
+            inviting that address again creates a new record, with none of the
+            old record's groups or grants.
           content:
             application/json:
               schema:
@@ -784,9 +786,12 @@ paths:
       tags:
         - Groups
       description: |-
-        Replaces the group's writable fields. Prefer resending the complete
-        object — omitted fields are not preserved. Requires account owner or
-        administrator access.
+        Replaces the group's writable fields; omitted fields are not preserved.
+        A body with only `name` comes back with no `description`,
+        `resourceGrants: []` and `_roleIds: []`, so the group grants its
+        members nothing while their memberships stay. Read the group first and
+        send its `description`, `_roleIds` and `resourceGrants` back with the
+        change. Requires account owner or administrator access.
       parameters:
         - name: _id
           in: path
@@ -804,9 +809,19 @@ paths:
               $ref: '#/components/schemas/GroupRequest'
             examples:
               rename:
-                summary: Rename the group
+                summary: Rename the group, sending back everything else it holds
                 value:
                   name: Finance EMEA
+                  description: Finance department end users
+                  intendedFor:
+                    - end-user
+                  _roleIds:
+                    - 68c1d2e3f4a5b6c7d8e9f0a1
+                  resourceGrants:
+                    - resourceType: mcpServer
+                      _resourceId: 6a1b2c3d4e5f6a7b8c9d0e1f
+                      capabilities:
+                        - tool:all
       responses:
         '200':
           description: Updated group.
@@ -1133,10 +1148,15 @@ paths:
               $ref: '#/components/schemas/RoleRequest'
             examples:
               updateDescription:
-                summary: Update the description
+                summary: Update the description, sending back the grants it holds
                 value:
                   name: Finance tools
                   description: Updated description
+                  resourceGrants:
+                    - resourceType: mcpServer
+                      _resourceId: 6a1b2c3d4e5f6a7b8c9d0e1f
+                      capabilities:
+                        - pset:6c3d4e5f6a7b8c9d0e1f2a3b
       responses:
         '200':
           description: Updated role.
@@ -1622,7 +1642,7 @@ components:
                   - invite_failed
                 x-enumDescriptions:
                   email_invalid: The email address is not valid
-                  enduser_ashare_exists: An end-user record already exists for this user in the account
+                  enduser_ashare_exists: An end-user record already exists for this user in the account (a revoked record doesn't count)
                   owner_self_invite_not_allowed: The address is the account owner's — owners already have MCP access without an end-user record
                   validation_failed: The shared groupIds or grants failed validation for this item
                   invite_failed: An unexpected per-item error, caught so the batch can continue
@@ -7574,7 +7594,10 @@ components:
       properties:
         updated:
           type: integer
-          description: Number of end-user records updated. Members already in (or absent from) the group are not counted.
+          description: |-
+            Number of listed end users processed, including any already in the
+            group (on add) or already outside it (on remove), whose memberships
+            are left as they were.
     Role:
       type: object
       description: |-

package/dist/export.yml

@@ -15728,6 +15728,11 @@ components:
         `transform` and output `filter` still run on top of them, so downstream steps — and a
         lookup's results mapping — see the transformed, filtered records, not the shape stored here.
 
+        In a flow test run of an HTTP export with a saved mock (live probe, 2026-10-21), the export
+        still listed `request` and `response` stages: `request` held the request the export composes,
+        and `response` held the mock under the source's URL, as did the test run's request log, which
+        recorded it as a 200. Read those stages as the substituted mock, not as a live call.
+
         `POST /v1/exports/preview` reads the `mockOutput` in its request body, not the saved one. For
         an export the preview supports (an HTTP export, for example), a body that carries it (as an
         export read back with GET does) returns that snapshot as a lone `parse` stage without calling

package/dist/flow.yml

@@ -2859,16 +2859,20 @@ paths:
       summary: Search jobs within a flow by trace key
       description: |-
         Searches for flow-run jobs that contain records matching a trace key prefix. Returns up to 1000
-        matching job objects — there is no pagination beyond that limit.
+        matching job objects — there is no pagination beyond that limit. A run matches when it carried
+        a matching record at all, whether the record succeeded, failed or was ignored there (live probe,
+        2026-10-21). Very short prefixes can match nothing — in that probe a two-character prefix of a
+        nine-character key found no run while three characters did — so send the record's whole trace
+        key.
 
-        The `traceKeyPrefix` query parameter is required; the server returns `400` when it is missing.
+        The `traceKeyPrefix` query parameter is required; the server returns `400` ("traceKeyPrefix is
+        required.") when it is missing.
 
-        Known behavior: the `status` filter is accepted but silently ignored — the response always includes
-        jobs of all statuses regardless of the filter value.
+        `status` filters the runs: in the same probe `status=failed` left out a `completed` run that
+        `status=completed` returned, and a value that is not a job status was ignored.
 
         Narrow the window with `createdAt_gte` / `createdAt_lte` when there are many runs for the
-        flow. Because `status` is silently ignored, filter client-side if you need only completed or
-        errored jobs.
+        flow.
       parameters:
         - name: _id
           in: path
@@ -2881,15 +2885,19 @@ paths:
         - name: traceKeyPrefix
           in: query
           required: true
-          description: Trace key prefix to search for. The server matches job records whose `traceKey` begins with this value.
+          description: |-
+            Trace key prefix to search for. The server matches job records whose `traceKey` begins with
+            this value, but very short prefixes can match nothing: in a live probe (2026-10-21) a
+            two-character prefix of a nine-character key found no run while three characters did. Send
+            the record's whole trace key.
           schema:
             type: string
         - name: status
           in: query
           required: false
           description: |-
-            Job status filter. **Note:** this parameter is currently accepted but silently ignored — all
-            statuses are always returned.
+            Job status filter: only runs with this status are returned. A value that is not a job
+            status is ignored (live probe, 2026-10-21).
           schema:
             type: string
         - name: createdAt_gte
@@ -2951,7 +2959,7 @@ paths:
                   value:
                     errors:
                       - code: invalid_request
-                        message: traceKeyPrefix query parameter is required.
+                        message: traceKeyPrefix is required.
         '401':
           $ref: '#/components/responses/401-unauthorized'
         '404':
@@ -3007,7 +3015,7 @@ paths:
             x-enumDescriptions:
               success: The record was processed successfully at this step.
               error: The record encountered an error during processing.
-              ignore: The record was skipped by a filter or routing rule.
+              ignore: The record was skipped at this step, by a filter, a router branch, or an import's ignore-existing or ignore-missing rule.
         - name: _expOrImpId
           in: query
           required: false
@@ -7842,11 +7850,11 @@ components:
           enum:
             - success
             - error
-            - ignored
+            - ignore
           x-enumDescriptions:
             success: The record was processed successfully at this step.
             error: The record encountered an error during processing.
-            ignored: The record was skipped by a filter or routing rule.
+            ignore: The record was skipped at this step, by a filter, a router branch, or an import's ignore-existing or ignore-missing rule.
         timeTaken:
           type: integer
           description: Milliseconds spent processing this record at this step.
@@ -8114,7 +8122,7 @@ components:
           x-enumDescriptions:
             success: The record was processed successfully at this step.
             error: The record encountered an error during processing.
-            ignore: The record was skipped by a filter or routing rule.
+            ignore: The record was skipped at this step, by a filter, a router branch, or an import's ignore-existing or ignore-missing rule.
         timeTaken:
           type: integer
           description: Milliseconds spent processing this record at this step.

package/dist/job.yml

@@ -71,10 +71,13 @@ paths:
         forward, take the `createdAt` of the last record, subtract 1 ms, and
         pass it as `createdAt_lte`.
 
-        Active jobs (`queued` or `running`) are pinned to the top of the first
-        page even when they fall outside the date filters; `canceling` jobs are
-        not pinned. Account for this when paging — the first page can contain
-        records older filters would otherwise exclude.
+        In a live probe (2026-10-21) the date filters applied to a `running`
+        flow job too: created outside `createdAt_gte` / `createdAt_lte`, it was
+        left out of every date-filtered list, whether the query was scoped by
+        flow and integration, by integration, or not at all. `queued` and
+        `canceling` jobs were not tested; if `queued` jobs are pinned to the
+        first page, that page can hold rows the date filters would otherwise
+        exclude, so tolerate out-of-range rows when paging.
       parameters:
         - name: _integrationId
           in: query

package/dist/mcp-server.yml

@@ -122,7 +122,6 @@ paths:
                         - _id: 6a7b8c9d0e1f2a3b4c5d6e7f
                           name: Finance read-only
                           description: Read-only invoice lookups for the finance team
-                          accessLevel: read
                           _toolIds:
                             - 69d462d5b9c28ea0b7f82522
                           _apiIds: []
@@ -293,7 +292,6 @@ paths:
                       - _id: 6a7b8c9d0e1f2a3b4c5d6e7f
                         name: Finance read-only
                         description: Read-only invoice lookups for the finance team
-                        accessLevel: read
                         _toolIds:
                           - 69d462d5b9c28ea0b7f82522
                         _apiIds: []
@@ -406,7 +404,6 @@ paths:
                     - _id: 6a7b8c9d0e1f2a3b4c5d6e7f
                       name: Finance read-only
                       description: Read-only invoice lookups for the finance team
-                      accessLevel: read
                       _toolIds:
                         - 69d462d5b9c28ea0b7f82522
                       _apiIds: []
@@ -476,7 +473,6 @@ paths:
                       - _id: 6a7b8c9d0e1f2a3b4c5d6e7f
                         name: Finance read-only
                         description: Read-only invoice lookups for the finance team
-                        accessLevel: read
                         _toolIds:
                           - 69d462d5b9c28ea0b7f82522
                         _apiIds: []
@@ -2392,16 +2388,19 @@ components:
         inside the MCP server document, and each set's `_id` is the stable handle
         that grants reference.
 
-        Deleting a set — or resubmitting it without its `_id` — rewrites every
-        grant that references it: the `pset:` capability is replaced with the
-        set's constituent `tool:`, `api:`, `prompt:`, and `resource:`
-        capabilities at removal time.
+        Removing a set — leaving it out of a PUT, or sending it back renamed and
+        without its `_id` — rewrites every end-user, group, and role grant that
+        references it: the `pset:` capability is replaced with the set's
+        constituent `tool:`, `api:`, `prompt:`, and `resource:` capabilities at
+        removal time. The grantees keep that access, but it no longer follows
+        the set: a set created later, even under the same name, reaches none of
+        them until they are granted it.
       x-celigo-ai-guidance:
         - |-
           When updating a server via PUT, send the complete `permissionSets` array
           and round-trip every existing set with its `_id` intact — an omitted set
           is removed and the grants that referenced it are flattened to its
-          individual tool/API capabilities.
+          individual `tool:`, `api:`, `prompt:` and `resource:` capabilities.
       properties:
         _id:
           type: string
@@ -2409,8 +2408,10 @@ components:
           description: |-
             Server-generated identifier for the set — the grant handle referenced
             as `pset:<_id>` in resource grants. Send it back unchanged on PUT to
-            preserve the set's identity; a set submitted without its `_id` is
-            treated as a brand-new set and assigned a fresh one.
+            preserve the set's identity. A set sent without its `_id` keeps the
+            `_id`, and the grants, of the stored set whose `name` matches it
+            (case-insensitively); only a set whose name matches no stored set is
+            new and gets a fresh `_id`.
           examples:
             - 6a7b8c9d0e1f2a3b4c5d6e7f
         name:
@@ -2436,7 +2437,10 @@ components:
           x-enumDescriptions:
             read: Read-level access, aligned with the `mcp:read` OAuth scope
             write: Write-level access, aligned with the `mcp:write` OAuth scope
-          description: OAuth-aligned access level the set pins for everyone it is granted to.
+          description: |-
+            OAuth-aligned access level for the set. The API doesn't store it: a
+            set's reads never include `accessLevel`, so don't rely on it to limit
+            what the set grants.
           examples:
             - read
         _toolIds:
@@ -2492,7 +2496,6 @@ components:
             - - 6aa970882c7f7fbf96a81c5e
       required:
         - name
-        - accessLevel
     UpstreamItemOverrides:
       type: object
       description: |-

package/dist/networkpolicy.yml

@@ -500,9 +500,10 @@ paths:
       description: |-
         Returns the change history for a network policy, newest first. Each entry
         records one event with who made the change, when, and which fields were
-        affected. Entries survive the policy's deletion and purge; the route itself
-        returns 404 once the policy has been purged, so use `GET /v1/audit?resourceType=networkpolicy`
-        to read the history of a purged policy.
+        affected. Entries survive the policy's deletion and purge, but the route
+        itself returns 404 as soon as the policy is deleted, so use
+        `GET /v1/audit?resourceType=networkpolicy` to read the history of a
+        deleted policy.
       tags:
         - Network Policies
       operationId: getNetworkPolicyAudit
@@ -828,7 +829,10 @@ components:
         name:
           type: string
           maxLength: 150
-          description: Display name shown wherever a policy is picked or listed. Unique among the environment's policies that are not in the recycle bin.
+          description: |-
+            Display name shown wherever a policy is picked or listed. Unique among the
+            environment's policies that are not in the recycle bin; on create, a name that
+            differs only in case from a live policy's is accepted.
           examples:
             - Corporate VPN egress
         description:
@@ -929,15 +933,19 @@ components:
           entries fails with 400 `max_cidr_entries_exceeded`. Duplicate entries are stored as sent.
         - |-
           `name` must be unique among the environment's live policies: a duplicate fails with 409
-          `conflict` on create, replace, and patch. A name held only by a policy in the recycle bin
-          can be reused.
+          `conflict` on create, replace, and patch. On create the comparison is case-sensitive: a name
+          that differs from a live policy's only in case is accepted as a separate policy. A name held
+          only by a policy in the recycle bin can be reused.
       required:
         - name
       properties:
         name:
           type: string
           maxLength: 150
-          description: Display name shown wherever a policy is picked or listed. Unique among the environment's policies that are not in the recycle bin.
+          description: |-
+            Display name shown wherever a policy is picked or listed. Unique among the
+            environment's policies that are not in the recycle bin; on create, a name that
+            differs only in case from a live policy's is accepted.
           x-celigo-ai-guidance:
             - Name the policy after the network it describes ("Corporate VPN egress", "Partner SFTP host"), not after the token or MCP server it is assigned to — one policy can be assigned to many principals.
           examples:

package/dist/tool.yml

@@ -36798,6 +36798,11 @@ components:
         `transform` and output `filter` still run on top of them, so downstream steps — and a
         lookup's results mapping — see the transformed, filtered records, not the shape stored here.
 
+        In a flow test run of an HTTP export with a saved mock (live probe, 2026-10-21), the export
+        still listed `request` and `response` stages: `request` held the request the export composes,
+        and `response` held the mock under the source's URL, as did the test run's request log, which
+        recorded it as a 200. Read those stages as the substituted mock, not as a live call.
+
         `POST /v1/exports/preview` reads the `mockOutput` in its request body, not the saved one. For
         an export the preview supports (an HTTP export, for example), a body that carries it (as an
         export read back with GET does) returns that snapshot as a lone `parse` stage without calling

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@celigo/api-specs",
-  "version": "0.2.143",
+  "version": "0.2.145",
   "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": "eeb7fc20",
+		"iasCommit": "325c42fa",
 		"generatedAt": "2026-10-21"
 	},
 	"roots": {