@celigo/api-specs 0.2.128 → 0.2.129

package/dist/import.yml

@@ -849,12 +849,12 @@ paths:
                 value:
                   data:
                     - _id: 5d67ab3992080024596e0d8f
-                      email: nirav.pranami@celigo.com
+                      email: jane@example.com
                       verified: true
                       developer: true
-                      name: sai kaivalya
-                      role: Associate QA Engineer
-                      company: celigo
+                      name: Jane Doe
+                      role: Engineer
+                      company: acme
                       createdAt: '2019-08-29T10:38:50.396Z'
                       lastModified: '2024-09-25T14:17:50.802Z'
                   importConfig:
@@ -903,8 +903,8 @@ paths:
                               data:
                                 nlobjFieldIds:
                                   custrecord_user_id: 5d67ab3992080024596e0d8f
-                                  custrecord_user_email: nirav.pranami@celigo.com
-                                  custrecord_user_name: sai kaivalya
+                                  custrecord_user_email: jane@example.com
+                                  custrecord_user_name: Jane Doe
                                   custrecord_user_onboarded: 'true'
                                 nlobjSublistIds: {}
                           originalSize: 1
@@ -1998,30 +1998,19 @@ components:
               would be bare ``{{{jsonSerialize record}}}`` with nothing
               around it, you don't need a template at all.
 
-              Production frequency: roughly 1 in 3 active HTTPImports leaves
-              this field empty (~35% null / empty array); closer to 1 in 2
-              once you count the additional ~12% of body entries that are
-              blank strings.  The dominant case is "no body template".
-
               Leave undefined for:
               - REST APIs accepting JSON CRUD payloads (the destination
                 already wants exactly the post-mapped record shape).
-              - GraphQL destinations — do NOT author the body template here.
-                The dedicated GraphQL specialist owns the
-                ``{query, operationName, variables}`` shape and routes the
-                post-mapped record into ``variables`` automatically.  Roughly
-                96% of all wrapped-``jsonSerialize record`` uses in production
-                are GraphQL mutations; every one of those should go through
-                the GraphQL specialist, not through this body template.
               - Any case where the destination wants the mapped record as-is.
+
+              GraphQL destinations are different: the body is the stringified
+              ``{query, operationName, variables}`` envelope described under
+              ``formType``, with the post-mapped record passed in
+              ``variables``.
             - |-
-              ## SET THIS FIELD when one of the production patterns below applies
+              ## SET THIS FIELD when one of the patterns below applies
 
-              Production grounds these patterns: 36,445 active body entries
-              across HTTPImports in the last 30 days (Celigo-internal users
-              excluded).  Choose the pattern that fits the destination's
-              shape, then write marker ``instructions`` describing intent
-              (let the Handlebars specialist produce the literal template).
+              Choose the pattern that fits the destination's shape.
 
               ### Pattern A — ``{{{jsonSerialize record}}}`` inside a static wrapper
 
@@ -2033,13 +2022,12 @@ components:
               destination's field shape; the body owns the transport-level
               scaffolding.
 
-              Production frequency: roughly 115 / 36,445 (0.3%) of body
-              entries when the destination is non-GraphQL.  Rare but real;
-              the use cases that fit are obvious when the user describes
-              them ("wrap each request in a SQS-style message envelope",
-              "add a batch header with timestamp + interface name", etc.).
+              Rare for non-GraphQL destinations, but real; the use cases
+              that fit are obvious when the user describes them ("wrap each
+              request in a SQS-style message envelope", "add a batch header
+              with timestamp + interface name", etc.).
 
-              Real production shapes:
+              Typical shapes:
               - Message-bus envelope:
                 ``{"MessageBody": {"class": "EntityUpdate", "payload": {{{jsonSerialize record}}}}}``
               - Metadata wrap:
@@ -2050,8 +2038,7 @@ components:
               NEVER emit BARE ``{{{jsonSerialize record}}}`` with no wrapper.
               The platform sends the post-mapped record as JSON automatically
               when body is undefined; bare ``jsonSerialize record`` produces
-              identical wire output and shows up in 0.7% of production body
-              entries — every one of those is redundant config the user has
+              identical wire output, so it is redundant config the user has
               to maintain for zero benefit.
 
               ### Pattern B — Batch / page wrapper around mapped records
@@ -2098,15 +2085,14 @@ components:
               anti-pattern is the ``jsonSerialize`` wrap, not any particular
               path shape.
 
-              - Production frequency: 15 / 36,445 (0.04%) — essentially never.
+              - Essentially never needed.
               - Failure mode: the body validator sees the PRE-mapped sample
                 shape, can't resolve the post-mapped path during validation,
                 and ``jsonSerialize`` on an unresolved path raises
                 ``Helper {{jsonSerialize}} expects an argument`` — the
                 template fails validation even when it would render at
-                runtime.  The specialist enters a retry loop, tries variations
-                (``getValue`` wrappers, alternate paths), and converges on
-                failure.
+                runtime.  Variations (``getValue`` wrappers, alternate paths)
+                fail the same way.
 
               If you find yourself wanting to reference a per-field
               post-mapped scalar wrapped in ``jsonSerialize``, your situation
@@ -2169,16 +2155,6 @@ components:
                 before choosing: form-data APIs get the parts array above;
                 multipart/related APIs get the hand-authored document. Never
                 mix the two shapes in one body.
-            - |-
-              ## Marker instructions style
-
-              When emitting a ``$agent: handlebars`` marker at this field,
-              write the ``instructions`` as INTENT (what the body should
-              produce: destination fields, shape, encoding), not as literal
-              Handlebars syntax.  Embedding literal ``{{{jsonSerialize record.X}}}``
-              in the instructions risks the specialist following it verbatim
-              even when a simpler template would work — one of the ways the
-              per-field anti-pattern above gets introduced.
           examples:
             - - '{"name": "{{record.name}}", "email": "{{record.email}}"}'
             - - '{"requestData": {{{jsonSerialize record}}}}'
@@ -2270,9 +2246,7 @@ components:
             - |-
               The value MUST match the ``name`` of a lookup entry in ``http.lookups``.
               The lookup config itself (HTTP path, method, extract,
-              fallback chain) is authored separately — typically by the LookupsAgent
-              specialist via a ``$agent:
-              lookup`` marker.
+              fallback chain) is defined separately, in that entry.
             - |-
               ## Mutually exclusive with ``existingExtract``
 
@@ -2752,9 +2726,8 @@ components:
 
               The Celigo platform persists lookups in TWO locations on an HTTP
               import: top-level ``lookups`` and ``http.lookups``.  Both arrays
-              MUST hold byte-for-byte identical content.  The import engine
-              and the MappingsAgent both maintain this mirror on every save —
-              callers never have to write both manually.
+              MUST hold byte-for-byte identical content, so write both on
+              every save.
             - |-
               ## Static vs dynamic vs cached
 
@@ -3030,7 +3003,7 @@ components:
               computedObject.fileName." — an error the platform labels source `internal` although the
               template is the cause. The run-time-proven way to keep the source file's name on a
               `blob: true` import is `{{record.fileMeta.fileName}}` on `file.fileName` with this field
-              omitted (the production runs of one FTP blob import set exactly that); the same template
+              omitted (recorded runs of an FTP blob import set exactly that); the same template
               on this field has not been run. The field's editor preview (data version 1, its default)
               exposes the record as `data` —
               the `{blobKey, fileMeta}` record on a blob import, the page's record array otherwise —
@@ -3410,8 +3383,8 @@ components:
               ## Mirror invariant
               The Celigo platform persists lookups in TWO locations on a JDBC
               import: top-level `lookups` and `jdbc.lookups`. Both arrays
-              must hold byte-for-byte identical content — the MappingsAgent
-              writes both on every save.
+              must hold byte-for-byte identical content, so write both on every
+              save.
           x-celigo-agent:
             - lookup
     Mongodb:
@@ -3890,25 +3863,22 @@ components:
                   substitutions FIRST against the incoming source record (pre-mapped),
                   then the substituted expression is sent to NetSuite as a saved-search query.
                 - |-
-                  ## Handlebars conventions (production grounded)
+                  ## Handlebars conventions
 
                   - **No `record.` prefix** — substitutions reference top-level
                     source-record fields directly.  `{{{id}}}` / `{{{Id}}}` /
                     `{{{externalid}}}` / `{{{[Internal ID]}}}` — NOT
-                    `{{{record.id}}}`.  Production: only 122 / 55,328 expressions
-                    (0.2%) use the `record.` prefix; the dominant convention is
-                    top-level paths.
-                  - **Triple braces `{{{...}}}`** are the preferred form (78% of
-                    production); double-brace `{{...}}` also works for cases
-                    where you want the platform's default HTML-escape (rare in
-                    this field).
+                    `{{{record.id}}}`.  Top-level paths are the established
+                    convention.
+                  - **Triple braces `{{{...}}}`** are the preferred form;
+                    double-brace `{{...}}` also works for cases where you want
+                    the platform's default HTML-escape (rare in this field).
                   - **Bracket notation for field names with spaces or special
                     chars**: `{{{[Field With Spaces]}}}`, `{{{[Internal ID]}}}`.
-                    Anchored to ~10% of production expressions.
                 - |-
                   ## Canonical patterns
 
-                  ### Simple lookup by internal ID (most common — 8.4% of all expressions)
+                  ### Simple lookup by internal ID (most common)
 
                   `["internalid","is","{{{id}}}"]`
 
@@ -3979,8 +3949,8 @@ components:
                   `is` / `equalto` / `internalid anyof` value to `isempty` before the
                   search. On `restletVersion: suiteapp2.0` that search is not treated as
                   "no match": it can return existing records, and `addupdate` then
-                  updates one of them — an unrelated record receives the mapping (seen
-                  in production as `cant_modify_sub` on a customer the record never
+                  updates one of them — an unrelated record receives the mapping (for
+                  example, a `cant_modify_sub` error on a customer the record never
                   named). SuiteBundle and SuiteApp 1.0 discard a blank `internalid`
                   match and create. Design so the operational lookup never renders
                   empty: key it on a value every record carries (the source id stored
@@ -4067,10 +4037,6 @@ components:
             - |-
               Validated via the dedicated `PUT /v1/netsuiteDA/previewImportMappingFields`
               endpoint (NOT `/v1/processors/mapperProcessor`).
-            - |-
-              Managed by the MappingsAgent (`$agent: mapping`) — resource-authoring
-              agents must emit a specialist marker at this field rather than
-              generating the mapping inline.
           properties:
             fields:
               type: array
@@ -4147,8 +4113,8 @@ components:
                         this block ONLY when the destination record type genuinely requires the
                         subrecord.
                       - |-
-                        **Real-world `recordType` values** (ranked by
-                        production frequency across NetSuite DA imports):
+                        **Common `recordType` values** (most common
+                        first):
                         * `inventorydetail` — by far the most common.
                           Serial / lot / bin assignments on sales-order,
                           item-fulfillment, purchase-order, and inventory-
@@ -4218,8 +4184,8 @@ components:
                         type: string
                         description: |
                           Secondary reference-field identifier used on a
-                          small fraction of subrecord blocks in production
-                          (~3%).  Exact semantics are not publicly
+                          small fraction of subrecord blocks.  Exact
+                          semantics are not publicly
                           documented by Celigo — match the value on
                           existing resources when present; do NOT
                           synthesize one.  Leave unset unless a template
@@ -4418,9 +4384,8 @@ components:
                               this block ONLY when the destination record type genuinely requires the
                               subrecord.
                             - |-
-                              **Real-world `recordType` values** (ranked
-                              by production frequency across NetSuite DA
-                              imports):
+                              **Common `recordType` values** (most
+                              common first):
                               * `inventorydetail` — by far the most
                                 common.  Serial / lot / bin assignments on
                                 sales-order, item-fulfillment, purchase-
@@ -4488,9 +4453,9 @@ components:
                               type: string
                               description: |
                                 Secondary reference-field identifier used
-                                on a small fraction of subrecord blocks
-                                in production (~3%).  Exact semantics are
-                                not publicly documented by Celigo — match
+                                on a small fraction of subrecord blocks.
+                                Exact semantics are not publicly
+                                documented by Celigo — match
                                 the value on existing resources when
                                 present; do NOT synthesize one.  Leave
                                 unset unless a template clearly requires
@@ -4770,8 +4735,8 @@ components:
               ## Mirror invariant
               The Celigo platform persists NetSuite Distributed Import lookups in
               TWO locations: `netsuite_da.lookups` and top-level `lookups`.
-              Both arrays must hold byte-for-byte identical content — the
-              MappingsAgent writes both on every save.
+              Both arrays must hold byte-for-byte identical content, so write
+              both on every save.
             - |-
               ## One context for body and sublist lookups
               Every lookup's `expression` renders against the whole source
@@ -5169,8 +5134,8 @@ components:
             **Mirror invariant**
             The Celigo platform persists lookups in TWO locations on an RDBMS
             import: top-level `lookups` and `rdbms.lookups`. Both arrays
-            must hold byte-for-byte identical content — the MappingsAgent
-            writes both on every save.
+            must hold byte-for-byte identical content, so write both on every
+            save.
           items:
             type: object
             properties:
@@ -5295,7 +5260,7 @@ components:
               - **Nested fields**: `{{record.properties.email}}` (auto-quoted)
                 or `{{{record.properties.email}}}` (raw).
             - |-
-              ## EXAMPLES (production-grounded)
+              ## EXAMPLES
 
               - INSERT (string columns, auto-quoted): `["INSERT INTO customers (name, email) VALUES ({{record.name}}, {{record.email}})"]`
               - INSERT (mixed numeric + string): `["INSERT INTO orders (qty, sku) VALUES ({{{record.qty}}}, {{record.sku}})"]`
@@ -6156,8 +6121,7 @@ components:
           "wrapper" JavaScript module that invokes a custom function (typically to
           integrate with a system Celigo doesn't have a first-class connector for).
         - |-
-          Wrapper imports use Mapper 1.0 for field mappings and the generic Celigo lookup shape.
-          The MappingsAgent operates in `v1_standard` mode for this adaptor type —
+          Wrapper imports use Mapper 1.0 for field mappings and the generic Celigo lookup shape:
           mappings live in `resource.mapping` (fields/lists) and lookups mirror at
           `resource.lookups` and `resource.wrapper.lookups`.
       properties:
@@ -6205,8 +6169,8 @@ components:
               ## Mirror invariant
               The Celigo platform persists lookups in TWO locations on a
               Wrapper import: top-level `lookups` and `wrapper.lookups`.
-              Both arrays must hold byte-for-byte identical content — the
-              MappingsAgent writes both on every save.
+              Both arrays must hold byte-for-byte identical content, so write
+              both on every save.
       if:
         not:
           propertyNames:
@@ -6241,8 +6205,8 @@ components:
             **Mirror invariant**
             The Celigo platform stores lookups in TWO locations on a Salesforce
             import resource: top-level ``lookups`` and ``salesforce.lookups``.
-            Both arrays must hold byte-for-byte identical content — the
-            MappingsAgent writes both on every save.
+            Both arrays must hold byte-for-byte identical content, so write
+            both on every save.
 
             **Static vs dynamic lookups**
             - **Static** — only ``map`` + optional ``default``. No Salesforce
@@ -8408,10 +8372,8 @@ components:
               update this field — the wrapper itself stays the same shape,
               just points at a different Tool.
             - |-
-              The agent that authors the wrapper does not author the Tool itself;
-              Tool authoring goes through the Tools page agent's `create_tool` / `update_tool` tools (or,
-              when invoked from a flow / API / Tool dispatch path,
-              through the Tool Builder which delegates to the Tool engine's brief-based entry point).
+              Writing the wrapper does not create or change the Tool itself;
+              author the Tool as its own resource through `/v1/tools`.
           examples:
             - 69ce8ae7cbbb51405ae42ae5
         overrides:
@@ -13374,7 +13336,7 @@ components:
               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` (IO-166197). Re-enabling a child
+              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
@@ -14413,7 +14375,7 @@ components:
                 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` (IO-166197). Re-enabling a child
+                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
@@ -14852,7 +14814,7 @@ components:
                         ``{record: {...}, settings: ..., job: ...}`` (plus
                         ``fileMeta`` on file-provider steps) — the
                         same runtime-context envelope Handlebars / SQL /
-                        GraphQL specialists consume.  ``mappings[].extract``
+                        GraphQL templates render against.  ``mappings[].extract``
                         JSONPath values MUST include the ``record.`` segment
                         — for example ``"$.record.orderId"`` or
                         ``"$.record.customer.email"``.  PLACEHOLDER extracts
@@ -14880,9 +14842,8 @@ components:
                       ``inputContext: record`` makes the contract
                       self-documenting and prevents the transform from
                       drifting into envelope mode if an upstream change ever
-                      changes the platform default.  The TransformsAgent
-                      reads this value off the transform config and threads
-                      it into the generator's prompt so the JSONPath form
+                      changes the platform default.  Read this value before
+                      writing ``mappings[].extract`` so the JSONPath form
                       matches the runtime root.
                     - |-
                       ## fileMeta on file-provider steps
@@ -16150,7 +16111,7 @@ components:
               Optional on a `blob: true` file-provider import: when omitted the platform reads the
               record's root `blobKey` — the field a blob export emits on its `{blobKey, fileMeta}`
               record — so a file-transfer flow needs no `blobKeyPath`. Observed on an FTP import
-              (production runs writing files with no `blobKeyPath`) and on a Google Drive folder
+              (recorded runs writing files with no `blobKeyPath`) and on a Google Drive folder
               upload (`http.type: file`, the marketplace file-transfer template's shape); other
               file providers were not probed. Set it only when a response mapping placed the key
               elsewhere; on those two providers its absence is not a cause of upload failures.
@@ -16332,13 +16293,9 @@ components:
             - |-
               JavaScript hook references attached to lifecycle stages of the import.
               Engage hooks ONLY when the user explicitly wants scripting OR a requirement
-              cannot be expressed through declarative specialists (mapping / filter /
+              cannot be expressed through declarative configuration (mappings / filters /
               responseTransform).
               Hooks bypass the platform's declarative validation, so use them sparingly.
-            - |-
-              Phase A authoring scope: ``preMap`` and ``postMap`` only.
-              ``postSubmit`` and ``postAggregate`` are Phase B's territory (they author
-              against the real destination response).
           properties:
             preMap:
               type: object
@@ -16355,7 +16312,7 @@ components:
                   before the mapping sees them (drop archived records,
                   normalize date strings, split a record into many).  Don't
                   engage for static value substitution or simple field
-                  renames — that's the mapping specialist's job.
+                  renames — mappings handle those.
 
                   Runtime contract: ``options.data[]`` (the page of upstream
                   records) → array of the same length.
@@ -16397,11 +16354,6 @@ components:
                   Post-submit JavaScript hook — runs AFTER each batch of
                   destination writes, on the destination's response.
 
-                  **Phase B owns this slot.**  Phase A must NOT emit a
-                  ``$agent`` marker here (see "Phase A vs Phase B ownership"
-                  in the engine prompt).  Phase B authors this against the
-                  real probe response.
-
                   Runtime contract: ``options.responseData[]`` (one per
                   submitted record; ``{statusCode, errors, _json, ...}`` —
                   ``id`` is present on real runs but absent from the
@@ -16426,11 +16378,6 @@ components:
                   ``invalid_hook`` ("unsupported postAggregate hook") —
                   never emit it for non-file adaptors.
 
-                  **Phase B owns this slot.**  Phase A must NOT emit a
-                  ``$agent`` marker here (see "Phase A vs Phase B ownership"
-                  in the engine prompt).  Phase B authors this against the
-                  real probe response.
-
                   Runtime contract: ``options.postAggregateData``
                   (``{success, _json, code, message, source}``) → no return
                   value; side effects only (logging, notifying, downstream
@@ -16482,8 +16429,7 @@ components:
 
               REQUIRED for ``SalesforceImport`` and ``WrapperImport``: these
               adaptors must use Mapper 1.0; Mapper 2.0 is not supported for
-              them.  The agent's adaptor→mode classifier routes them here
-              automatically.  ``NetSuiteDistributedImport`` is also V1-required
+              them.  ``NetSuiteDistributedImport`` is also V1-required
               but uses a NetSuite-specific variant at its adaptor-scoped copy
               ``netsuite_da.mapping`` (richer sublist / subRecord vocabulary) —
               not this field.
@@ -16492,17 +16438,9 @@ components:
               ``FTPImport``, ``JDBCImport``, etc.) when the user explicitly asks
               for Mapper 1.0 — e.g. when the import wraps a legacy v1 connector
               or is being migrated from an older integration.  Those adaptors
-              default to Mapper 2.0 at the top-level ``mappings`` (plural) field;
-              see :mod:`celigo_agents.helpers.mappings.mapping_mode` for the
-              adaptor → default-mode classifier.  Do not emit a marker here
-              unsolicited; the v2 default produces better output for modern
-              connectors.
-            - |-
-              ## Specialist marker
-
-              Managed by the MappingsAgent (``$agent: mapping``) — resource-
-              authoring agents must emit a specialist marker at this field
-              rather than generating mapping content inline.
+              default to Mapper 2.0 at the top-level ``mappings`` (plural) field.
+              Do not set this field unsolicited; the v2 default produces better
+              output for modern connectors.
             - |-
               Allowed (but not the default) on other import adaptors such as
               ``HTTPImport``, ``RDBMSImport``, ``FTPImport``, and
@@ -16519,8 +16457,8 @@ components:
 
               Lookups referenced by ``lookupName`` live on the top-level
               ``resource.lookups`` array (mirrored under the adaptor key for
-              adaptors that maintain their own copy — see the mirror pattern in
-              the MappingsAgent architecture). Lookups are independent of this
+              adaptors that maintain their own copy — see the mirror invariant
+              on ``lookups``). Lookups are independent of this
               mapping: they are neither created nor cleared automatically when
               this mapping changes.
           properties:
@@ -16635,9 +16573,8 @@ components:
             - |-
               ## Mirror invariant
 
-              Both arrays MUST hold byte-for-byte identical content. The
-              MappingsAgent writes both on every save and treats them as a
-              single logical field.
+              Both arrays MUST hold byte-for-byte identical content: write
+              both on every save and treat them as a single logical field.
             - |-
               ## Shape
 
@@ -16698,7 +16635,7 @@ components:
               - ``envelope``: the mapper sees a wrapped object of the shape
                 ``{record: {...}, settings: ..., job: ...}`` — the same
                 runtime-context envelope Handlebars / SQL / GraphQL
-                specialists consume. ``mappings[].extract`` JSONPath values
+                templates render against. ``mappings[].extract`` JSONPath values
                 MUST include the ``record.`` segment — for example
                 ``"$.record.orderId"`` or ``"$.record.customer.email"``.
                 PLACEHOLDER extracts use ``"$.record.PLACEHOLDER_<field>"``.
@@ -16723,9 +16660,9 @@ components:
               platform, but emitting ``inputContext: record`` makes the
               contract self-documenting and prevents the mapper from drifting
               into envelope mode if an upstream change ever changes the
-              platform default. The MappingsAgent reads this value off the
-              resource and threads it into the mapping generator's prompt so
-              the JSONPath form matches the runtime root.
+              platform default. Read this value before writing
+              ``mappings[].extract`` so the JSONPath form matches the runtime
+              root.
         settingsForm:
           x-celigo-agent:
             - settings_form

package/dist/job.yml

@@ -424,8 +424,8 @@ paths:
         - |-
           Returns a paged collection of currently running jobs for the dashboard.
           The request body supports filtering by integration, flow, status, and
-          application.  The platform requires ``sandbox`` in the body; Ora is
-          production-only so it always sends ``false``.
+          application.  ``sandbox`` is deprecated; when a caller still sends it,
+          ``false`` selects production.
         - |-
           Do not send time_gt or time_lte; they are not on this request. To find jobs
           stuck for longer than a threshold, compare each job's createdAt or startedAt

package/dist/notification.yml

@@ -76,8 +76,8 @@ paths:
                       _connectionId: 5e5eb06fdd83ed4f8206a4ea
                       lastModified: '2021-08-31T17:36:09.092Z'
                       subscribedByUser:
-                        name: James Roth
-                        email: james.roth@celigo.com
+                        name: John Doe
+                        email: john@example.com
                     - _id: 698abc1234567890abcdef01
                       type: flow
                       _flowId: 69497fc443fc1f9a03d31bd9
@@ -90,8 +90,8 @@ paths:
                       _syncId: 69e7549b0f8b6cd703e5d3b2
                       lastModified: '2026-04-21T10:43:22.077Z'
                       subscribedByUser:
-                        name: Bhavik Shah
-                        email: bhavik.shah@celigo.com
+                        name: Alex Doe
+                        email: alex@example.com
         '204':
           description: |-
             Caller has no subscriptions in the current scope (default scope when
@@ -348,13 +348,13 @@ components:
                   type: string
                   description: Display name of the subscribed user.
                   examples:
-                    - James Roth
+                    - Jane Doe
                 email:
                   type: string
                   format: email
                   description: Email address the notifications are routed to.
                   examples:
-                    - james.roth@celigo.com
+                    - jane@example.com
     Error:
       type: object
       description: Standard error response envelope returned by integrator.io APIs.

package/dist/script.yml

@@ -745,7 +745,7 @@ paths:
                           type: string
                           description: User display name.
                           examples:
-                            - Tyler Lamparter
+                            - Jane Doe
                     fieldChanges:
                       type: array
                       description: Fields that were modified.
@@ -782,7 +782,7 @@ paths:
                       byUser:
                         _id: 624cb0346309dc3a543733a2
                         email: user@example.com
-                        name: Tyler Lamparter
+                        name: Jane Doe
                       fieldChanges:
                         - fieldPath: debugUntil
                           oldValue: '2026-04-18T14:52:43.041Z'

package/dist/stack.yml

@@ -609,7 +609,7 @@ paths:
                           type: string
                           description: User display name.
                           examples:
-                            - Tyler Lamparter
+                            - Jane Doe
                     fieldChanges:
                       type: array
                       description: Fields that were modified.
@@ -649,7 +649,7 @@ paths:
                       byUser:
                         _id: 624cb0346309dc3a543733a2
                         email: user@example.com
-                        name: Tyler Lamparter
+                        name: Jane Doe
                       fieldChanges:
                         - fieldPath: name
                           oldValue: AWS test

package/dist/subscription.yml

@@ -568,8 +568,8 @@ components:
           NOT what is actually configured or in use on the account.
           For example, `sso:
           true` means the plan includes SSO capability — it does not mean SSO is configured.
-          To know what is actually configured, use the appropriate domain tools (e.g.,
-          `get_account_settings` for SSO/MFA status).
+          To know what is actually configured, read the account's own configuration
+          (e.g., its SSO and MFA settings), not the license.
         - |-
           Licenses may represent:
           - an account-level subscription (`type` is `integrator`, `platform`, or `endpoint`)
@@ -795,9 +795,9 @@ components:
         aiConversationsPrepaidBalance:
           type: number
           description: |-
-            Remaining prepaid credit balance for Ora (Celigo's AI assistant).
+            Remaining prepaid credit balance for Celigo's AI assistant.
             Customers purchase credits up front and usage costs are deducted
-            as they interact with Ora.
+            as they interact with the assistant.
           example: 47.96
         aiAgentsPrepaidBalance:
           type: number
@@ -805,7 +805,8 @@ components:
             Remaining prepaid credit balance for AI Agents — LLM/AI capabilities
             used within flows, APIs, and automations (e.g., AI-powered transforms,
             hooks). Customers purchase credits up front and usage costs are
-            deducted as AI agents run. This balance is separate from Ora credits.
+            deducted as AI agents run. This balance is separate from the AI
+            assistant's credits (`aiConversationsPrepaidBalance`).
           example: 19.62
         topics:
           type: object