@celigo/api-specs 0.2.1

package/dist/iclient.yml

@@ -0,0 +1,4452 @@
+openapi: 3.2.0
+info:
+  version: 1.0.0
+  title: iClients
+  description: API for managing Celigo iClients — shared OAuth 2.0 credential stores referenced by connections.
+servers:
+  - url: https://api.integrator.io
+    description: Production (US / default region)
+  - url: https://api.eu.integrator.io
+    description: Production (EU region)
+  - url: https://api.au.integrator.io
+    description: Production (AU region)
+  - url: https://api.ca.integrator.io
+    description: Production (CA region)
+security:
+  - bearerAuth: []
+tags:
+  - name: iClients
+    x-displayName: iClients
+    description: |-
+      iClients are shared OAuth 2.0 credential stores that hold client
+      IDs, secrets, and token-endpoint configuration for a specific
+      application or provider. Multiple connections can reference the
+      same iClient so credentials are managed in one place.
+
+      Each iClient targets one `provider` — the provider determines
+      which credential sub-object (`oauth2`, `netsuite`, `salesforce`,
+      `ebay`, `amazonmws`, `azureserviceprincipal`) is required.
+      Secrets are stored encrypted and returned masked as `"******"`.
+
+      ## iClient schema
+
+      {% openapi-schemas spec="iclient" schemas="iClient" grouped="true" %}
+paths:
+  /v1/iclients:
+    get:
+      x-internal: false
+      summary: List iClients
+      description: |-
+        Returns all iClients in the account. Does not paginate — all
+        iClients are returned in a single response.
+      x-celigo-ai-guidance:
+        - |-
+          Returns a list of all iClients configured in the account.
+          If no iClients exist in the account,
+          a 204 response with no body will be returned.
+        - |-
+          Returns a list of all iClients configured in the account.
+          If no iClients exist in the account,
+          a 204 response with no body will be returned.
+        - |-
+          Returns a list of all iClients configured in the account.
+          If no iClients exist in the account,
+          a 204 response with no body will be returned.
+      operationId: listIClients
+      tags:
+        - iClients
+      parameters:
+        - name: limit
+          in: query
+          description: Maximum number of records to return per page.
+          schema:
+            type: integer
+            minimum: 1
+            examples:
+              - 100
+        - $ref: '#/components/parameters/After'
+      responses:
+        '200':
+          description: List of iClients (may be empty).
+          x-celigo-ai-guidance:
+            - Successfully retrieved list of iClients
+          headers:
+            Link:
+              description: |-
+                RFC-5988 pagination links. When more pages remain, includes a `<...>; rel="next"` entry;
+                absent on the final page.
+              schema:
+                type: string
+          content:
+            application/json:
+              schema:
+                type: array
+                items:
+                  $ref: '#/components/schemas/iClient'
+              examples:
+                default:
+                  value:
+                    - _id: 664be9dc9f7cf79527e2c03e
+                      name: Google Drive
+                      published: false
+                      lastModified: '2024-05-21T00:25:00.735Z'
+                      provider: custom_oauth2
+                      _httpConnectorId: 669e1d90e3e73a17fb1fb1eb
+                      _httpConnectorApiId: 66a0a457ea5ed5b80f6efa74
+                      enableJWT: false
+                      enableIClientReferences: false
+                      formType: assistant
+                      oauth2:
+                        clientId: 1096775564568-cucr5sv44tgfec4kkqsufi5k975d8orv.apps.googleusercontent.com
+                        clientSecret: '******'
+                        scope: []
+                        scopeDelimiter: ' '
+                        validDomainNames:
+                          - google.com
+                        useNewAuthFailSchema: true
+                        auth:
+                          uri: https://accounts.google.com/o/oauth2/auth
+                        token:
+                          uri: https://accounts.google.com/o/oauth2/token
+                    - _id: 69e83183438f9e0edcc68c49
+                      name: Azure Service Principal
+                      published: false
+                      lastModified: '2026-05-02T18:09:32.572Z'
+                      provider: azureserviceprincipal
+                      enableJWT: false
+                      enableIClientReferences: false
+                      formType: http
+                      azureserviceprincipal:
+                        clientId: a1b2c3d4-e5f6-7890-abcd-ef1234567890
+                        clientSecret: '******'
+                        tenantId: f0e1d2c3-b4a5-6789-0abc-def012345678
+        '204':
+          description: No iClients exist in the account.
+        '401':
+          $ref: '#/components/responses/401-unauthorized'
+    post:
+      x-internal: false
+      summary: Create an iClient
+      description: |-
+        Creates a new iClient. The `provider` field is required and
+        determines which credential sub-object must be populated.
+      operationId: createIClient
+      tags:
+        - iClients
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              $ref: '#/components/schemas/Request'
+            examples:
+              custom_oauth2:
+                summary: Generic OAuth 2.0 provider
+                value:
+                  name: My OAuth App
+                  provider: custom_oauth2
+                  oauth2:
+                    clientId: my-client-id
+                    clientSecret: my-client-secret
+                    scope:
+                      - read write
+                    auth:
+                      uri: https://auth.example.com/authorize
+                    token:
+                      uri: https://auth.example.com/token
+              azureserviceprincipal:
+                summary: Azure AD service principal
+                value:
+                  name: Azure SP
+                  provider: azureserviceprincipal
+                  azureserviceprincipal:
+                    clientId: a1b2c3d4-e5f6-7890-abcd-ef1234567890
+                    clientSecret: my-client-secret
+                    tenantId: f0e1d2c3-b4a5-6789-0abc-def012345678
+      responses:
+        '201':
+          description: iClient created.
+          x-celigo-ai-guidance:
+            - iClient created successfully
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/iClient'
+              examples:
+                created:
+                  summary: Created OAuth 2.0 iClient (secret masked, server defaults applied)
+                  value:
+                    _id: 69e83183438f9e0edcc68c49
+                    name: Client Credentials App
+                    published: false
+                    lastModified: '2026-05-02T18:09:32.572Z'
+                    provider: custom_oauth2
+                    enableJWT: false
+                    enableIClientReferences: false
+                    formType: http
+                    oauth2:
+                      clientId: cid
+                      clientSecret: '******'
+                      scope: []
+                      validDomainNames:
+                        - example.com
+                      grantType: clientcredentials
+                      useNewAuthFailSchema: true
+        '400':
+          $ref: '#/components/responses/400-bad-request'
+        '401':
+          $ref: '#/components/responses/401-unauthorized'
+        '403':
+          $ref: '#/components/responses/403-forbidden'
+        '422':
+          $ref: '#/components/responses/422-unprocessable-entity'
+  /v1/iclients/{_id}:
+    get:
+      x-internal: false
+      summary: Get an iClient
+      description: Retrieves a single iClient by ID.
+      operationId: getIClientById
+      tags:
+        - iClients
+      parameters:
+        - in: path
+          name: _id
+          required: true
+          schema:
+            type: string
+            format: objectId
+          description: iClient ID.
+      responses:
+        '200':
+          description: iClient object.
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/iClient'
+              examples:
+                custom_oauth2:
+                  summary: OAuth 2.0 iClient backed by an HTTP connector
+                  value:
+                    _id: 664be9dc9f7cf79527e2c03e
+                    name: Google Drive
+                    published: false
+                    lastModified: '2024-05-21T00:25:00.735Z'
+                    provider: custom_oauth2
+                    _httpConnectorId: 669e1d90e3e73a17fb1fb1eb
+                    _httpConnectorApiId: 66a0a457ea5ed5b80f6efa74
+                    enableJWT: false
+                    enableIClientReferences: false
+                    formType: assistant
+                    oauth2:
+                      clientId: 1096775564568-cucr5sv44tgfec4kkqsufi5k975d8orv.apps.googleusercontent.com
+                      clientSecret: '******'
+                      scope: []
+                      scopeDelimiter: ' '
+                      validDomainNames:
+                        - google.com
+                      useNewAuthFailSchema: true
+                      auth:
+                        uri: https://accounts.google.com/o/oauth2/auth
+                      token:
+                        uri: https://accounts.google.com/o/oauth2/token
+        '401':
+          $ref: '#/components/responses/401-unauthorized'
+        '404':
+          $ref: '#/components/responses/404-not-found'
+    put:
+      x-internal: false
+      summary: Update an iClient
+      description: |-
+        Replaces an iClient. All mutable fields must be provided — omitted
+        fields are reset to defaults. Secrets returned as `"******"` can be
+        sent back as-is to keep the existing value.
+      operationId: updateIClient
+      tags:
+        - iClients
+      parameters:
+        - in: path
+          name: _id
+          required: true
+          schema:
+            type: string
+            format: objectId
+          description: iClient ID.
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              $ref: '#/components/schemas/Request'
+            examples:
+              update_name:
+                summary: Update name only (preserve secrets)
+                value:
+                  name: Renamed OAuth App
+                  provider: custom_oauth2
+                  oauth2:
+                    clientId: my-client-id
+                    clientSecret: '******'
+      responses:
+        '200':
+          description: Updated iClient.
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/iClient'
+              examples:
+                renamed:
+                  summary: Renamed iClient (existing secret preserved, omitted fields reset)
+                  value:
+                    _id: 69e83183438f9e0edcc68c49
+                    name: Renamed OAuth App
+                    published: false
+                    lastModified: '2026-05-02T18:14:05.118Z'
+                    provider: custom_oauth2
+                    enableJWT: false
+                    enableIClientReferences: false
+                    formType: http
+                    oauth2:
+                      clientId: my-client-id
+                      clientSecret: '******'
+                      scope: []
+                      useNewAuthFailSchema: true
+        '400':
+          $ref: '#/components/responses/400-bad-request'
+        '401':
+          $ref: '#/components/responses/401-unauthorized'
+        '404':
+          $ref: '#/components/responses/404-not-found'
+        '422':
+          $ref: '#/components/responses/422-unprocessable-entity'
+    patch:
+      x-internal: false
+      summary: Patch an iClient
+      description: |-
+        Partially updates an iClient using JSON Patch (RFC 6902). Only
+        `/oauth2/failPath` is patchable; use PUT for other field changes.
+      operationId: patchIClient
+      tags:
+        - iClients
+      parameters:
+        - in: path
+          name: _id
+          required: true
+          schema:
+            type: string
+            format: objectId
+          description: iClient ID.
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              type: array
+              items:
+                type: object
+                required:
+                  - op
+                  - path
+                properties:
+                  op:
+                    type: string
+                    enum:
+                      - replace
+                      - add
+                      - remove
+                    x-enumDescriptions:
+                      replace: Replace the current value at the path.
+                      add: Add a value at the path.
+                      remove: Remove the value at the path.
+                    description: JSON Patch operation.
+                  path:
+                    type: string
+                    enum:
+                      - /oauth2/failPath
+                    x-enumDescriptions:
+                      /oauth2/failPath: Response body path used to detect OAuth auth failures.
+                    description: |-
+                      JSON Pointer to modify. Only `/oauth2/failPath` is
+                      whitelisted.
+                  value:
+                    type: string
+                    description: |-
+                      New value. Required for `replace` and `add`;
+                      omit for `remove`.
+            examples:
+              replace_failPath:
+                summary: Replace the auth failure detection path
+                value:
+                  - op: replace
+                    path: /oauth2/failPath
+                    value: error.message
+      responses:
+        '204':
+          description: Patch applied (no response body).
+        '401':
+          $ref: '#/components/responses/401-unauthorized'
+        '404':
+          $ref: '#/components/responses/404-not-found'
+        '422':
+          description: Patch rejected.
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/Error'
+              examples:
+                invalid_patch_data:
+                  summary: Body is not a JSON array
+                  value:
+                    errors:
+                      - message: invalid patch data
+                non_whitelisted:
+                  summary: Path is not patchable
+                  value:
+                    errors:
+                      - message: /name is not a whitelisted property
+    delete:
+      x-internal: false
+      summary: Delete an iClient
+      description: |-
+        Permanently deletes an iClient. Blocked if the iClient is still
+        referenced by a connection.
+      operationId: deleteIClient
+      tags:
+        - iClients
+      parameters:
+        - in: path
+          name: _id
+          required: true
+          schema:
+            type: string
+            format: objectId
+          description: iClient ID.
+      responses:
+        '204':
+          description: iClient deleted (no response body).
+        '401':
+          $ref: '#/components/responses/401-unauthorized'
+        '404':
+          $ref: '#/components/responses/404-not-found'
+        '422':
+          $ref: '#/components/responses/422-unprocessable-entity'
+  /v1/iclients/{_id}/dependencies:
+    get:
+      x-internal: false
+      operationId: listIClientDependencies
+      tags:
+        - iClients
+      summary: List dependencies of an iClient
+      description: |-
+        Returns the set of resources that depend on the specified resource.
+        The response is an object whose keys are dependent-resource types
+        (e.g. `flows`, `imports`) and whose values are arrays of dependency
+        entries. Returns `{}` when no dependents exist, including for
+        well-formatted but nonexistent IDs.
+      parameters:
+        - name: _id
+          in: path
+          required: true
+          description: Resource ID.
+          schema:
+            type: string
+            format: objectId
+      responses:
+        '200':
+          description: |
+            Dependency map. Keys are resource-type strings; values are arrays
+            of dependency entries. Returns `{}` when no dependents exist.
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/DependencyResponse'
+              examples:
+                none:
+                  summary: No dependents (also returned for a nonexistent ID)
+                  value: {}
+        '401':
+          $ref: '#/components/responses/401-unauthorized'
+components:
+  securitySchemes:
+    bearerAuth:
+      type: http
+      scheme: bearer
+  parameters:
+    After:
+      name: after
+      in: query
+      required: false
+      description: |-
+        Opaque cursor for forward pagination. Pass the value from the `Link`
+        response header (`rel="next"`) to fetch the next page.
+      schema:
+        type: string
+  schemas:
+    IClientBase:
+      type: object
+      description: Writable iClient fields shared by the request and response schemas.
+      properties:
+        name:
+          type: string
+          description: Display name for the iClient.
+          x-celigo-ai-guidance:
+            - Name the iClient after the ONE application whose OAuth app / client credentials it holds, plus the account or environment when that distinguishes it (e.g. "Google Drive OAuth App", "Shopify OAuth - mystore").
+            - Never name an iClient after a flow or use case — iClients are account-level credentials referenced by many connections (`_iClientId`), and a use-case name hides which application the client belongs to.
+          examples:
+            - Google Drive OAuth App
+        provider:
+          type: string
+          description: Authentication provider that determines which credential fields apply.
+          x-celigo-ai-guidance:
+            - |-
+              ## IMPORTANT NOTES:
+              - This is not a human/vendor label — it is the provider key that selects an authentication method.
+            - |-
+              ## IMPLEMENTATION GUIDANCE:
+              - Pick the provider that matches the system you are authenticating against.
+              - For generic OAuth2 providers, use `custom_oauth2`.
+              - Ensure the corresponding auth configuration under `oauth2`, `jwt`, or provider-specific sections is populated as needed.
+            - |-
+              Specifies the authentication provider/method used by this iClient,
+              determining which authentication flow and credential fields are used (e.g.,
+              Google OAuth, Salesforce OAuth, NetSuite token-based auth,
+              or a custom OAuth2 provider).
+            - |-
+              ## FIELD BEHAVIOR:
+              - Required.
+              - Must be one of the supported provider enum values.
+              - Drives the UI and validation rules for which authentication settings are shown/required.
+            - |-
+              ## DEPENDENCY CHAIN:
+              - Influences which auth sub-configurations are applicable (for example, `oauth2.*`, `netsuite.*`, `salesforce.*`, `jwt.*`).
+            - |-
+              Specifies the authentication provider/method used by this iClient,
+              determining which authentication flow and credential fields are used (e.g.,
+              Google OAuth, Salesforce OAuth, NetSuite token-based auth,
+              or a custom OAuth2 provider).
+            - |-
+              Specifies the authentication provider/method used by this iClient,
+              determining which authentication flow and credential fields are used (e.g.,
+              Google OAuth, Salesforce OAuth, NetSuite token-based auth,
+              or a custom OAuth2 provider).
+          enum:
+            - custom_oauth2
+            - netsuite
+            - amazonmws
+            - awsIam
+            - azureserviceprincipal
+            - googleserviceaccount
+            - integrator
+            - salesforce
+            - shopify
+            - ebay-xml
+            - microsoftbusinesscentral
+            - google
+            - azureoauth
+            - squareup
+            - zendesk
+            - docusign
+            - ebay
+            - windowslive
+            - bigcommerce
+            - asana
+            - box
+            - dropbox
+            - clover
+            - servicenow
+            - jobvite
+            - twilio
+            - certify
+            - woocommerce
+          x-enumDescriptions:
+            custom_oauth2: Generic OAuth 2.0 provider for applications not listed.
+            netsuite: NetSuite token-based authentication.
+            amazonmws: Amazon Marketplace Web Service (MWS) authentication.
+            awsIam: AWS IAM cross-account role authentication (assume-role with an external ID).
+            azureserviceprincipal: Azure AD service principal (client credentials) authentication.
+            googleserviceaccount: Google Cloud service-account key authentication (JSON key file).
+            integrator: Celigo integrator.io internal authentication.
+            salesforce: Salesforce OAuth 2.0 authentication.
+            shopify: Shopify OAuth 2.0 authentication.
+            ebay-xml: eBay Trading (XML) API authentication.
+            microsoftbusinesscentral: Microsoft Dynamics 365 Business Central OAuth 2.0 authentication.
+            google: Google OAuth 2.0 authentication.
+            azureoauth: Microsoft Azure AD OAuth 2.0 authentication.
+            squareup: Square OAuth 2.0 authentication.
+            zendesk: Zendesk OAuth 2.0 authentication.
+            docusign: DocuSign OAuth 2.0 authentication.
+            ebay: eBay REST API OAuth 2.0 authentication.
+            windowslive: Microsoft Windows Live OAuth authentication.
+            bigcommerce: BigCommerce OAuth 2.0 authentication.
+            asana: Asana OAuth 2.0 authentication.
+            box: Box OAuth 2.0 authentication.
+            dropbox: Dropbox OAuth 2.0 authentication.
+            clover: Clover OAuth 2.0 authentication.
+            servicenow: ServiceNow OAuth 2.0 authentication.
+            jobvite: Jobvite API authentication.
+            twilio: Twilio API authentication.
+            certify: Certify API authentication.
+            woocommerce: WooCommerce REST API authentication.
+        published:
+          type: boolean
+          description: When true, this iClient is published and available for use.
+          x-celigo-ai-guidance:
+            - |-
+              ## IMPLEMENTATION GUIDANCE:
+              - Default to `false` unless you intend to publish the iClient.
+            - Indicates whether this iClient is published (available/visible for use).
+            - |-
+              ## EXAMPLES:
+              - `true`
+              - `false`
+            - |-
+              ## FIELD BEHAVIOR:
+              - Boolean flag: `true` or `false`.
+              - Used to control publication status in the UI.
+        enableJWT:
+          type: boolean
+          description: |-
+            Enables a JWT assertion as part of the OAuth token request.
+            When true, `{{{iClient.jwt.token}}}` resolves to the signed
+            JWT for use in the token URL request body. Requires the `jwt`
+            sub-object to be configured.
+          x-celigo-ai-guidance:
+            - |-
+              ## FIELD BEHAVIOR:
+              - When `true`, the iClient includes a JWT assertion/token as part of the OAuth token request.
+              - When `false`, the OAuth flow does not incorporate a JWT assertion component.
+            - |-
+              ## IMPLEMENTATION GUIDANCE:
+              - Enable only when your OAuth provider requires JWT assertion.
+              - Populate the `jwt` configuration (e.g., `iClient.jwt.*`) so `{{{iClient.jwt.token}}}` can be resolved.
+              - Use the resolved JWT token in the token request body parameters for the OAuth token URL, as required by the provider.
+            - |-
+              ## TECHNICAL DETAILS:
+              - The JWT token can be referenced via `{{{iClient.jwt.token}}}` during request templating.
+            - |-
+              ## IMPORTANT NOTES:
+              - This flag is for **OAuth JWT assertion** use-cases; it does not mean "all requests must include a JWT Authorization header."
+              - If enabled without configuring `iClient.jwt`, token generation will fail.
+            - |-
+              Enable this field when the OAuth provider requires an additional JWT assertion
+              as a component of the OAuth authentication flow;
+              when enabled,
+              use the Handlebars path `{{{iClient.jwt.token}}}` to obtain the JWT token value,
+              which is then used in the request body of the token URL to generate an access token.
+            - |-
+              ## EXAMPLES:
+              - `true` (OAuth token request includes a JWT assertion component)
+              - `false` (standard OAuth flow without JWT assertion)
+            - |-
+              ## DEPENDENCY CHAIN:
+              - Depends on `iClient.jwt` fields and the provider's OAuth token request requirements.
+              - Used when constructing the token URL request body for OAuth.
+            - |-
+              Enable this field when the OAuth provider requires an additional JWT assertion
+              as a component of the OAuth authentication flow;
+              when enabled,
+              use the Handlebars path `{{{iClient.jwt.token}}}` to obtain the JWT token value,
+              which is then used in the request body of the token URL to generate an access token.
+            - |-
+              Enable this field when the OAuth provider requires an additional JWT assertion
+              as a component of the OAuth authentication flow;
+              when enabled,
+              use the Handlebars path `{{{iClient.jwt.token}}}` to obtain the JWT token value,
+              which is then used in the request body of the token URL to generate an access token.
+        enableIClientReferences:
+          type: boolean
+          description: When true, other resources can reference this iClient's fields via Handlebars expressions.
+          x-celigo-ai-guidance:
+            - |-
+              ## IMPORTANT NOTES:
+              - Enabling iClient references may require additional permissions or configurations on the client or server side.
+              - Disabling this feature can improve security by limiting external references but may reduce functionality.
+              - Changes to this setting might require a system restart or reinitialization to take effect.
+            - |-
+              ## FIELD BEHAVIOR:
+              - When set to true, iClient references are enabled, allowing the system to recognize and process iClient-related interactions.
+              - When set to false, iClient references are disabled, and any related functionality will be ignored or unavailable.
+              - The field typically accepts a boolean value.
+            - |-
+              ## TECHNICAL DETAILS:
+              - Typically implemented as a boolean flag in the configuration.
+              - Controls conditional logic paths that handle iClient reference processing.
+              - May influence API endpoints, middleware behavior, or client-server communication protocols.
+            - |-
+              Determines whether the system should enable support for iClient references,
+              allowing integration and interaction with iClient components or services.
+              This setting controls the activation of features that facilitate communication,
+              data exchange, or functionality extension through iClient references.
+            - |-
+              ## IMPLEMENTATION GUIDANCE:
+              - Enable this setting only if your application requires integration with iClient components.
+              - Ensure that enabling this does not conflict with other system configurations or security policies.
+              - Validate the impact on performance and compatibility when toggling this setting.
+            - |-
+              ## EXAMPLES:
+              - true: Enables iClient references, allowing the system to interact with iClient services.
+              - false: Disables iClient references, preventing any iClient-related processing.
+            - |-
+              ## DEPENDENCY CHAIN:
+              - May depend on the presence of iClient libraries or modules within the system.
+              - Could be linked to authentication or authorization settings related to client references.
+              - Might interact with other integration or communication-related configuration properties.
+            - |-
+              Determines whether the system should enable support for iClient references,
+              allowing integration and interaction with iClient components or services.
+              This setting controls the activation of features that facilitate communication,
+              data exchange, or functionality extension through iClient references.
+            - |-
+              Determines whether the system should enable support for iClient references,
+              allowing integration and interaction with iClient components or services.
+              This setting controls the activation of features that facilitate communication,
+              data exchange, or functionality extension through iClient references.
+        formType:
+          type: string
+          enum:
+            - assistant
+            - http
+          x-enumDescriptions:
+            assistant: Guided setup form for applications where integrator.io provides a setup assistant; used when `_httpConnectorId` is set
+            http: Standard HTTP configuration form.
+          description: |-
+            UI form type. Set automatically by the UI: `assistant` when
+            `_httpConnectorId` is present, `http` otherwise.
+          x-celigo-ai-guidance:
+            - |-
+              ## IMPORTANT NOTES:
+              - The value must be lowercase (`assistant` or `http`).
+              - Changing this value impacts the UI experience for configuring the iClient.
+            - |-
+              ## FIELD BEHAVIOR:
+              - Controls the form layout and fields displayed in the UI.
+              - May affect validation and conditional rendering in the UI.
+              - Must be one of: `assistant`, `http`.
+            - |-
+              ## EXAMPLES:
+              - `assistant`
+              - `http`
+            - |-
+              ## DEPENDENCY CHAIN:
+              - Depends on whether the iClient is tied to an HTTP Connector (`_httpConnectorId`).
+              - Influences which UI renderer is selected for the resource.
+            - Specifies which UI form is used to configure this iClient in integrator.io.
+            - |-
+              ## IMPLEMENTATION GUIDANCE:
+              - Prefer letting the UI default this value based on `_httpConnectorId` unless you have a specific reason to override it.
+              - Use `assistant` when configuring via an iClient assistant-backed application.
+              - Use `http` for the standard HTTP configuration form.
+            - |-
+              ## TECHNICAL DETAILS:
+              - Stored as a lowercase string enum.
+        _httpConnectorId:
+          type: string
+          format: objectId
+          x-celigo-refModel: httpconnectors
+          description: HTTP connector backing this iClient's guided setup.
+          examples:
+            - 5d2e9c8b7a6f4e3d2c1b0a99
+            - 6a1f2b3c4d5e6f7a8b9c0d1e
+          x-celigo-ai-guidance:
+            - |-
+              ## IMPLEMENTATION GUIDANCE:
+              - Ensure the ID corresponds to a valid and active HTTP connector within the system.
+              - Validate the format of the ID to match expected patterns (e.g., UUID or predefined naming conventions).
+              - Use this field to dynamically select or switch HTTP connectors in multi-connector environments.
+              - Handle cases where the specified connector ID does not exist or is unavailable.
+            - |-
+              ## TECHNICAL DETAILS:
+              - Typically stored as a string data type.
+              - May be used as a key in lookup tables or configuration maps.
+              - Should be indexed for efficient retrieval in large-scale systems.
+            - |-
+              ## DEPENDENCY CHAIN:
+              - Depends on the existence of HTTP connector configurations within the system.
+              - May influence or be influenced by authentication, proxy, or network settings tied to the connector.
+            - |-
+              ## FIELD BEHAVIOR:
+              - Accepts a string representing the connector's unique ID.
+              - Used to reference an existing HTTP connector configuration.
+              - Required when the operation depends on a specific HTTP connector.
+              - Immutable once set during the lifecycle of the configuration.
+            - |-
+              Specifies the unique identifier for the HTTP connector used to establish network communication.
+              This ID links the configuration to a specific HTTP connector instance,
+              enabling the system to route requests appropriately.
+            - |-
+              ## IMPORTANT NOTES:
+              - This field is critical for routing HTTP requests correctly.
+              - Incorrect or missing connector IDs may lead to failed connections or errors.
+              - The connector ID must be managed securely to prevent unauthorized access.
+            - |-
+              ## EXAMPLES:
+              - "connector-1234abcd"
+              - "http-conn-5678efgh"
+              - "uuid-550e8400-e29b-41d4-a716-446655440000"
+            - |-
+              Specifies the unique identifier for the HTTP connector used to establish network communication.
+              This ID links the configuration to a specific HTTP connector instance,
+              enabling the system to route requests appropriately.
+            - |-
+              Specifies the unique identifier for the HTTP connector used to establish network communication.
+              This ID links the configuration to a specific HTTP connector instance,
+              enabling the system to route requests appropriately.
+        _httpConnectorApiId:
+          type: string
+          format: objectId
+          x-celigo-refModel: httpconnectorapis
+          description: HTTP connector API definition linked to this iClient.
+          examples:
+            - 669e1d90e3e73a17fb1fb1eb
+            - 5f3a9b2c8d4e1f6a7b0c2d3e
+          x-celigo-ai-guidance:
+            - |-
+              ## IMPLEMENTATION GUIDANCE:
+              - Validate the ID against the list of available HTTP Connector APIs before assignment.
+              - Ensure the ID format complies with the system's identifier standards (e.g., UUID or specific naming conventions).
+              - Handle cases where the referenced API ID does not exist or is deprecated.
+              - Use this property to dynamically bind or switch HTTP Connector APIs in configurations.
+            - |-
+              ## FIELD BEHAVIOR:
+              - Acts as a reference pointer to a specific HTTP Connector API instance.
+              - Must be a valid and existing API identifier within the system.
+              - Used to establish connections and route requests appropriately.
+              - Typically immutable once set to ensure consistent API linkage.
+            - |-
+              ## EXAMPLES:
+              - "api-123e4567-e89b-12d3-a456-426614174000"
+              - "http-connector-v2"
+              - "connectorApi_987654321"
+            - |-
+              ## TECHNICAL DETAILS:
+              - Typically stored as a string data type.
+              - Should be indexed for efficient lookup in large systems.
+              - May be linked to metadata describing the HTTP Connector API's capabilities and endpoints.
+              - Often integrated with API management tools or service registries.
+            - |-
+              Specifies the unique identifier of the HTTP Connector API associated with the
+              current configuration or operation.
+              This ID is used to reference and link the HTTP Connector API within the system,
+              enabling seamless integration and communication between components.
+            - |-
+              ## IMPORTANT NOTES:
+              - This property is critical for routing HTTP requests correctly.
+              - Incorrect or missing IDs can lead to failed API calls or misrouted traffic.
+              - Changes to this ID should be managed carefully to avoid breaking integrations.
+              - May require appropriate permissions to read or modify.
+            - |-
+              ## DEPENDENCY CHAIN:
+              - Depends on the existence of the HTTP Connector API registry or catalog.
+              - Used by components responsible for HTTP request handling and routing.
+              - May influence authentication, authorization, and logging mechanisms tied to the API.
+            - |-
+              Specifies the unique identifier of the HTTP Connector API associated with the
+              current configuration or operation.
+              This ID is used to reference and link the HTTP Connector API within the system,
+              enabling seamless integration and communication between components.
+            - |-
+              Specifies the unique identifier of the HTTP Connector API associated with the
+              current configuration or operation.
+              This ID is used to reference and link the HTTP Connector API within the system,
+              enabling seamless integration and communication between components.
+        settings:
+          type: object
+          description: |-
+            Connector-specific settings (e.g. region, environment, instance
+            URI). Shape varies by connector.
+          x-celigo-ai-guidance:
+            - |-
+              An object containing configuration options that customize the behavior and
+              features of the system or application.
+              This property allows users or developers to specify various parameters,
+              preferences, and toggles that influence how the system operates,
+              enabling flexible and dynamic adjustments to meet different requirements.
+            - |-
+              ## EXAMPLES:
+              - Setting a timeout duration with `"timeout": 3000`.
+              - Configuring logging levels with `"logging": {"level": "verbose", "output": "file"}`.
+              - Toggling feature flags such as `"features": {"betaAccess": true, "newUI": false}`.
+            - |-
+              ## IMPLEMENTATION GUIDANCE:
+              - Validate the structure and data types of the settings to ensure correctness.
+              - Provide default values for unspecified settings to maintain predictable behavior.
+              - Allow extensibility to accommodate future settings without breaking compatibility.
+              - Document each configurable option clearly to guide users in setting appropriate values.
+            - |-
+              ## IMPORTANT NOTES:
+              - Changes to settings may require system restart or reinitialization to take effect.
+              - Improper configuration can lead to unexpected behavior or degraded performance.
+              - Sensitive settings should be protected and validated to prevent security risks.
+              - The settings object should be kept as concise as possible to avoid complexity.
+            - |-
+              ## TECHNICAL DETAILS:
+              - Typically represented as a JSON object or equivalent data structure.
+              - Supports various data types including strings, numbers, booleans, arrays, and nested objects.
+              - May be stored in configuration files, databases, or managed via APIs.
+              - Should support serialization and deserialization for persistence and transmission.
+            - |-
+              ## FIELD BEHAVIOR:
+              - Accepts a structured set of key-value pairs representing different configuration settings.
+              - Can include nested objects to group related settings logically.
+              - Modifications to this property typically affect system behavior immediately or upon the next initialization.
+              - Supports enabling or disabling features, setting thresholds, defining modes, and other customizable options.
+            - |-
+              ## DEPENDENCY CHAIN:
+              - Dependent on the system's configuration management module.
+              - May influence or be influenced by user preferences and environment variables.
+              - Interacts with feature toggles, access controls, and runtime parameters.
+            - |-
+              An object containing configuration options that customize the behavior and
+              features of the system or application.
+              This property allows users or developers to specify various parameters,
+              preferences, and toggles that influence how the system operates,
+              enabling flexible and dynamic adjustments to meet different requirements.
+            - |-
+              An object containing configuration options that customize the behavior and
+              features of the system or application.
+              This property allows users or developers to specify various parameters,
+              preferences, and toggles that influence how the system operates,
+              enabling flexible and dynamic adjustments to meet different requirements.
+        settingsForm:
+          type: object
+          description: Dynamic UI form definition for the settings object.
+          x-celigo-ai-guidance:
+            - |-
+              ## EXAMPLES:
+              - A form object with fields for username, email preferences, and notification settings.
+              - A nested form structure with sections for privacy, display, and account management.
+              - Validation rules specifying required fields and acceptable value ranges.
+            - |-
+              An object representing the configuration and structure of a settings form used
+              to capture user preferences or application parameters.
+              This form typically includes fields, validation rules, default values,
+              and UI metadata necessary for rendering and processing the settings interface.
+            - |-
+              ## IMPORTANT NOTES:
+              - The form should be designed to accommodate localization and accessibility standards.
+              - Changes to the form structure may require corresponding updates in the UI and backend processing.
+              - Ensure sensitive data fields are handled securely and comply with privacy regulations.
+            - |-
+              ## IMPLEMENTATION GUIDANCE:
+              - Structure the form object to include field definitions, types, labels, and validation constraints.
+              - Include metadata for UI rendering such as placeholders, tooltips, and grouping.
+              - Ensure validation rules are comprehensive to prevent invalid input.
+              - Support extensibility to add or modify fields without breaking existing functionality.
+            - |-
+              ## TECHNICAL DETAILS:
+              - Typically represented as a JSON object or similar structured data format.
+              - May include nested objects or arrays to represent complex form hierarchies.
+              - Validation rules can be expressed using standard schemas or custom logic.
+              - Supports integration with form libraries or frameworks for rendering and state management.
+            - |-
+              ## DEPENDENCY CHAIN:
+              - Depends on UI components to render the form fields.
+              - Relies on validation logic to enforce input correctness.
+              - Interacts with backend services to save and retrieve settings data.
+            - |-
+              ## FIELD BEHAVIOR:
+              - Defines the layout and components of the settings form.
+              - Contains input fields with associated validation and default values.
+              - Supports dynamic updates based on user interaction or external data.
+              - Facilitates submission and retrieval of user-configured settings.
+            - |-
+              An object representing the configuration and structure of a settings form used
+              to capture user preferences or application parameters.
+              This form typically includes fields, validation rules, default values,
+              and UI metadata necessary for rendering and processing the settings interface.
+            - |-
+              An object representing the configuration and structure of a settings form used
+              to capture user preferences or application parameters.
+              This form typically includes fields, validation rules, default values,
+              and UI metadata necessary for rendering and processing the settings interface.
+        oauth2:
+          type: object
+          description: |-
+            OAuth 2.0 configuration. Used when `provider` is `custom_oauth2`
+            or any OAuth-based provider.
+          x-celigo-ai-guidance:
+            - |-
+              ## DEPENDENCY CHAIN:
+              - Depends on the presence of an OAuth 2.0 compliant authorization server.
+              - Requires secure storage and transmission of client credentials.
+              - Interacts with API endpoints that enforce OAuth 2.0 token validation.
+            - |-
+              ## IMPLEMENTATION GUIDANCE:
+              - Ensure URLs for authorization and token endpoints are accurate and reachable.
+              - Clearly define the scopes to limit access according to least privilege principles.
+              - Include client ID and client secret securely, avoiding exposure in client-side code.
+              - Support refresh tokens if long-lived sessions are required.
+              - Validate tokens on the server side to maintain security.
+            - |-
+              ## TECHNICAL DETAILS:
+              - Typically includes fields like authorizationUrl, tokenUrl, refreshUrl, scopes, clientId, clientSecret, and grantTypes.
+              - Uses HTTPS endpoints to ensure secure communication.
+              - May support PKCE (Proof Key for Code Exchange) for enhanced security in public clients.
+              - Tokens are usually JWTs or opaque tokens depending on the OAuth provider implementation.
+            - |-
+              ## FIELD BEHAVIOR:
+              - Defines the OAuth 2.0 flow and parameters required for client authentication.
+              - Specifies the endpoints for obtaining authorization and access tokens.
+              - Lists the scopes that determine the level of access granted.
+              - Supports multiple OAuth 2.0 grant types (e.g., authorization code, client credentials).
+              - Enables secure token exchange and refresh mechanisms.
+            - |-
+              ## EXAMPLES:
+              - Authorization code flow with authorization URL, token URL, and scopes.
+              - Client credentials flow with token URL and client credentials.
+              - Implicit flow configuration for single-page applications.
+              - Refresh token configuration for renewing access tokens.
+            - |-
+              ## IMPORTANT NOTES:
+              - OAuth 2.0 configurations must comply with the security best practices to prevent token leakage.
+              - Sensitive information such as client secrets should never be exposed publicly.
+              - The choice of grant type depends on the client application type and security requirements.
+              - Proper error handling should be implemented for token acquisition failures.
+            - |-
+              Configuration settings for OAuth 2.0 authentication,
+              enabling secure authorization and access delegation for API clients.
+              This property typically includes details such as authorization URLs, token URLs,
+              scopes, client credentials, and grant types supported by the OAuth 2.0 provider.
+            - |-
+              Configuration settings for OAuth 2.0 authentication,
+              enabling secure authorization and access delegation for API clients.
+              This property typically includes details such as authorization URLs, token URLs,
+              scopes, client credentials, and grant types supported by the OAuth 2.0 provider.
+            - |-
+              Configuration settings for OAuth 2.0 authentication,
+              enabling secure authorization and access delegation for API clients.
+              This property typically includes details such as authorization URLs, token URLs,
+              scopes, client credentials, and grant types supported by the OAuth 2.0 provider.
+          properties:
+            clientId:
+              type: string
+              description: OAuth 2.0 client ID from the provider's app registration.
+              x-celigo-ai-guidance:
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Dependent on successful client registration with the OAuth 2.0 authorization server.
+                  - Used in conjunction with client secret (if applicable) during token requests.
+                  - Required for constructing authorization URLs and token exchange requests.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Must be a unique string assigned by the authorization server.
+                  - Used in authorization and token request flows to identify the client application.
+                  - Typically remains constant for the lifetime of the client registration.
+                  - Should be included in all OAuth 2.0 requests where client identification is required.
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Typically a string of alphanumeric characters, sometimes including dashes or underscores.
+                  - May be case-sensitive depending on the OAuth provider.
+                  - Passed as a query parameter or in the request body during OAuth flows.
+                  - Must conform to the OAuth 2.0 specification and provider-specific requirements.
+                - |-
+                  The unique identifier assigned to a client application during the OAuth 2.0
+                  registration process.
+                  This client ID is used to identify the application when making authorization
+                  requests to the OAuth 2.0 authorization server.
+                  It is a public value that is included in authorization requests and token
+                  exchanges to associate the requests with the registered client.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Obtain the client ID from the OAuth 2.0 provider during client registration.
+                  - Store the client ID securely within the application configuration.
+                  - Do not treat the client ID as a secret; it can be exposed in URLs and logs.
+                  - Validate the client ID format according to the OAuth provider's specifications.
+                - |-
+                  ## IMPORTANT NOTES:
+                  - The client ID is distinct from the client secret; the latter must be kept confidential.
+                  - Exposure of the client ID does not compromise security but is necessary for proper OAuth flows.
+                  - Ensure the client ID matches exactly the value registered with the OAuth provider to avoid authentication errors.
+                - |-
+                  ## EXAMPLES:
+                  - "abc123xyz"
+                  - "myapp-client-001"
+                  - "1234567890abcdef"
+                - |-
+                  The unique identifier assigned to a client application during the OAuth 2.0
+                  registration process.
+                  This client ID is used to identify the application when making authorization
+                  requests to the OAuth 2.0 authorization server.
+                  It is a public value that is included in authorization requests and token
+                  exchanges to associate the requests with the registered client.
+                - |-
+                  The unique identifier assigned to a client application during the OAuth 2.0
+                  registration process.
+                  This client ID is used to identify the application when making authorization
+                  requests to the OAuth 2.0 authorization server.
+                  It is a public value that is included in authorization requests and token
+                  exchanges to associate the requests with the registered client.
+              examples:
+                - 1096775564568-cucr5sv44tgfec4kkqsufi5k975d8orv.apps.googleusercontent.com
+                - abc123xyz
+                - myapp-client-001
+                - 1234567890abcdef
+            clientSecret:
+              type: string
+              description: |-
+                OAuth 2.0 client secret. Returned masked as `"******"`.
+                Re-send that value on update to keep it; it is not preserved if omitted.
+              x-celigo-ai-guidance:
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Provide the plain client secret value here to set/update it.
+                  - To keep the existing secret unchanged during an update, omit this field (or, if the API/UI returns a masked value, keep `"******"` as-is).
+                - |-
+                  This is the value you provide to configure or update the iClient.
+                  Internally,
+                  integrator.io stores this secret encrypted at rest (for example as
+                  `clientSecret_crypt` and `clientSecret_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a secret is already set.
+                - |-
+                  This is the value you provide to configure or update the iClient.
+                  Internally,
+                  integrator.io stores this secret encrypted at rest (for example as
+                  `clientSecret_crypt` and `clientSecret_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a secret is already set.
+                - |-
+                  This is the value you provide to configure or update the iClient.
+                  Internally,
+                  integrator.io stores this secret encrypted at rest (for example as
+                  `clientSecret_crypt` and `clientSecret_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a secret is already set.
+            scope:
+              type: array
+              items:
+                type: string
+              description: |-
+                OAuth 2.0 scopes. The API accepts a string on input but
+                always returns an array in responses.
+              x-celigo-ai-guidance:
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Depends on the OAuth 2.0 authorization server's scope definitions.
+                  - Influences the access token issued and the permissions it carries.
+                  - Affects user consent and authorization decisions.
+                  - Interacts with resource server policies enforcing scope-based access control.
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Represented as a single string with space-separated scope values.
+                  - Included as a parameter in the authorization request and token request.
+                  - Returned in the access token response under the "scope" attribute.
+                  - Must conform to the OAuth 2.0 specification (RFC 6749) for scope syntax and semantics.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Specifies one or more space-delimited strings representing permissions.
+                  - Determines the extent of access granted by the access token.
+                  - Can be optional or required depending on the OAuth 2.0 flow and server configuration.
+                  - May influence the consent screen shown to the user during authorization.
+                - |-
+                  ## IMPORTANT NOTES:
+                  - Scopes are case-sensitive and must be handled consistently.
+                  - Overly broad scopes can lead to security risks; prefer minimal necessary scopes.
+                  - Some OAuth providers define custom scopes specific to their APIs.
+                  - The absence of a scope parameter may result in default or limited access.
+                - |-
+                  Defines the specific permissions or access levels that the OAuth 2.0 token
+                  grants to the client application.
+                  Scopes limit the actions and resources the client can access on behalf of the user,
+                  ensuring fine-grained control over authorization.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Use standardized or well-defined scope values to ensure interoperability.
+                  - Clearly document the meaning and permissions associated with each scope.
+                  - Support multiple scopes by allowing space-separated values.
+                  - Validate requested scopes against allowed scopes on the authorization server.
+                  - Return granted scopes in the token response to inform the client of authorized permissions.
+                - |-
+                  ## EXAMPLES:
+                  - "read"
+                  - "write"
+                  - "openid profile email"
+                  - "user.read user.write"
+                  - "https://api.example.com/auth/calendar.read"
+                - |-
+                  Defines the specific permissions or access levels that the OAuth 2.0 token
+                  grants to the client application.
+                  Scopes limit the actions and resources the client can access on behalf of the user,
+                  ensuring fine-grained control over authorization.
+                - |-
+                  Defines the specific permissions or access levels that the OAuth 2.0 token
+                  grants to the client application.
+                  Scopes limit the actions and resources the client can access on behalf of the user,
+                  ensuring fine-grained control over authorization.
+            scopeDelimiter:
+              type: string
+              description: |-
+                Character separating multiple scopes in a single string.
+                Defaults to space per the OAuth 2.0 spec (RFC 6749).
+              x-celigo-ai-guidance:
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Typically a single character but can be a string if supported.
+                  - Used in string splitting functions to parse scope lists.
+                  - Should be URL-encoded if it is a special character in URLs.
+                  - Must be consistent with the OAuth2 provider's expectations to ensure interoperability.
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Depends on the OAuth2 authorization server's scope formatting requirements.
+                  - Influences how the 'scope' parameter in authorization requests and tokens is constructed and parsed.
+                  - May affect downstream components that interpret or validate scopes.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Defines how multiple scopes are split and recognized in authorization requests.
+                  - Ensures correct parsing of scope strings when multiple scopes are requested simultaneously.
+                  - Influences the format of the scope parameter in OAuth2 authorization URLs and tokens.
+                - |-
+                  Specifies the character or string used to separate multiple OAuth2 scopes within
+                  a single authorization request or token.
+                  This delimiter enables the parsing and interpretation of scope values when they
+                  are provided as a concatenated string.
+                  Common delimiters include spaces, commas,
+                  or other characters depending on the OAuth2 provider's implementation.
+                - |-
+                  ## EXAMPLES:
+                  - Space character (" ") as a delimiter: "read write delete"
+                  - Comma (",") as a delimiter: "read,write,delete"
+                  - Semicolon (";") as a delimiter: "read;write;delete"
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Choose a delimiter that aligns with the OAuth2 provider's specification or defaults (e.g., space is standard per OAuth2 spec).
+                  - Ensure consistent use of the delimiter across all OAuth2 requests and responses.
+                  - Validate scope strings to correctly split and handle multiple scopes using this delimiter.
+                  - Document the chosen delimiter clearly for developers integrating with the API.
+                - |-
+                  ## IMPORTANT NOTES:
+                  - The OAuth2 specification (RFC 6749) recommends using a space character as the scope delimiter.
+                  - Some OAuth2 providers may use non-standard delimiters; this property allows customization to accommodate those cases.
+                  - Incorrect delimiter configuration can lead to authorization failures or incorrect scope parsing.
+                  - When omitted, the default delimiter is typically a space character.
+                - |-
+                  Specifies the character or string used to separate multiple OAuth2 scopes within
+                  a single authorization request or token.
+                  This delimiter enables the parsing and interpretation of scope values when they
+                  are provided as a concatenated string.
+                  Common delimiters include spaces, commas,
+                  or other characters depending on the OAuth2 provider's implementation.
+                - |-
+                  Specifies the character or string used to separate multiple OAuth2 scopes within
+                  a single authorization request or token.
+                  This delimiter enables the parsing and interpretation of scope values when they
+                  are provided as a concatenated string.
+                  Common delimiters include spaces, commas,
+                  or other characters depending on the OAuth2 provider's implementation.
+              examples:
+                - ' '
+            redirectUri:
+              type: string
+              description: OAuth 2.0 redirect URI registered with the provider.
+              x-celigo-ai-guidance:
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Depends on the authorization server's registered redirect URIs.
+                  - Used in conjunction with client_id and response_type parameters.
+                  - Integral to OAuth 2.0 authorization code and implicit grant flows.
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Must conform to URI syntax as per RFC 3986.
+                  - Typically uses HTTPS scheme for security.
+                  - Should be URL-encoded when included in authorization requests.
+                  - The authorization server compares the redirect URI in the request with the registered URIs for exact match or pattern match depending on server policy.
+                - |-
+                  ## EXAMPLES:
+                  - https://client.example.com/callback
+                  - https://app.example.com/oauth2/callback
+                  - https://localhost:8080/auth/callback (for development purposes)
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Ensure the redirect URI is registered with the authorization server before use.
+                  - Use HTTPS to protect the integrity and confidentiality of the redirect.
+                  - Avoid using wildcard or overly broad redirect URIs.
+                  - Validate the redirect URI strictly on the server side to prevent open redirect vulnerabilities.
+                - |-
+                  ## IMPORTANT NOTES:
+                  - Mismatched redirect URIs will cause authorization requests to fail.
+                  - Redirect URIs should not contain fragments (#).
+                  - Avoid using query parameters unless necessary and registered.
+                  - The redirect URI is critical for security; improper configuration can lead to token leakage.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Specifies the callback endpoint for the authorization response.
+                  - Must be an absolute URI.
+                  - Used to return authorization codes or tokens after user consent.
+                  - Validated against pre-registered URIs to ensure security.
+                - |-
+                  The URI to which the authorization server will redirect the user-agent after
+                  granting or denying access.
+                  This URI must be registered with the authorization server and should exactly
+                  match one of the pre-registered redirect URIs to prevent security
+                  vulnerabilities such as open redirect attacks.
+                  It is used in OAuth 2.0 authorization flows to receive authorization codes or
+                  access tokens securely.
+                - |-
+                  The URI to which the authorization server will redirect the user-agent after
+                  granting or denying access.
+                  This URI must be registered with the authorization server and should exactly
+                  match one of the pre-registered redirect URIs to prevent security
+                  vulnerabilities such as open redirect attacks.
+                  It is used in OAuth 2.0 authorization flows to receive authorization codes or
+                  access tokens securely.
+                - |-
+                  The URI to which the authorization server will redirect the user-agent after
+                  granting or denying access.
+                  This URI must be registered with the authorization server and should exactly
+                  match one of the pre-registered redirect URIs to prevent security
+                  vulnerabilities such as open redirect attacks.
+                  It is used in OAuth 2.0 authorization flows to receive authorization codes or
+                  access tokens securely.
+              examples:
+                - https://api.integrator.io/connection/oauth2callback
+                - https://client.example.com/callback
+                - https://app.example.com/oauth2/callback
+                - https://localhost:8080/auth/callback
+            grantType:
+              type: string
+              enum:
+                - authorizecode
+                - password
+                - clientcredentials
+              x-enumDescriptions:
+                authorizecode: Authorization Code grant (server-side flows with user authorization).
+                password: Resource Owner Password Credentials grant (trusted apps with direct credentials).
+                clientcredentials: Client Credentials grant (machine-to-machine, no user involvement).
+              description: OAuth 2.0 grant type.
+              examples:
+                - password
+              x-celigo-ai-guidance:
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Defines the method by which the client application requests an access token.
+                  - Influences the parameters required in the token request.
+                  - Determines the security and user interaction model of the OAuth flow.
+                  - Must align with the authorization server's supported grant types.
+                - |-
+                  ## IMPORTANT NOTES:
+                  - Some grant types require additional parameters (e.g., "authorization_code" requires a code).
+                  - Using the "password" grant type is discouraged due to security risks.
+                  - The choice of grant type affects the overall security posture of the application.
+                  - Always use secure communication channels (HTTPS) when transmitting tokens and credentials.
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Must be a string matching one of the OAuth 2.0 defined grant types or extensions.
+                  - Sent as a parameter in the token request payload or URL-encoded form.
+                  - Case-sensitive and must conform to the OAuth 2.0 specification (RFC 6749).
+                  - May require additional headers or parameters depending on the grant type.
+                - |-
+                  ## EXAMPLES:
+                  - "authorization_code" for standard web server flows involving user authorization.
+                  - "client_credentials" for machine-to-machine authentication without user involvement.
+                  - "password" for legacy applications where the user provides credentials directly.
+                  - "refresh_token" to obtain a new access token using a previously issued refresh token.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Choose the grant type based on the client application's capabilities and security requirements.
+                  - Ensure the authorization server supports the specified grant type.
+                  - Validate the grant type value against the OAuth 2.0 specification and any extensions used.
+                  - Handle errors gracefully if an unsupported or invalid grant type is provided.
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Depends on the OAuth 2.0 authorization server configuration.
+                  - Influences the required request parameters and token endpoint behavior.
+                  - Affects client registration details and scopes granted.
+                - |-
+                  Specifies the OAuth 2.0 grant type used to obtain an access token from the authorization server.
+                  This parameter determines the flow of the authentication process and how the
+                  client interacts with the authorization server to request and receive tokens.
+                  Common grant types include "authorization_code", "client_credentials",
+                  "password", and "refresh_token",
+                  each serving different use cases and security considerations.
+                - |-
+                  Specifies the OAuth 2.0 grant type used to obtain an access token from the authorization server.
+                  This parameter determines the flow of the authentication process and how the
+                  client interacts with the authorization server to request and receive tokens.
+                  Common grant types include "authorization_code", "client_credentials",
+                  "password", and "refresh_token",
+                  each serving different use cases and security considerations.
+                - |-
+                  Specifies the OAuth 2.0 grant type used to obtain an access token from the authorization server.
+                  This parameter determines the flow of the authentication process and how the
+                  client interacts with the authorization server to request and receive tokens.
+                  Common grant types include "authorization_code", "client_credentials",
+                  "password", and "refresh_token",
+                  each serving different use cases and security considerations.
+            clientCredentialsLocation:
+              type: string
+              enum:
+                - basicauthheader
+                - body
+              x-enumDescriptions:
+                basicauthheader: Client credentials sent in the Authorization header (HTTP Basic).
+                body: Client credentials sent as form parameters in the POST body.
+              description: Where to include client credentials in the token request.
+              x-celigo-ai-guidance:
+                - |-
+                  ## IMPORTANT NOTES:
+                  - Sending credentials in the header is generally preferred for security reasons.
+                  - Some OAuth 2.0 servers may only support one method; verify server documentation.
+                  - Incorrect configuration may lead to authentication failures.
+                  - Avoid exposing client credentials in URLs or query parameters.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Use "header" to send credentials via the Authorization header using Basic authentication.
+                  - Use "body" to include credentials as form parameters in the POST request body.
+                  - Ensure compatibility with the OAuth 2.0 server's expected credential location.
+                  - Validate that the chosen location aligns with security best practices and server requirements.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Defines where to place client credentials during the token request.
+                  - Accepts values indicating header or body placement.
+                  - Influences how the authentication server receives and validates client credentials.
+                - |-
+                  Specifies the location within the HTTP request where the client credentials
+                  (such as client ID and client secret) should be included when using the OAuth
+                  2.0 client credentials grant type.
+                  This setting determines whether the credentials are sent in the request header
+                  (typically using the Authorization header with Basic authentication) or in the
+                  request body as form parameters.
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - When set to "header", credentials are base64-encoded and included in the Authorization header.
+                  - When set to "body", credentials are included as "client_id" and "client_secret" form parameters.
+                  - Must comply with the OAuth 2.0 specification (RFC 6749) regarding client authentication methods.
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Depends on the OAuth 2.0 client credentials grant type being used.
+                  - Works in conjunction with clientId and clientSecret properties.
+                  - Affects the construction of the token request sent to the authorization server.
+                - |-
+                  Specifies the location within the HTTP request where the client credentials
+                  (such as client ID and client secret) should be included when using the OAuth
+                  2.0 client credentials grant type.
+                  This setting determines whether the credentials are sent in the request header
+                  (typically using the Authorization header with Basic authentication) or in the
+                  request body as form parameters.
+                - |-
+                  Specifies the location within the HTTP request where the client credentials
+                  (such as client ID and client secret) should be included when using the OAuth
+                  2.0 client credentials grant type.
+                  This setting determines whether the credentials are sent in the request header
+                  (typically using the Authorization header with Basic authentication) or in the
+                  request body as form parameters.
+            accessTokenLocation:
+              type: string
+              enum:
+                - url
+                - header
+                - body
+              x-enumDescriptions:
+                url: Access token sent as a URL query parameter.
+                header: Access token sent in the Authorization header.
+                body: Access token sent in the POST request body.
+              description: Where the access token is included in API requests.
+              x-celigo-ai-guidance:
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Depends on the OAuth 2.0 flow and server requirements.
+                  - Works in conjunction with the access token value and token type.
+                  - Influences request construction and security considerations.
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - When set to "header", typically uses the "Authorization: Bearer <token>" format.
+                  - When set to "query", appends the token as a URL parameter, often named "access_token".
+                  - When set to "body", includes the token in the request payload, usually as a form parameter.
+                  - Must be handled securely to prevent token leakage.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Defines the method of including the access token in API requests.
+                  - Common values include "header", "query", or "body".
+                  - Influences how the client constructs the request for authentication.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Verify the API specification to determine the supported token locations.
+                  - Use "header" to include the token in the Authorization header (e.g., Bearer token).
+                  - Use "query" to append the token as a URL query parameter.
+                  - Use "body" to include the token within the request payload, typically for POST requests.
+                  - Ensure secure transmission, especially when using query parameters.
+                - |-
+                  ## IMPORTANT NOTES:
+                  - Sending tokens in query parameters can expose them in logs or browser history; use with caution.
+                  - The chosen location must align with the OAuth 2.0 server's expectations.
+                  - Some APIs may only support one method; incorrect configuration can lead to authentication failures.
+                - |-
+                  Specifies the location where the OAuth 2.0 access token should be included when
+                  making API requests.
+                  This determines how the access token is transmitted to the server,
+                  such as in the HTTP header, query parameters, or request body.
+                  Proper configuration of this field ensures that the token is sent in a manner
+                  compatible with the API's authentication requirements.
+                - |-
+                  Specifies the location where the OAuth 2.0 access token should be included when
+                  making API requests.
+                  This determines how the access token is transmitted to the server,
+                  such as in the HTTP header, query parameters, or request body.
+                  Proper configuration of this field ensures that the token is sent in a manner
+                  compatible with the API's authentication requirements.
+                - |-
+                  Specifies the location where the OAuth 2.0 access token should be included when
+                  making API requests.
+                  This determines how the access token is transmitted to the server,
+                  such as in the HTTP header, query parameters, or request body.
+                  Proper configuration of this field ensures that the token is sent in a manner
+                  compatible with the API's authentication requirements.
+            accessTokenHeaderName:
+              type:
+                - string
+                - 'null'
+              description: |-
+                Header name for the access token when `accessTokenLocation`
+                is `header`. Defaults to `Authorization`.
+              x-celigo-ai-guidance:
+                - |-
+                  ## EXAMPLES:
+                  - `Authorization` (typically with value `Bearer <token>`)
+                  - `X-Access-Token`
+                - Header name used to send the OAuth 2.0 access token.
+              examples:
+                - Authorization
+                - '`Authorization`'
+                - '`X-Access-Token`'
+            accessTokenParamName:
+              type: string
+              description: |-
+                Parameter name when the access token is sent as a
+                query or body parameter.
+              x-celigo-ai-guidance:
+                - |-
+                  ## EXAMPLES:
+                  - `access_token`
+                  - `token`
+                  - `auth_token`
+                - |-
+                  Parameter name used when the access token is passed as a query/body parameter
+                  (instead of a header).
+                - |-
+                  Parameter name used when the access token is passed as a query/body parameter
+                  (instead of a header).
+                - |-
+                  Parameter name used when the access token is passed as a query/body parameter
+                  (instead of a header).
+              examples:
+                - access_token
+                - '`access_token`'
+                - '`token`'
+                - '`auth_token`'
+            accessTokenPath:
+              type: string
+              description: |-
+                JSON path to extract the access token from the token
+                endpoint response body.
+              x-celigo-ai-guidance:
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Defines the endpoint path for access token requests in the OAuth2 flow.
+                  - Must be a valid relative URL path starting with a forward slash (/).
+                  - Used during the token exchange phase after obtaining an authorization code or other grant types.
+                  - Typically combined with the authorization server's base URL to form the complete token endpoint URL.
+                - |-
+                  Specifies the relative URL path on the OAuth2 authorization server where the
+                  access token request should be sent.
+                  This path is appended to the base URL of the authorization server to form the
+                  full endpoint for obtaining an access token during the OAuth2 authentication
+                  flow.
+                  It is essential for enabling clients to exchange authorization grants for access
+                  tokens securely.
+                - |-
+                  ## IMPORTANT NOTES:
+                  - This path is critical for the OAuth2 token exchange process; incorrect configuration will prevent successful authentication.
+                  - It should not include the full URL, only the path component.
+                  - Must align with the OAuth2 server's documentation to ensure interoperability.
+                  - Often used in conjunction with other OAuth2 properties like client ID, client secret, and authorization path.
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Depends on the base URL of the OAuth2 authorization server.
+                  - Used alongside authorizationPath and other OAuth2 configuration properties.
+                  - Integral to the OAuth2 token grant process.
+                - |-
+                  ## EXAMPLES:
+                  - /oauth2/token
+                  - /api/v1/access_token
+                  - /auth/token
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Ensure the path corresponds exactly to the OAuth2 server's token endpoint specification.
+                  - Validate that the path is correctly formatted and accessible.
+                  - Avoid including query parameters or fragments in this path; it should be a clean URL path.
+                  - Confirm compatibility with the OAuth2 server's expected token endpoint URL structure.
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Expected to be a URI path string.
+                  - Should begin with a forward slash (/).
+                  - Combined with the OAuth2 server's base URL to form the full token endpoint URI.
+                  - Utilized in HTTP POST requests to obtain access tokens.
+                - |-
+                  Specifies the relative URL path on the OAuth2 authorization server where the
+                  access token request should be sent.
+                  This path is appended to the base URL of the authorization server to form the
+                  full endpoint for obtaining an access token during the OAuth2 authentication
+                  flow.
+                  It is essential for enabling clients to exchange authorization grants for access
+                  tokens securely.
+                - |-
+                  Specifies the relative URL path on the OAuth2 authorization server where the
+                  access token request should be sent.
+                  This path is appended to the base URL of the authorization server to form the
+                  full endpoint for obtaining an access token during the OAuth2 authentication
+                  flow.
+                  It is essential for enabling clients to exchange authorization grants for access
+                  tokens securely.
+              examples:
+                - access_token
+                - /oauth2/token
+                - /api/v1/access_token
+                - /auth/token
+            refreshTokenPath:
+              type: string
+              description: |-
+                JSON path to extract the refresh token from the token
+                endpoint response body.
+              x-celigo-ai-guidance:
+                - |-
+                  ## IMPORTANT NOTES:
+                  - This path is distinct from the initial token request endpoint.
+                  - The refresh token flow requires that the client has previously obtained a refresh token.
+                  - Not all OAuth 2.0 providers support refresh tokens; verify compatibility.
+                  - The endpoint must support secure communication protocols (e.g., HTTPS).
+                - |-
+                  ## EXAMPLES:
+                  - "/oauth2/token/refresh"
+                  - "https://auth.example.com/oauth2/token"
+                  - "/api/v1/auth/refresh-token"
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Depends on the existence of a valid refresh token issued during initial authentication.
+                  - Works in conjunction with the access token and client credentials.
+                  - Related to the OAuth 2.0 token endpoint configuration.
+                - |-
+                  The relative or absolute URL path used to request a refresh token from the OAuth
+                  2.0 authorization server.
+                  This endpoint is typically called when the current access token has expired or
+                  is about to expire,
+                  allowing the client to obtain a new access token without requiring the user to re-authenticate.
+                  The path should conform to the OAuth 2.0 specification for token refresh
+                  requests and support the necessary HTTP methods,
+                  usually POST.
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Typically uses the HTTP POST method with form-encoded parameters.
+                  - Requires parameters such as grant_type=refresh_token and the refresh_token itself.
+                  - Responses include a new access token and optionally a new refresh token.
+                  - Must handle scopes and token expiration as per OAuth 2.0 standards.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Ensure the path is correctly formatted as a relative or absolute URL.
+                  - Confirm that the authorization server supports refresh token requests at this endpoint.
+                  - Secure the endpoint with appropriate authentication and authorization measures.
+                  - Validate that the client credentials and refresh token are correctly handled during the request.
+                  - Handle error responses gracefully, such as invalid or expired refresh tokens.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Specifies the endpoint for refreshing OAuth 2.0 access tokens.
+                  - Used by the client application to maintain authenticated sessions seamlessly.
+                  - Invoked automatically by the client when the access token expires or is near expiration.
+                  - Must be accessible and correctly configured on the authorization server.
+                - |-
+                  The relative or absolute URL path used to request a refresh token from the OAuth
+                  2.0 authorization server.
+                  This endpoint is typically called when the current access token has expired or
+                  is about to expire,
+                  allowing the client to obtain a new access token without requiring the user to re-authenticate.
+                  The path should conform to the OAuth 2.0 specification for token refresh
+                  requests and support the necessary HTTP methods,
+                  usually POST.
+                - |-
+                  The relative or absolute URL path used to request a refresh token from the OAuth
+                  2.0 authorization server.
+                  This endpoint is typically called when the current access token has expired or
+                  is about to expire,
+                  allowing the client to obtain a new access token without requiring the user to re-authenticate.
+                  The path should conform to the OAuth 2.0 specification for token refresh
+                  requests and support the necessary HTTP methods,
+                  usually POST.
+              examples:
+                - refresh_token
+                - /oauth2/token/refresh
+                - https://auth.example.com/oauth2/token
+                - /api/v1/auth/refresh-token
+            scheme:
+              type: string
+              description: Authorization scheme prefix (e.g. `Bearer`, `Basic`).
+              x-celigo-ai-guidance:
+                - |-
+                  ## EXAMPLES:
+                  - "authorization_code" for server-side web applications.
+                  - "implicit" for single-page applications.
+                  - "password" for trusted applications with user credentials.
+                  - "client_credentials" for machine-to-machine authentication.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Choose the scheme that best fits the client application type and security context.
+                  - Ensure the scheme aligns with the OAuth 2.0 specification and server capabilities.
+                  - Clearly document the chosen scheme to aid client developers in implementation.
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Depends on the OAuth 2.0 specification version supported.
+                  - Interacts with token endpoint and authorization endpoint configurations.
+                  - Influences client registration and credential management.
+                - |-
+                  ## IMPORTANT NOTES:
+                  - Selecting an inappropriate scheme can lead to security vulnerabilities.
+                  - Some schemes may require additional parameters or configurations.
+                  - The scheme impacts token lifecycle and refresh mechanisms.
+                - |-
+                  Specifies the OAuth 2.0 authorization scheme used for securing API requests.
+                  This field defines the method by which the client obtains and presents access
+                  tokens to authenticate and authorize API calls.
+                  Common schemes include "authorization_code", "implicit", "password",
+                  and "client_credentials",
+                  each representing a different OAuth 2.0 flow tailored to various client types
+                  and security requirements.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Determines the OAuth 2.0 flow applied for token acquisition.
+                  - Influences how clients interact with the authorization server.
+                  - Guides the expected parameters and endpoints involved in the authentication process.
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Typically represented as a string value.
+                  - Must conform to recognized OAuth 2.0 flow identifiers.
+                  - Used by client libraries to determine authentication steps.
+                - |-
+                  Specifies the OAuth 2.0 authorization scheme used for securing API requests.
+                  This field defines the method by which the client obtains and presents access
+                  tokens to authenticate and authorize API calls.
+                  Common schemes include "authorization_code", "implicit", "password",
+                  and "client_credentials",
+                  each representing a different OAuth 2.0 flow tailored to various client types
+                  and security requirements.
+                - |-
+                  Specifies the OAuth 2.0 authorization scheme used for securing API requests.
+                  This field defines the method by which the client obtains and presents access
+                  tokens to authenticate and authorize API calls.
+                  Common schemes include "authorization_code", "implicit", "password",
+                  and "client_credentials",
+                  each representing a different OAuth 2.0 flow tailored to various client types
+                  and security requirements.
+              examples:
+                - Bearer
+                - authorization_code
+                - implicit
+                - password
+                - client_credentials
+            validDomainNames:
+              type: array
+              items:
+                type: string
+              description: |-
+                Domain names used to validate OAuth URLs. Provide each
+                unique domain once (no scheme, no path).
+              examples:
+                - - domain.com
+                - - domain.com
+                  - domain1.com
+                  - domain2.com
+              x-celigo-ai-guidance:
+                - |-
+                  Set this to the list of unique domain names used to validate the OAuth URLs (Authorization,
+                  Access Token, Revoke Token).
+                  In the UI, enter each unique domain name as comma-separated values;
+                  if the same domain is used for each URL, provide it only once.
+                  For multiple domains, set this to `["domain.com", "domain1.com",
+                  "domain2.com"]`; if all URLs share the same domain (e.g.
+                  `domain.com`), set this to `["domain.com"]`.
+                - |-
+                  Example: if your URLs are:
+                  - `https://<AccessTokenURL>.domain.com`
+                  - `https://<RevokeTokenURL>.domain1.com`
+                  - `https://<AuthorizationURL>.domain2.com`
+
+                  then set `validDomainNames` to: `["domain.com", "domain1.com", "domain2.com"]`.
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Stored as an array of strings.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Array of domain names (no scheme, no path).
+                  - Used to validate the OAuth URL domains (authorization/token/revoke).
+                  - Provide each unique domain once.
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Used alongside `oauth2.auth.uri`, `oauth2.token.uri`, and `oauth2.revoke.uri`.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Extract the domain portion from each OAuth URL and include it here.
+                  - Do not include `https://` or any URL path/query—only the domain.
+                  - Keep this list in sync if any OAuth URLs change.
+                - |-
+                  ## EXAMPLES:
+                  - ["domain.com"]
+                  - ["domain.com", "domain1.com", "domain2.com"]
+                - |-
+                  ## IMPORTANT NOTES:
+                  - This is about **domains** for OAuth URLs, not full URLs.
+                - |-
+                  Example: if your URLs are:
+                  - `https://<AccessTokenURL>.domain.com`
+                  - `https://<RevokeTokenURL>.domain1.com`
+                  - `https://<AuthorizationURL>.domain2.com`
+                - |-
+                  Set this to the list of unique domain names used to validate the OAuth URLs (Authorization,
+                  Access Token, Revoke Token).
+                  In the UI, enter each unique domain name as comma-separated values;
+                  if the same domain is used for each URL, provide it only once.
+                  For multiple domains, set this to `["domain.com", "domain1.com",
+                  "domain2.com"]`; if all URLs share the same domain (e.g.
+                  `domain.com`), set this to `["domain.com"]`.
+                - |-
+                  Set this to the list of unique domain names used to validate the OAuth URLs (Authorization,
+                  Access Token, Revoke Token).
+                  In the UI, enter each unique domain name as comma-separated values;
+                  if the same domain is used for each URL, provide it only once.
+                  For multiple domains, set this to `["domain.com", "domain1.com",
+                  "domain2.com"]`; if all URLs share the same domain (e.g.
+                  `domain.com`), set this to `["domain.com"]`.
+            failPath:
+              type: string
+              description: |-
+                Response body path to check for auth errors. Set only if
+                the API uses a field in the response body (not just HTTP
+                status) to indicate auth failures.
+              x-celigo-ai-guidance:
+                - |-
+                  This field only needs to be set if the API returns a field in the HTTP response
+                  body to indicate auth errors.
+                  For example,
+                  if an API returns the field `errorMessage` with the value `Auth failed`,
+                  then set this field to `errorMessage`.
+                - |-
+                  ## EXAMPLES:
+                  - `errorMessage`
+                  - `error`
+                  - `errors.0.message`
+                - |-
+                  This field only needs to be set if the API returns a field in the HTTP response
+                  body to indicate auth errors.
+                  For example,
+                  if an API returns the field `errorMessage` with the value `Auth failed`,
+                  then set this field to `errorMessage`.
+                - |-
+                  This field only needs to be set if the API returns a field in the HTTP response
+                  body to indicate auth errors.
+                  For example,
+                  if an API returns the field `errorMessage` with the value `Auth failed`,
+                  then set this field to `errorMessage`.
+              examples:
+                - error.message
+                - '`errorMessage`'
+                - '`error`'
+                - '`errors.0.message`'
+            failValues:
+              type: array
+              items:
+                type: string
+              description: Values at `failPath` that indicate an auth failure.
+              examples:
+                - - access_denied
+                  - invalid_grant
+                  - unauthorized_client
+                - - error
+                  - invalid_request
+              x-celigo-ai-guidance:
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Array of strings.
+                  - Values correspond to provider-specific error indicators in the response body.
+                  - Used programmatically to trigger failure callbacks or error messages.
+                  - May be integrated with logging and monitoring systems for authentication failures.
+                - |-
+                  ## IMPORTANT NOTES:
+                  - Failure values are critical for robust error handling in OAuth2 flows.
+                  - Missing or incorrect failValues may result in unhandled authentication errors.
+                  - Should be aligned with the OAuth2 specification and provider documentation.
+                  - Case sensitivity may matter depending on the OAuth2 provider's response.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Array of one or more strings.
+                  - If any value matches the configured response body field, the response is treated as an auth failure.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Use exact values returned by the provider in the response body.
+                  - Provide each distinct value once (case sensitivity depends on the provider response).
+                - |-
+                  ## EXAMPLES:
+                  - ["access_denied", "invalid_grant", "unauthorized_client"]
+                  - ["error", "invalid_request"]
+                - |-
+                  Use this field to limit the exact values in the configured HTTP response body
+                  field that should be treated as authentication errors.
+                - |-
+                  UI behavior: to provide multiple values, enter a comma-separated list;
+                  in the API/config, represent this as an array of strings.
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Depends on the OAuth2 provider's error response definitions.
+                  - Works in conjunction with success and error handling mechanisms in the authentication flow.
+                  - Influences the overall OAuth2 authentication state management.
+                - |-
+                  Use this field to limit the exact values in the configured HTTP response body
+                  field that should be treated as authentication errors.
+                - |-
+                  UI behavior: to provide multiple values, enter a comma-separated list;
+                  in the API/config, represent this as an array of strings.
+                - |-
+                  Use this field to limit the exact values in the configured HTTP response body
+                  field that should be treated as authentication errors.
+                - |-
+                  UI behavior: to provide multiple values, enter a comma-separated list;
+                  in the API/config, represent this as an array of strings.
+            failStatusCode:
+              type: number
+              description: |-
+                HTTP status code indicating an auth error, if the provider
+                uses something other than 401.
+              x-celigo-ai-guidance:
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Leave unset if auth errors are returned as `401` (default behavior).
+                  - Set this if auth failures are returned using another status code (e.g., `400`).
+                - |-
+                  Set this field only if the system you are authenticating against uses an HTTP
+                  status code other than 401 to indicate an OAuth2 authentication error;
+                  for example,
+                  an API may return a generic `400` status code and use a field in the HTTP
+                  response body to indicate authentication errors.
+                - |-
+                  ## IMPORTANT NOTES:
+                  - Setting an inappropriate status code may lead to client confusion or security risks.
+                  - Some clients or intermediaries may behave differently depending on the status code.
+                  - The status code should be accompanied by a descriptive error message in the response body.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Determines the HTTP response status code sent upon OAuth2 failure.
+                  - Influences client-side error handling and user feedback.
+                  - Overrides default failure status codes if explicitly set.
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Depends on OAuth2 authentication and authorization failure events.
+                  - Works in conjunction with error response payloads and headers.
+                  - May interact with logging and monitoring systems for failure tracking.
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Must be an integer within the range of valid HTTP status codes (100–599).
+                  - Typically used in HTTP response status line.
+                  - Should be consistent with OAuth2 error response standards defined in RFC 6749.
+                - |-
+                  ## EXAMPLES:
+                  - 401
+                  - 400
+                - |-
+                  Set this field only if the system you are authenticating against uses an HTTP
+                  status code other than 401 to indicate an OAuth2 authentication error;
+                  for example,
+                  an API may return a generic `400` status code and use a field in the HTTP
+                  response body to indicate authentication errors.
+                - |-
+                  Set this field only if the system you are authenticating against uses an HTTP
+                  status code other than 401 to indicate an OAuth2 authentication error;
+                  for example,
+                  an API may return a generic `400` status code and use a field in the HTTP
+                  response body to indicate authentication errors.
+              examples:
+                - 403
+                - 401
+                - 400
+            useNewAuthFailSchema:
+              type: boolean
+              readOnly: true
+              description: Server-managed flag. Always `true` in current responses.
+            failures:
+              type: array
+              readOnly: true
+              description: |-
+                Server-computed auth-failure detection rules derived from
+                `failPath`, `failValues`, and `failStatusCode`. Present
+                only when those fields are configured.
+              items:
+                type: object
+                properties:
+                  statusCode:
+                    type: number
+                    description: HTTP status code triggering auth-failure detection.
+                  path:
+                    type: string
+                    description: Response body path checked for failure values.
+                  values:
+                    type: array
+                    items:
+                      type: string
+                    description: Values at `path` that indicate auth failure.
+            pkceCodeChallengeMethod:
+              type:
+                - string
+                - 'null'
+              enum:
+                - plain
+                - s256
+              x-enumDescriptions:
+                plain: Code verifier sent as-is (use only when required by the provider).
+                s256: SHA-256 hash of code verifier (recommended).
+              description: PKCE code challenge method (RFC 7636).
+              x-celigo-ai-guidance:
+                - PKCE code challenge method used for the OAuth 2.0 authorization code flow (RFC 7636).
+                - |-
+                  ## EXAMPLES:
+                  - `s256`
+                  - `plain`
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - `s256` is recommended.
+                  - `plain` should only be used if required by the provider.
+            useIClientFields:
+              type: boolean
+              description: |-
+                Use legacy iClient-specific fields instead of standard
+                OAuth 2.0 fields. For backward compatibility only.
+              x-celigo-ai-guidance:
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Overrides default OAuth2 client ID, secret, and token endpoint parameters with iClient equivalents.
+                  - May alter request payload structure during OAuth2 token exchanges.
+                  - Typically used in environments where legacy iClient authentication flows are required.
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Depends on the presence of iClient-specific OAuth2 fields in the configuration.
+                  - Affects OAuth2 token request and refresh processes.
+                - |-
+                  ## EXAMPLES:
+                  - true: Use iClient-specific fields for OAuth2 authentication.
+                  - false: Use standard OAuth2 fields for authentication.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Enable this flag only if integrating with legacy systems requiring iClient fields.
+                  - Ensure that the corresponding iClient fields are properly configured when this is enabled.
+                  - Validate compatibility with the OAuth2 provider before enabling this option.
+                - |-
+                  ## IMPORTANT NOTES:
+                  - Enabling this may affect interoperability with modern OAuth2 providers.
+                  - This setting is primarily for backward compatibility and may be deprecated in future releases.
+                  - Misconfiguration can lead to authentication failures.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - When set to true, the system uses iClient-specific OAuth2 fields for authentication.
+                  - When set to false or omitted, the system defaults to standard OAuth2 fields.
+                  - Influences how client credentials and tokens are processed during OAuth2 flows.
+                - |-
+                  Determines whether to utilize the legacy iClient-specific fields in the OAuth2
+                  configuration instead of the standard OAuth2 fields.
+                  This option is typically used for backward compatibility with systems or
+                  integrations that rely on the older iClient field structure.
+                - |-
+                  Determines whether to utilize the legacy iClient-specific fields in the OAuth2
+                  configuration instead of the standard OAuth2 fields.
+                  This option is typically used for backward compatibility with systems or
+                  integrations that rely on the older iClient field structure.
+                - |-
+                  Determines whether to utilize the legacy iClient-specific fields in the OAuth2
+                  configuration instead of the standard OAuth2 fields.
+                  This option is typically used for backward compatibility with systems or
+                  integrations that rely on the older iClient field structure.
+            username:
+              type: string
+              description: |-
+                Username for the password grant type.
+
+                Required when grantType is password.
+              x-celigo-ai-guidance:
+                - |-
+                  ## IMPORTANT NOTES:
+                  - The username must correspond to a valid user account in the OAuth2 provider.
+                  - Incorrect usernames will result in authentication failure.
+                  - Should be handled securely to prevent exposure of sensitive user information.
+                - |-
+                  The username used to authenticate the user within the OAuth2 authorization framework.
+                  This value typically represents the unique identifier assigned to the user by
+                  the authentication provider or system.
+                  It is required when performing resource owner password credentials grant or
+                  other flows that involve direct user authentication.
+                - |-
+                  ## EXAMPLES:
+                  - "johndoe"
+                  - "user@example.com"
+                  - "alice123"
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Data type: string
+                  - Maximum length may vary depending on the OAuth2 provider.
+                  - Should be URL-encoded if included in query parameters or request bodies.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Ensure the username is securely transmitted over HTTPS to protect user credentials.
+                  - Validate the format and existence of the username before processing authentication.
+                  - Avoid logging the username in plain text to maintain user privacy.
+                  - Support international characters if the authentication system allows.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Must be a non-empty string representing the user's login identifier.
+                  - Used in conjunction with the password to obtain an access token.
+                  - Should be case-sensitive depending on the authentication system.
+                  - Validated against the authentication provider's user database.
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Typically used alongside the `password` property in OAuth2 password grant flows.
+                  - Dependent on the OAuth2 server's user management and authentication mechanisms.
+                - |-
+                  The username used to authenticate the user within the OAuth2 authorization framework.
+                  This value typically represents the unique identifier assigned to the user by
+                  the authentication provider or system.
+                  It is required when performing resource owner password credentials grant or
+                  other flows that involve direct user authentication.
+                - |-
+                  The username used to authenticate the user within the OAuth2 authorization framework.
+                  This value typically represents the unique identifier assigned to the user by
+                  the authentication provider or system.
+                  It is required when performing resource owner password credentials grant or
+                  other flows that involve direct user authentication.
+              examples:
+                - service-account@example.com
+                - johndoe
+                - user@example.com
+                - alice123
+            password:
+              type: string
+              description: |-
+                Password for the password grant type. Returned masked
+                as `"******"`. Re-send that value on update to keep it; it is not preserved if omitted.
+              x-celigo-ai-guidance:
+                - |-
+                  Use `password` for the OAuth2 password value used with the password grant;
+                  this is the value provided to configure or update the iClient,
+                  is stored encrypted at rest internally in integrator.io (for example as
+                  `password_crypt`/`password_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a password is already set.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Provide the plain password value here to set/update it.
+                  - To keep the existing password unchanged during an update, omit this field (or keep `"******"` as-is if returned).
+                - |-
+                  Use `password` for the OAuth2 password value used with the password grant;
+                  this is the value provided to configure or update the iClient,
+                  is stored encrypted at rest internally in integrator.io (for example as
+                  `password_crypt`/`password_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a password is already set.
+                - |-
+                  Use `password` for the OAuth2 password value used with the password grant;
+                  this is the value provided to configure or update the iClient,
+                  is stored encrypted at rest internally in integrator.io (for example as
+                  `password_crypt`/`password_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a password is already set.
+            auth:
+              type: object
+              description: Authorization endpoint configuration.
+              x-celigo-ai-guidance:
+                - |-
+                  ## EXAMPLES:
+                  - Client credentials flow with client ID and client secret.
+                  - Authorization code flow with redirect URI and scopes.
+                  - Password grant with username and password fields.
+                  - Refresh token usage for renewing access tokens.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Ensure all required fields for the chosen OAuth 2.0 flow are included.
+                  - Securely store sensitive information like client secrets.
+                  - Validate the format and correctness of URLs and credentials.
+                  - Support common grant types such as authorization code, client credentials, and password.
+                  - Handle token expiration and refresh logic as needed.
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Depends on the OAuth 2.0 grant type specified elsewhere in the configuration.
+                  - Interacts with token endpoint URLs and scope definitions.
+                  - May be linked to client application registration details.
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Typically includes fields such as client_id, client_secret, token_url, scopes, grant_type.
+                  - May require encoding or encryption of credentials during transmission.
+                  - Supports standard OAuth 2.0 token request and response formats.
+                  - Should handle HTTP status codes and error responses from the authorization server.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Determines the authentication flow used in the OAuth 2.0 process.
+                  - Controls how credentials are presented to the authorization server.
+                  - Influences token acquisition and refresh mechanisms.
+                  - May include multiple authentication parameters depending on the grant type.
+                - |-
+                  ## IMPORTANT NOTES:
+                  - Sensitive data must be protected and not exposed in logs or error messages.
+                  - The authentication method must comply with OAuth 2.0 standards.
+                  - Misconfiguration can lead to failed authentication or security vulnerabilities.
+                  - Different OAuth 2.0 providers may require specific parameters or formats.
+                - |-
+                  Specifies the authentication method and credentials required for OAuth 2.0 authorization.
+                  This property defines how the client should authenticate with the authorization
+                  server to obtain an access token.
+                  It typically includes details such as client ID, client secret, token endpoint,
+                  scopes, and grant type.
+                - |-
+                  Specifies the authentication method and credentials required for OAuth 2.0 authorization.
+                  This property defines how the client should authenticate with the authorization
+                  server to obtain an access token.
+                  It typically includes details such as client ID, client secret, token endpoint,
+                  scopes, and grant type.
+                - |-
+                  Specifies the authentication method and credentials required for OAuth 2.0 authorization.
+                  This property defines how the client should authenticate with the authorization
+                  server to obtain an access token.
+                  It typically includes details such as client ID, client secret, token endpoint,
+                  scopes, and grant type.
+              properties:
+                uri:
+                  type: string
+                  description: Authorization endpoint URI.
+                  x-celigo-ai-guidance:
+                    - |-
+                      The URI endpoint where the OAuth 2.0 authorization server accepts authorization requests.
+                      This URI is used by clients to initiate the authorization flow,
+                      typically by redirecting the resource owner's user-agent to this address.
+                      It must be a valid HTTPS URL to ensure secure transmission of sensitive
+                      information such as authorization codes or tokens.
+                    - |-
+                      ## IMPORTANT NOTES:
+                      - The URI must be registered with the OAuth 2.0 provider and match the client configuration.
+                      - Using HTTP instead of HTTPS is not recommended due to security risks.
+                      - The URI should be stable and not change frequently to avoid client misconfigurations.
+                      - This endpoint is distinct from the token endpoint used to exchange authorization codes for tokens.
+                    - |-
+                      ## EXAMPLES:
+                      - https://authorization-server.com/oauth2/authorize
+                      - https://accounts.example.com/auth
+                      - https://login.provider.com/oauth2/auth
+                    - |-
+                      ## FIELD BEHAVIOR:
+                      - Serves as the entry point for the OAuth 2.0 authorization process.
+                      - Used by clients to request authorization from the resource owner.
+                      - Typically involves redirection of the user's browser to this URI.
+                      - Must support standard OAuth 2.0 authorization request parameters.
+                    - |-
+                      ## DEPENDENCY CHAIN:
+                      - Dependent on the OAuth 2.0 client configuration specifying this URI.
+                      - Used in conjunction with client_id, redirect_uri, response_type, and scope parameters.
+                      - Works alongside the token endpoint URI for completing the OAuth flow.
+                    - |-
+                      ## IMPLEMENTATION GUIDANCE:
+                      - Ensure the URI is an HTTPS endpoint to maintain security.
+                      - The endpoint should conform to OAuth 2.0 specifications for authorization endpoints.
+                      - Validate that the URI is reachable and correctly configured to handle authorization requests.
+                      - Include necessary query parameters as per OAuth 2.0 standards during requests.
+                    - |-
+                      ## TECHNICAL DETAILS:
+                      - Must be a valid, well-formed URL.
+                      - Should support GET requests with query parameters for authorization requests.
+                      - Typically responds with redirects (HTTP 302) to the redirect_uri with authorization codes or tokens.
+                      - Should implement security best practices such as TLS 1.2+ and proper CORS policies.
+                    - |-
+                      The URI endpoint where the OAuth 2.0 authorization server accepts authorization requests.
+                      This URI is used by clients to initiate the authorization flow,
+                      typically by redirecting the resource owner's user-agent to this address.
+                      It must be a valid HTTPS URL to ensure secure transmission of sensitive
+                      information such as authorization codes or tokens.
+                    - |-
+                      The URI endpoint where the OAuth 2.0 authorization server accepts authorization requests.
+                      This URI is used by clients to initiate the authorization flow,
+                      typically by redirecting the resource owner's user-agent to this address.
+                      It must be a valid HTTPS URL to ensure secure transmission of sensitive
+                      information such as authorization codes or tokens.
+                  examples:
+                    - https://accounts.google.com/o/oauth2/auth
+                    - https://authorization-server.com/oauth2/authorize
+                    - https://accounts.example.com/auth
+                    - https://login.provider.com/oauth2/auth
+                queryParameters:
+                  type: object
+                  description: |-
+                    Additional query parameters appended to the authorization
+                    URL. Stored encrypted (masked as `"****"` in responses).
+            token:
+              type: object
+              description: Token endpoint configuration.
+              x-celigo-ai-guidance:
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Usually a string encoded in JWT or opaque format.
+                  - Contains claims or metadata about the user and permissions.
+                  - Includes an expiration timestamp (exp claim in JWT).
+                  - May include scopes defining access rights.
+                  - Must conform to OAuth 2.0 and OpenID Connect standards where applicable.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Represents the credential used to access protected resources.
+                  - Must be included in API requests to authenticate the client.
+                  - Has an expiration time after which it becomes invalid.
+                  - May be a JWT or opaque string depending on the authorization server.
+                  - Should be securely stored and transmitted only over HTTPS.
+                - |-
+                  ## EXAMPLES:
+                  - "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
+                  - "2YotnFZFEjr1zCsicMWpAA"
+                  - "mF_9.B5f-4.1JqM"
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Ensure the token is included in the Authorization header as "Bearer {token}".
+                  - Validate the token's expiration and scope before use.
+                  - Refresh the token using a refresh token if supported and expired.
+                  - Handle token revocation and errors gracefully.
+                  - Avoid logging or exposing the token in client-side code or URLs.
+                - |-
+                  ## IMPORTANT NOTES:
+                  - The token must be kept confidential to prevent unauthorized access.
+                  - Tokens are typically short-lived to enhance security.
+                  - Different APIs may require tokens with specific scopes or claims.
+                  - Always use secure transport (HTTPS) when transmitting tokens.
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Obtained after successful OAuth 2.0 authorization or token exchange.
+                  - May depend on client credentials, authorization code, or refresh token.
+                  - Used in conjunction with the Authorization header in API requests.
+                - |-
+                  The access token issued by the OAuth 2.0 authorization server,
+                  used to authenticate and authorize API requests on behalf of the user or client.
+                  This token is typically a string representing a bearer token that must be
+                  included in the Authorization header of HTTP requests to access protected
+                  resources.
+                  It has a limited lifetime and scope,
+                  defining the permissions granted to the client.
+                - |-
+                  The access token issued by the OAuth 2.0 authorization server,
+                  used to authenticate and authorize API requests on behalf of the user or client.
+                  This token is typically a string representing a bearer token that must be
+                  included in the Authorization header of HTTP requests to access protected
+                  resources.
+                  It has a limited lifetime and scope,
+                  defining the permissions granted to the client.
+                - |-
+                  The access token issued by the OAuth 2.0 authorization server,
+                  used to authenticate and authorize API requests on behalf of the user or client.
+                  This token is typically a string representing a bearer token that must be
+                  included in the Authorization header of HTTP requests to access protected
+                  resources.
+                  It has a limited lifetime and scope,
+                  defining the permissions granted to the client.
+              properties:
+                method:
+                  type: string
+                  enum:
+                    - GET
+                    - POST
+                  x-enumDescriptions:
+                    GET: Token request sent as query parameters in a GET request; may expose sensitive data in URLs and logs
+                    POST: Token request sent as form data in a POST request; most common and recommended
+                  description: HTTP method for the token request.
+                  x-celigo-ai-guidance:
+                    - HTTP method used to call the OAuth 2.0 token endpoint.
+                uri:
+                  type: string
+                  description: Token endpoint URI.
+                  x-celigo-ai-guidance:
+                    - |-
+                      ## IMPLEMENTATION GUIDANCE:
+                      - Ensure the URI is a fully qualified HTTPS URL to maintain security.
+                      - Confirm the endpoint supports the OAuth 2.0 token exchange specification.
+                      - Validate the URI format before use to prevent runtime errors.
+                      - Document any additional headers or parameters required by the token endpoint.
+                    - |-
+                      ## FIELD BEHAVIOR:
+                      - Defines the exact URL to which token requests are made during the OAuth 2.0 flow.
+                      - Used by clients to exchange authorization grants or refresh tokens for access tokens.
+                      - Must support the OAuth 2.0 token request parameters and response formats.
+                      - Typically accessed via HTTP POST requests.
+                    - |-
+                      The URI (Uniform Resource Identifier) specifying the endpoint where the OAuth
+                      2.0 token request is sent to obtain an access token.
+                      This endpoint is responsible for authenticating the client and issuing tokens
+                      according to the OAuth 2.0 protocol.
+                      It must be a valid HTTPS URL to ensure secure transmission of sensitive credentials and tokens.
+                    - |-
+                      ## TECHNICAL DETAILS:
+                      - Must conform to URI syntax as per RFC 3986.
+                      - Typically accessed using HTTP POST with content type application/x-www-form-urlencoded.
+                      - Responses are usually JSON objects containing access tokens and metadata.
+                      - May support additional OAuth 2.0 extensions like PKCE or client authentication methods.
+                    - |-
+                      ## DEPENDENCY CHAIN:
+                      - Dependent on the OAuth 2.0 authorization server configuration.
+                      - Used in conjunction with client credentials and grant types.
+                      - Related to other OAuth 2.0 endpoints such as authorization URI and revocation URI.
+                    - |-
+                      ## IMPORTANT NOTES:
+                      - The URI must be reachable and responsive to token requests.
+                      - Using HTTP instead of HTTPS is discouraged due to security risks.
+                      - The token endpoint may require client authentication via headers or request body.
+                      - Changes to this URI can disrupt the OAuth 2.0 authentication flow.
+                    - |-
+                      ## EXAMPLES:
+                      - https://auth.example.com/oauth2/token
+                      - https://login.provider.com/oauth2/v1/token
+                      - https://api.service.com/oauth/token
+                    - |-
+                      The URI (Uniform Resource Identifier) specifying the endpoint where the OAuth
+                      2.0 token request is sent to obtain an access token.
+                      This endpoint is responsible for authenticating the client and issuing tokens
+                      according to the OAuth 2.0 protocol.
+                      It must be a valid HTTPS URL to ensure secure transmission of sensitive credentials and tokens.
+                    - |-
+                      The URI (Uniform Resource Identifier) specifying the endpoint where the OAuth
+                      2.0 token request is sent to obtain an access token.
+                      This endpoint is responsible for authenticating the client and issuing tokens
+                      according to the OAuth 2.0 protocol.
+                      It must be a valid HTTPS URL to ensure secure transmission of sensitive credentials and tokens.
+                  examples:
+                    - https://accounts.google.com/o/oauth2/token
+                    - https://auth.example.com/oauth2/token
+                    - https://login.provider.com/oauth2/v1/token
+                    - https://api.service.com/oauth/token
+                body:
+                  type: string
+                  description: |-
+                    Custom request body template for the token request.
+                    Supports Handlebars expressions.
+                  x-celigo-ai-guidance:
+                    - |-
+                      ## DEPENDENCY CHAIN:
+                      - Depends on the OAuth 2.0 grant type selected.
+                      - Relies on correct client credentials and authorization codes obtained from prior steps.
+                      - Works in conjunction with HTTP headers like Content-Type and Authorization.
+                    - |-
+                      ## TECHNICAL DETAILS:
+                      - Typically sent as application/x-www-form-urlencoded or application/json.
+                      - Must be included in the POST request to the token endpoint URL.
+                      - Parameters are case-sensitive and must match the OAuth 2.0 specification.
+                      - The server response depends on the correctness and completeness of the body content.
+                    - |-
+                      ## FIELD BEHAVIOR:
+                      - Contains the data sent in the HTTP request body during the token request.
+                      - Must include all required parameters based on the OAuth 2.0 grant type being used.
+                      - Often formatted as application/x-www-form-urlencoded or JSON, depending on the API requirements.
+                      - Is transmitted securely over HTTPS to protect sensitive information.
+                    - |-
+                      ## EXAMPLES:
+                      - grant_type=authorization_code&code=AUTH_CODE&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcallback&client_id=CLIENT_ID&client_secret=CLIENT_SECRET
+                      - { "grant_type": "refresh_token", "refresh_token": "REFRESH_TOKEN", "client_id": "CLIENT_ID" }
+                    - |-
+                      The body property represents the payload content sent in the HTTP request when
+                      obtaining an OAuth 2.0 token.
+                      It typically includes key-value pairs such as grant type, client credentials,
+                      authorization code, refresh token, and scope,
+                      formatted according to the OAuth 2.0 specification.
+                      This property is essential for conveying the necessary parameters to the token
+                      endpoint to successfully authenticate and receive an access token.
+                    - |-
+                      ## IMPORTANT NOTES:
+                      - The exact parameters required in the body depend on the OAuth 2.0 flow implemented (authorization code, client credentials, password, refresh token).
+                      - Sensitive information such as client_secret should be handled securely and never exposed in logs or client-side code.
+                      - The body must conform to the OAuth 2.0 specification and the authorization server's expectations.
+                    - |-
+                      ## IMPLEMENTATION GUIDANCE:
+                      - Ensure the body includes all mandatory fields such as grant_type, client_id, client_secret, code, redirect_uri, or refresh_token as applicable.
+                      - Use the correct content type header matching the body format.
+                      - Encode parameters properly to comply with URL encoding standards if using form-urlencoded format.
+                      - Validate the body content before sending to avoid malformed requests.
+                    - |-
+                      The body property represents the payload content sent in the HTTP request when
+                      obtaining an OAuth 2.0 token.
+                      It typically includes key-value pairs such as grant type, client credentials,
+                      authorization code, refresh token, and scope,
+                      formatted according to the OAuth 2.0 specification.
+                      This property is essential for conveying the necessary parameters to the token
+                      endpoint to successfully authenticate and receive an access token.
+                    - |-
+                      The body property represents the payload content sent in the HTTP request when
+                      obtaining an OAuth 2.0 token.
+                      It typically includes key-value pairs such as grant type, client credentials,
+                      authorization code, refresh token, and scope,
+                      formatted according to the OAuth 2.0 specification.
+                      This property is essential for conveying the necessary parameters to the token
+                      endpoint to successfully authenticate and receive an access token.
+                  examples:
+                    - grant_type=client_credentials&client_id={{{iClient.oauth2.clientId}}}
+                    - grant_type=authorization_code&code=AUTH_CODE&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcallback&client_id=CLIENT_ID&client_secret=CLIENT_SECRET
+                headers:
+                  description: |-
+                    Custom HTTP headers for the token request. Can be an
+                    array of `{name, value}` objects or a string.
+                  x-celigo-ai-guidance:
+                    - |-
+                      A collection of HTTP headers to include in the token request when obtaining an
+                      OAuth 2.0 access token.
+                      These headers allow customization of the request, such as setting content types,
+                      authorization credentials, or custom metadata required by the token endpoint.
+                      The headers should be specified as key-value pairs where the key is the header
+                      name and the value is the header content.
+                    - |-
+                      ## DEPENDENCY CHAIN:
+                      - Used in conjunction with oauth2.token.url and oauth2.token.body parameters.
+                      - May depend on client credentials or other authentication parameters.
+                      - Influences the HTTP request sent to the OAuth token endpoint.
+                    - |-
+                      ## FIELD BEHAVIOR:
+                      - Overrides or supplements default headers sent in the token request.
+                      - Supports multiple headers to be included simultaneously.
+                      - Headers are sent exactly as specified without modification.
+                      - Used primarily during the OAuth 2.0 token exchange process.
+                    - |-
+                      ## IMPLEMENTATION GUIDANCE:
+                      - Ensure header names are correctly capitalized as per HTTP standards.
+                      - Avoid including sensitive information unless required and secure.
+                      - Validate header values to conform to expected formats (e.g., content-type).
+                      - Use this field to add custom headers required by specific OAuth providers.
+                    - |-
+                      ## IMPORTANT NOTES:
+                      - Headers specified here apply only to the token request, not to other OAuth flows.
+                      - Conflicts with default headers may cause token request failures.
+                      - Sensitive headers should be handled securely to prevent leaks.
+                      - Some OAuth providers may require specific headers for successful authentication.
+                    - |-
+                      ## TECHNICAL DETAILS:
+                      - Represented as a map/dictionary of string keys and string values.
+                      - Transmitted as HTTP headers in the token request POST or GET.
+                      - Supports standard HTTP header syntax and conventions.
+                      - Must comply with OAuth 2.0 token endpoint requirements and HTTP protocol.
+                    - |-
+                      ## EXAMPLES:
+                      - Authorization: Basic base64(client_id:client_secret)
+                      - Content-Type: application/x-www-form-urlencoded
+                      - Custom-Header: customValue
+                    - |-
+                      A collection of HTTP headers to include in the token request when obtaining an
+                      OAuth 2.0 access token.
+                      These headers allow customization of the request, such as setting content types,
+                      authorization credentials, or custom metadata required by the token endpoint.
+                      The headers should be specified as key-value pairs where the key is the header
+                      name and the value is the header content.
+                    - |-
+                      A collection of HTTP headers to include in the token request when obtaining an
+                      OAuth 2.0 access token.
+                      These headers allow customization of the request, such as setting content types,
+                      authorization credentials, or custom metadata required by the token endpoint.
+                      The headers should be specified as key-value pairs where the key is the header
+                      name and the value is the header content.
+                  oneOf:
+                    - type: array
+                      items:
+                        type: object
+                        properties:
+                          name:
+                            type: string
+                            description: Name of the HTTP header to send.
+                            examples:
+                              - Content-Type
+                          value:
+                            type: string
+                            description: Value of the HTTP header to send.
+                            examples:
+                              - application/x-www-form-urlencoded
+                    - type: string
+                    - type: 'null'
+            refresh:
+              type: object
+              description: Refresh token endpoint configuration.
+              x-celigo-ai-guidance:
+                - Indicates whether the OAuth2 refresh token flow is supported/enabled.
+                - |-
+                  ## EXAMPLES:
+                  - `true`
+                  - `false`
+              properties:
+                method:
+                  type: string
+                  enum:
+                    - GET
+                    - POST
+                  x-enumDescriptions:
+                    GET: Refresh request sent as query parameters in a GET request.
+                    POST: Refresh request sent as form data in a POST request (recommended).
+                  description: HTTP method for the refresh token request.
+                  examples:
+                    - POST
+                    - GET
+                  x-celigo-ai-guidance:
+                    - |-
+                      ## IMPLEMENTATION GUIDANCE:
+                      - Typically set to POST for secure transmission of sensitive data.
+                      - Ensure the chosen method aligns with the OAuth 2.0 server's requirements.
+                      - Validate that the client library or HTTP client supports the specified method.
+                      - Consider security implications of using GET, as parameters may be exposed in URLs.
+                    - |-
+                      ## EXAMPLES:
+                      - POST
+                      - GET
+                    - |-
+                      ## IMPORTANT NOTES:
+                      - Using GET may expose refresh tokens in URLs, which can be logged or cached.
+                      - Some OAuth 2.0 servers may only support POST for token refresh requests.
+                      - The method must be consistent with the server's expected protocol to avoid errors.
+                    - |-
+                      ## DEPENDENCY CHAIN:
+                      - Depends on the OAuth 2.0 server's token endpoint configuration.
+                      - Interacts with the refresh token and client credentials parameters.
+                      - Influences the HTTP headers and body formatting of the request.
+                    - |-
+                      Specifies the HTTP method to be used when making the refresh token request in
+                      the OAuth 2.0 authentication flow.
+                      This method determines how the refresh token and related parameters are sent to
+                      the authorization server to obtain a new access token.
+                      Common HTTP methods include POST and GET,
+                      with POST being the most widely used due to its ability to securely transmit
+                      data in the request body.
+                    - |-
+                      ## FIELD BEHAVIOR:
+                      - Defines the HTTP verb for the token refresh request.
+                      - Influences how parameters are encoded and transmitted.
+                      - Affects compatibility with different OAuth 2.0 server implementations.
+                    - |-
+                      ## TECHNICAL DETAILS:
+                      - HTTP methods are case-insensitive but typically uppercase.
+                      - POST requests send parameters in the request body using application/x-www-form-urlencoded format.
+                      - GET requests send parameters as URL query parameters.
+                      - Proper handling of HTTP status codes and responses is required based on the method used.
+                    - |-
+                      Specifies the HTTP method to be used when making the refresh token request in
+                      the OAuth 2.0 authentication flow.
+                      This method determines how the refresh token and related parameters are sent to
+                      the authorization server to obtain a new access token.
+                      Common HTTP methods include POST and GET,
+                      with POST being the most widely used due to its ability to securely transmit
+                      data in the request body.
+                    - |-
+                      Specifies the HTTP method to be used when making the refresh token request in
+                      the OAuth 2.0 authentication flow.
+                      This method determines how the refresh token and related parameters are sent to
+                      the authorization server to obtain a new access token.
+                      Common HTTP methods include POST and GET,
+                      with POST being the most widely used due to its ability to securely transmit
+                      data in the request body.
+                uri:
+                  type: string
+                  description: Refresh token endpoint URI.
+                  x-celigo-ai-guidance:
+                    - |-
+                      Refresh token endpoint URI used to exchange a refresh token for a new access
+                      token (RFC 6749 Section 6).
+                    - |-
+                      ## EXAMPLES:
+                      - https://auth.example.com/oauth2/token
+                      - https://login.provider.com/oauth2/v1/token
+                    - |-
+                      Refresh token endpoint URI used to exchange a refresh token for a new access
+                      token (RFC 6749 Section 6).
+                    - |-
+                      Refresh token endpoint URI used to exchange a refresh token for a new access
+                      token (RFC 6749 Section 6).
+                  examples:
+                    - https://accounts.google.com/o/oauth2/token
+                    - https://auth.example.com/oauth2/token
+                    - https://login.provider.com/oauth2/v1/token
+                body:
+                  type: string
+                  description: |-
+                    Custom request body template for the refresh request.
+                    Supports Handlebars expressions.
+                  x-celigo-ai-guidance:
+                    - |-
+                      The body of the HTTP request used to refresh an OAuth 2.0 access token.
+                      This typically includes parameters such as the refresh token,
+                      client credentials, grant type,
+                      and any additional required fields as specified by the OAuth 2.0 protocol.
+                      The body must be formatted according to the content type expected by the authorization server,
+                      commonly application/x-www-form-urlencoded.
+                    - |-
+                      ## EXAMPLES:
+                      - grant_type=refresh_token&refresh_token=xyz123&client_id=abc&client_secret=secret
+                      - grant_type=refresh_token&refresh_token=def456
+                    - |-
+                      ## FIELD BEHAVIOR:
+                      - Contains all necessary parameters to request a new access token using a refresh token.
+                      - Must include the "grant_type" parameter set to "refresh_token".
+                      - Should include the "refresh_token" parameter with the valid refresh token value.
+                      - May include client authentication parameters such as "client_id" and "client_secret" if required.
+                      - Sent as the payload of the HTTP POST request to the token endpoint.
+                    - |-
+                      ## IMPORTANT NOTES:
+                      - The refresh token must be valid and not expired or revoked.
+                      - The authorization server may require client authentication in the body or via other means.
+                      - The content type header must match the format of the body (e.g., application/x-www-form-urlencoded).
+                      - Improper formatting or missing parameters will result in an error response from the server.
+                    - |-
+                      ## TECHNICAL DETAILS:
+                      - Typically sent as an HTTP POST request body.
+                      - Commonly uses application/x-www-form-urlencoded encoding.
+                      - Parameters include "grant_type", "refresh_token", and optionally "client_id" and "client_secret".
+                      - Must comply with OAuth 2.0 RFC 6749 Section 6 for token refresh requests.
+                    - |-
+                      ## IMPLEMENTATION GUIDANCE:
+                      - Ensure the body is properly URL-encoded if using application/x-www-form-urlencoded content type.
+                      - Validate that all required parameters are present before sending the request.
+                      - Follow the OAuth 2.0 specification (RFC 6749) for the exact parameter names and values.
+                      - Handle any additional parameters required by the specific OAuth provider.
+                      - Securely handle sensitive information such as client secrets and refresh tokens.
+                    - |-
+                      ## DEPENDENCY CHAIN:
+                      - Depends on having a valid refresh token obtained from a previous authorization.
+                      - Requires knowledge of the OAuth 2.0 token endpoint URL.
+                      - May depend on client credentials if the server requires client authentication.
+                      - Relies on the correct grant_type parameter to indicate a refresh token request.
+                    - |-
+                      The body of the HTTP request used to refresh an OAuth 2.0 access token.
+                      This typically includes parameters such as the refresh token,
+                      client credentials, grant type,
+                      and any additional required fields as specified by the OAuth 2.0 protocol.
+                      The body must be formatted according to the content type expected by the authorization server,
+                      commonly application/x-www-form-urlencoded.
+                    - |-
+                      The body of the HTTP request used to refresh an OAuth 2.0 access token.
+                      This typically includes parameters such as the refresh token,
+                      client credentials, grant type,
+                      and any additional required fields as specified by the OAuth 2.0 protocol.
+                      The body must be formatted according to the content type expected by the authorization server,
+                      commonly application/x-www-form-urlencoded.
+                  examples:
+                    - grant_type=refresh_token&refresh_token={{{iClient.oauth2.refreshToken}}}
+                    - grant_type=refresh_token&refresh_token=xyz123&client_id=abc&client_secret=secret
+                    - grant_type=refresh_token&refresh_token=def456
+                headers:
+                  description: |-
+                    Custom HTTP headers for the refresh token request.
+                    Can be an array of `{name, value}` objects or a string.
+                  x-celigo-ai-guidance:
+                    - |-
+                      ## TECHNICAL DETAILS:
+                      - Represented as a map/dictionary of string keys and string values.
+                      - Translated into HTTP headers in the outgoing POST request to the token endpoint.
+                      - Must comply with HTTP/1.1 header field syntax and encoding rules.
+                      - Typically sent over HTTPS to ensure confidentiality and integrity.
+                    - |-
+                      ## FIELD BEHAVIOR:
+                      - Accepts key-value pairs representing HTTP header names and their corresponding values.
+                      - Headers are included in the HTTP request sent to the token endpoint during the refresh token flow.
+                      - Overrides or supplements default headers set by the client or HTTP library.
+                      - Supports standard and custom headers as required by the OAuth 2.0 provider.
+                    - |-
+                      A collection of HTTP headers to include in the OAuth 2.0 refresh token request.
+                      These headers can be used to pass additional metadata,
+                      authentication information,
+                      or custom parameters required by the authorization server during the token refresh process.
+                      Typically, this may include headers such as `Content-Type`, `Authorization`,
+                      or any other custom headers mandated by the API specification.
+                    - |-
+                      ## EXAMPLES:
+                      - `Content-Type: application/x-www-form-urlencoded`
+                      - `Authorization: Basic base64(client_id:client_secret)`
+                      - `Custom-Header: customValue`
+                    - |-
+                      ## IMPLEMENTATION GUIDANCE:
+                      - Ensure header names are correctly capitalized and conform to HTTP standards.
+                      - Avoid including sensitive information in headers unless required and secured.
+                      - Validate header values to prevent injection or formatting errors.
+                      - Use this field to add headers like `Authorization` if the token endpoint requires client authentication via headers.
+                      - Do not duplicate headers that are automatically managed by the HTTP client unless overriding is necessary.
+                    - |-
+                      ## IMPORTANT NOTES:
+                      - Headers specified here apply only to the refresh token request, not to other OAuth 2.0 flows.
+                      - Misconfigured headers can cause token refresh failures or security issues.
+                      - Some OAuth 2.0 servers require specific headers for token refresh requests; consult the provider's documentation.
+                      - Sensitive headers should be handled securely to prevent exposure.
+                    - |-
+                      ## DEPENDENCY CHAIN:
+                      - Used in conjunction with `oauth2.refresh.tokenUrl` to make the refresh token request.
+                      - May depend on client authentication method specified elsewhere in the OAuth 2.0 configuration.
+                      - Interacts with HTTP client settings that manage default headers.
+                    - |-
+                      A collection of HTTP headers to include in the OAuth 2.0 refresh token request.
+                      These headers can be used to pass additional metadata,
+                      authentication information,
+                      or custom parameters required by the authorization server during the token refresh process.
+                      Typically, this may include headers such as `Content-Type`, `Authorization`,
+                      or any other custom headers mandated by the API specification.
+                    - |-
+                      A collection of HTTP headers to include in the OAuth 2.0 refresh token request.
+                      These headers can be used to pass additional metadata,
+                      authentication information,
+                      or custom parameters required by the authorization server during the token refresh process.
+                      Typically, this may include headers such as `Content-Type`, `Authorization`,
+                      or any other custom headers mandated by the API specification.
+                  oneOf:
+                    - type: array
+                      items:
+                        type: object
+                        properties:
+                          name:
+                            type: string
+                            description: Name of the HTTP header to send.
+                            examples:
+                              - Content-Type
+                          value:
+                            type: string
+                            description: Value of the HTTP header to send.
+                            examples:
+                              - application/x-www-form-urlencoded
+                    - type: string
+                    - type: 'null'
+            revoke:
+              type: object
+              description: Token revocation endpoint configuration (RFC 7009).
+              x-celigo-ai-guidance:
+                - |-
+                  ## EXAMPLES:
+                  - `true`
+                  - `false`
+                - Indicates whether the OAuth2 token revocation endpoint is supported/enabled (RFC 7009).
+              properties:
+                uri:
+                  type: string
+                  description: Revocation endpoint URI.
+                  x-celigo-ai-guidance:
+                    - |-
+                      ## IMPORTANT NOTES:
+                      - The revocation URI is distinct from the authorization and token endpoints.
+                      - Proper implementation of token revocation enhances security by allowing clients to invalidate tokens when no longer needed.
+                      - Failure to provide a valid revocation URI may prevent clients from properly revoking tokens.
+                    - |-
+                      ## FIELD BEHAVIOR:
+                      - Accepts a single string value representing the revocation endpoint URL.
+                      - Used by clients to send HTTP POST requests to revoke tokens.
+                      - Should support standard OAuth 2.0 token revocation parameters as per RFC 7009.
+                      - Must be reachable and respond appropriately to revocation requests.
+                    - |-
+                      The URI endpoint where OAuth 2.0 token revocation requests are sent.
+                      This URI is used by clients to invalidate access or refresh tokens,
+                      ensuring they can no longer be used for authentication or authorization.
+                      It must be a valid HTTPS URL to guarantee secure transmission of sensitive token data.
+                    - |-
+                      ## TECHNICAL DETAILS:
+                      - Typically accessed via HTTP POST with parameters such as token and token_type_hint.
+                      - Must handle authentication of the client making the revocation request.
+                      - Should return appropriate HTTP status codes indicating success or failure of revocation.
+                    - |-
+                      ## IMPLEMENTATION GUIDANCE:
+                      - Ensure the URI uses HTTPS to protect token data during transmission.
+                      - The endpoint should conform to OAuth 2.0 Token Revocation specification (RFC 7009).
+                      - Validate the URI format to prevent misconfiguration.
+                      - Document any additional headers or authentication required by the revocation endpoint.
+                    - |-
+                      ## DEPENDENCY CHAIN:
+                      - Depends on the OAuth 2.0 authorization server configuration.
+                      - Related to the OAuth 2.0 token endpoint and authorization endpoint.
+                      - Used in conjunction with client credentials and tokens issued by the authorization server.
+                    - |-
+                      ## EXAMPLES:
+                      - https://auth.example.com/oauth2/revoke
+                      - https://api.service.com/oauth2/token/revoke
+                    - |-
+                      The URI endpoint where OAuth 2.0 token revocation requests are sent.
+                      This URI is used by clients to invalidate access or refresh tokens,
+                      ensuring they can no longer be used for authentication or authorization.
+                      It must be a valid HTTPS URL to guarantee secure transmission of sensitive token data.
+                    - |-
+                      The URI endpoint where OAuth 2.0 token revocation requests are sent.
+                      This URI is used by clients to invalidate access or refresh tokens,
+                      ensuring they can no longer be used for authentication or authorization.
+                      It must be a valid HTTPS URL to guarantee secure transmission of sensitive token data.
+                  examples:
+                    - https://accounts.google.com/o/oauth2/revoke
+                    - https://auth.example.com/oauth2/revoke
+                    - https://api.service.com/oauth2/token/revoke
+                body:
+                  type: string
+                  description: Custom request body for the revocation request.
+                  x-celigo-ai-guidance:
+                    - |-
+                      The request body containing the parameters required to revoke an OAuth 2.0 token.
+                      This typically includes the token to be revoked and may also specify the token
+                      type hint to indicate whether the token is an access token or a refresh token.
+                      The body must be formatted according to the application/x-www-form-urlencoded
+                      MIME type as per the OAuth 2.0 Token Revocation specification (RFC 7009).
+                    - |-
+                      ## IMPORTANT NOTES:
+                      - The token parameter is mandatory; omission will result in an error.
+                      - The token_type_hint is optional but recommended to improve server processing.
+                      - Revocation requests must be authenticated as per the authorization server's requirements.
+                      - Revoking a token invalidates it immediately, preventing further use.
+                      - The body must not contain any additional parameters beyond those defined by the specification.
+                    - |-
+                      ## DEPENDENCY CHAIN:
+                      - Depends on the OAuth 2.0 token revocation endpoint being correctly configured.
+                      - Requires the client to have a valid token to revoke.
+                      - May depend on client authentication credentials included in the request headers.
+                      - The server's response depends on the correctness of the body parameters.
+                    - |-
+                      ## TECHNICAL DETAILS:
+                      - Content-Type: application/x-www-form-urlencoded
+                      - Encoding: URL-encoded key-value pairs
+                      - Parameters:
+                        - token (string, required): The token to be revoked.
+                        - token_type_hint (string, optional): A hint about the type of the token.
+                      - HTTP Method: POST
+                      - Conforms to RFC 7009 (OAuth 2.0 Token Revocation)
+                    - |-
+                      ## EXAMPLES:
+                      - token=SlAV32hkKG
+                      - token=34xkj23j4k23&token_type_hint=refresh_token
+                      - token=abcdef123456&token_type_hint=access_token
+                    - |-
+                      ## FIELD BEHAVIOR:
+                      - Contains key-value pairs representing the token and optional token type hint.
+                      - Must be included in the HTTP POST request to the token revocation endpoint.
+                      - Parameters are URL-encoded in the request body.
+                      - Used to instruct the authorization server to invalidate a specific token.
+                    - |-
+                      ## IMPLEMENTATION GUIDANCE:
+                      - Ensure the body includes the "token" parameter with the token string to revoke.
+                      - Optionally include "token_type_hint" with values like "access_token" or "refresh_token" to assist the server.
+                      - Use application/x-www-form-urlencoded content type for the request.
+                      - Validate that the token parameter is present and correctly formatted before sending.
+                      - Handle server responses to confirm successful revocation or errors.
+                    - |-
+                      The request body containing the parameters required to revoke an OAuth 2.0 token.
+                      This typically includes the token to be revoked and may also specify the token
+                      type hint to indicate whether the token is an access token or a refresh token.
+                      The body must be formatted according to the application/x-www-form-urlencoded
+                      MIME type as per the OAuth 2.0 Token Revocation specification (RFC 7009).
+                    - |-
+                      The request body containing the parameters required to revoke an OAuth 2.0 token.
+                      This typically includes the token to be revoked and may also specify the token
+                      type hint to indicate whether the token is an access token or a refresh token.
+                      The body must be formatted according to the application/x-www-form-urlencoded
+                      MIME type as per the OAuth 2.0 Token Revocation specification (RFC 7009).
+                  examples:
+                    - token={{{iClient.oauth2.accessToken}}}
+                    - token=SlAV32hkKG
+                    - token=34xkj23j4k23&token_type_hint=refresh_token
+                    - token=abcdef123456&token_type_hint=access_token
+                headers:
+                  description: |-
+                    Custom HTTP headers for the revocation request.
+                    Can be an array of `{name, value}` objects or a string.
+                  x-celigo-ai-guidance:
+                    - |-
+                      ## FIELD BEHAVIOR:
+                      - Accepts key-value pairs representing HTTP header names and their corresponding values.
+                      - Headers are included in the HTTP request sent to the token revocation endpoint.
+                      - Can override default headers or add custom headers as needed.
+                      - Supports standard headers like `Authorization`, `Content-Type`, and custom headers.
+                    - |-
+                      ## DEPENDENCY CHAIN:
+                      - Used in conjunction with the `oauth2.revoke.url` property specifying the revocation endpoint.
+                      - May depend on `oauth2.revoke.method` to determine the HTTP method used.
+                      - Works alongside other OAuth 2.0 configuration properties to complete the revocation flow.
+                    - |-
+                      ## TECHNICAL DETAILS:
+                      - Represented as a map or dictionary of string key-value pairs.
+                      - Incorporated into the HTTP request headers when making the revocation call.
+                      - Must comply with HTTP header syntax and encoding rules.
+                      - Typically used in HTTP POST requests to the revocation endpoint.
+                    - |-
+                      ## IMPORTANT NOTES:
+                      - Headers specified here will be sent only during the token revocation request.
+                      - Misconfigured headers may cause the revocation request to fail.
+                      - This field does not affect other OAuth 2.0 requests such as token acquisition or introspection.
+                    - |-
+                      A collection of HTTP headers to include in the token revocation request for OAuth 2.0.
+                      These headers can be used to specify additional metadata such as content type,
+                      authorization credentials, custom client information,
+                      or any other required HTTP headers that the revocation endpoint expects.
+                      This allows for greater flexibility and control over the HTTP request sent to
+                      the authorization server when revoking tokens.
+                    - |-
+                      ## IMPLEMENTATION GUIDANCE:
+                      - Ensure header names are correctly capitalized and conform to HTTP standards.
+                      - Avoid including sensitive information in headers unless required and secure.
+                      - Validate header values to prevent injection or formatting errors.
+                      - Use this field to comply with specific OAuth 2.0 server requirements for token revocation.
+                    - |-
+                      ## EXAMPLES:
+                      - `Authorization: Basic Y2xpZW50SWQ6Y2xpZW50U2VjcmV0`
+                      - `Content-Type: application/x-www-form-urlencoded`
+                      - `X-Custom-Header: customValue`
+                    - |-
+                      A collection of HTTP headers to include in the token revocation request for OAuth 2.0.
+                      These headers can be used to specify additional metadata such as content type,
+                      authorization credentials, custom client information,
+                      or any other required HTTP headers that the revocation endpoint expects.
+                      This allows for greater flexibility and control over the HTTP request sent to
+                      the authorization server when revoking tokens.
+                    - |-
+                      A collection of HTTP headers to include in the token revocation request for OAuth 2.0.
+                      These headers can be used to specify additional metadata such as content type,
+                      authorization credentials, custom client information,
+                      or any other required HTTP headers that the revocation endpoint expects.
+                      This allows for greater flexibility and control over the HTTP request sent to
+                      the authorization server when revoking tokens.
+                  oneOf:
+                    - type: array
+                      items:
+                        type: object
+                        properties:
+                          name:
+                            type: string
+                            description: Name of the HTTP header to send.
+                            examples:
+                              - Content-Type
+                          value:
+                            type: string
+                            description: Value of the HTTP header to send.
+                            examples:
+                              - application/x-www-form-urlencoded
+                    - type: string
+                    - type: 'null'
+            unencrypted:
+              type: object
+              description: |-
+                Non-sensitive key-value pairs accessible via iClient
+                references (e.g. email, account ID, role).
+              x-celigo-ai-guidance:
+                - |-
+                  ## EXAMPLES:
+                  - `{"email":"my_email@company.com", "accountId": "8675301", "role":"admin"}`
+                - |-
+                  Store all non-sensitive fields required by your imports and exports to access
+                  the app you are connecting to;
+                  these values can be referenced by resources within integrator.io through the iClient.
+                - |-
+                  ## IMPORTANT NOTES:
+                  - Only store non-sensitive values here (safe to store unencrypted).
+                  - Use `encrypted` for secrets (passwords, tokens, keys).
+                - |-
+                  Store all non-sensitive fields required by your imports and exports to access
+                  the app you are connecting to;
+                  these values can be referenced by resources within integrator.io through the iClient.
+                - |-
+                  Store all non-sensitive fields required by your imports and exports to access
+                  the app you are connecting to;
+                  these values can be referenced by resources within integrator.io through the iClient.
+            encrypted:
+              type:
+                - object
+                - string
+              description: |-
+                Sensitive key-value pairs stored with AES-256 encryption.
+                Send an object when writing; API responses mask the whole
+                value as the string `"******"`.
+              x-celigo-ai-guidance:
+                - |-
+                  ## EXAMPLES:
+                  - `{"password":"celigorocks"}`
+                  - `{"token":"x7if4nkovhgr63ghp"}`
+                - |-
+                  ## IMPORTANT NOTES:
+                  - Use this for secrets (passwords, tokens, keys).
+                  - Values may be masked (e.g., `"******"`) in API responses once stored.
+                - |-
+                  Store all **sensitive** fields required by your imports and exports to access
+                  the app you are connecting to;
+                  these values are stored with **AES-256 encryption** and other layers of
+                  protection to keep your data safe,
+                  and can be referenced by resources within integrator.io through the iClient.
+                - |-
+                  Store all **sensitive** fields required by your imports and exports to access
+                  the app you are connecting to;
+                  these values are stored with **AES-256 encryption** and other layers of
+                  protection to keep your data safe,
+                  and can be referenced by resources within integrator.io through the iClient.
+                - |-
+                  Store all **sensitive** fields required by your imports and exports to access
+                  the app you are connecting to;
+                  these values are stored with **AES-256 encryption** and other layers of
+                  protection to keep your data safe,
+                  and can be referenced by resources within integrator.io through the iClient.
+        netsuite:
+          type: object
+          description: NetSuite token-based authentication credentials.
+          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.
+          properties:
+            consumerKey:
+              type: string
+              description: |-
+                NetSuite consumer key. Returned masked as `"******"`.
+                Re-send that value on update to keep it; it is not preserved if omitted.
+              x-celigo-ai-guidance:
+                - |-
+                  Set the NetSuite consumer key value used for authentication;
+                  provide this value to configure or update the iClient.
+                  Internally,
+                  integrator.io stores this value encrypted at rest (for example as
+                  `consumerKey_crypt`/`consumerKey_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a value is already set.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Provide the plaintext consumer key here to set/update it.
+                  - To keep the existing value unchanged during an update, omit this field (or keep `"******"` as-is if returned).
+                - |-
+                  Set the NetSuite consumer key value used for authentication;
+                  provide this value to configure or update the iClient.
+                  Internally,
+                  integrator.io stores this value encrypted at rest (for example as
+                  `consumerKey_crypt`/`consumerKey_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a value is already set.
+                - |-
+                  Set the NetSuite consumer key value used for authentication;
+                  provide this value to configure or update the iClient.
+                  Internally,
+                  integrator.io stores this value encrypted at rest (for example as
+                  `consumerKey_crypt`/`consumerKey_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a value is already set.
+            consumerSecret:
+              type: string
+              description: |-
+                NetSuite consumer secret. Returned masked as `"******"`.
+                Re-send that value on update to keep it; it is not preserved if omitted.
+              x-celigo-ai-guidance:
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Provide the plaintext consumer secret here to set/update it.
+                  - To keep the existing value unchanged during an update, omit this field (or keep `"******"` as-is if returned).
+                - |-
+                  The NetSuite consumer secret value used for authentication;
+                  provide this value to configure or update the iClient.
+                  Internally,
+                  integrator.io stores this value encrypted at rest (for example as
+                  `consumerSecret_crypt`/`consumerSecret_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a value is already set.
+                - |-
+                  The NetSuite consumer secret value used for authentication;
+                  provide this value to configure or update the iClient.
+                  Internally,
+                  integrator.io stores this value encrypted at rest (for example as
+                  `consumerSecret_crypt`/`consumerSecret_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a value is already set.
+                - |-
+                  The NetSuite consumer secret value used for authentication;
+                  provide this value to configure or update the iClient.
+                  Internally,
+                  integrator.io stores this value encrypted at rest (for example as
+                  `consumerSecret_crypt`/`consumerSecret_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a value is already set.
+        salesforce:
+          type: object
+          description: Salesforce authentication credentials.
+          x-celigo-ai-guidance:
+            - |-
+              ## FIELD BEHAVIOR:
+              - Holds all necessary information to authenticate and communicate with Salesforce services.
+              - Used to configure API calls for data retrieval, updates, and other Salesforce operations.
+              - May include nested objects or fields such as client ID, client secret, access tokens, instance URLs, and API versions.
+            - |-
+              ## EXAMPLES:
+              - An object containing OAuth credentials: client_id, client_secret, refresh_token, and instance_url.
+              - Configuration specifying API version and endpoint URLs.
+              - JSON structure with nested authentication and connection parameters.
+            - |-
+              ## IMPORTANT NOTES:
+              - Proper error handling should be implemented for authentication failures or API call errors.
+              - Salesforce API limits and quotas should be considered when designing integration logic.
+              - Secure handling of credentials is critical to prevent unauthorized access.
+              - The structure and required fields may vary depending on the Salesforce API version and authentication method used.
+            - |-
+              ## IMPLEMENTATION GUIDANCE:
+              - Ensure sensitive information like client secrets and access tokens are securely stored and transmitted.
+              - Validate the presence and correctness of required fields before attempting Salesforce integration.
+              - Support token refresh mechanisms if applicable to maintain session validity.
+              - Allow configuration flexibility to support different Salesforce environments (e.g., sandbox, production).
+            - |-
+              ## DEPENDENCY CHAIN:
+              - Dependent on Salesforce authentication mechanisms (OAuth 2.0, username-password flow, etc.).
+              - Relies on network connectivity to Salesforce endpoints.
+              - May depend on external libraries or SDKs for Salesforce API interaction.
+            - |-
+              Configuration settings and credentials required to integrate with Salesforce,
+              enabling seamless data synchronization and interaction with Salesforce APIs.
+              This property typically includes authentication details, API endpoints,
+              and any necessary parameters for establishing a secure connection to a Salesforce instance.
+            - |-
+              ## TECHNICAL DETAILS:
+              - Typically involves OAuth 2.0 tokens or username-password credentials.
+              - Uses HTTPS for secure communication with Salesforce REST or SOAP APIs.
+              - May include refresh token logic to maintain long-term access.
+              - Supports configuration of API versioning to align with Salesforce API changes.
+            - |-
+              Configuration settings and credentials required to integrate with Salesforce,
+              enabling seamless data synchronization and interaction with Salesforce APIs.
+              This property typically includes authentication details, API endpoints,
+              and any necessary parameters for establishing a secure connection to a Salesforce instance.
+            - |-
+              Configuration settings and credentials required to integrate with Salesforce,
+              enabling seamless data synchronization and interaction with Salesforce APIs.
+              This property typically includes authentication details, API endpoints,
+              and any necessary parameters for establishing a secure connection to a Salesforce instance.
+          properties:
+            clientId:
+              type: string
+              description: Salesforce connected app client ID.
+              x-celigo-ai-guidance:
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Obtain this value from the Salesforce connected app configuration.
+                  - Store securely and avoid exposing it in client-side code.
+                  - Validate the format to ensure it matches Salesforce client ID patterns.
+                  - Use in conjunction with clientSecret for authentication.
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Dependent on the Salesforce connected app setup.
+                  - Works alongside clientSecret, redirectUri, and OAuth tokens.
+                  - Required for generating access tokens.
+                - |-
+                  The unique identifier assigned to a client application by Salesforce during the
+                  OAuth client registration process.
+                  This ID is used to authenticate the client when making API requests and
+                  establishing a secure connection with Salesforce services.
+                  It is essential for enabling authorized access to Salesforce resources on behalf
+                  of the client application.
+                - |-
+                  ## EXAMPLES:
+                  - "3MVG9d6T2QxX9z5l7Y8P0qR1sT2uVwXyZAbCdEfGhIjKlMnOpQrStUvWxYz123456"
+                  - "1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef"
+                - |-
+                  ## IMPORTANT NOTES:
+                  - The clientId alone does not grant access; it must be paired with appropriate credentials and tokens.
+                  - Changing the clientId requires updating all integrations using it.
+                  - Keep the clientId confidential to prevent unauthorized access.
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Typically a 40-character alphanumeric string.
+                  - Assigned by Salesforce upon connected app creation.
+                  - Used in HTTP headers or request parameters during OAuth flows.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Must be a non-empty string.
+                  - Used as part of the OAuth authentication flow.
+                  - Typically remains constant for a given client application.
+                  - Required for initiating API calls to Salesforce.
+                - |-
+                  The unique identifier assigned to a client application by Salesforce during the
+                  OAuth client registration process.
+                  This ID is used to authenticate the client when making API requests and
+                  establishing a secure connection with Salesforce services.
+                  It is essential for enabling authorized access to Salesforce resources on behalf
+                  of the client application.
+                - |-
+                  The unique identifier assigned to a client application by Salesforce during the
+                  OAuth client registration process.
+                  This ID is used to authenticate the client when making API requests and
+                  establishing a secure connection with Salesforce services.
+                  It is essential for enabling authorized access to Salesforce resources on behalf
+                  of the client application.
+              examples:
+                - 3MVG9pRzvMkjMb6kkUMc3nVfDlF1H9V8sV0kZ8wQ7nC2x
+                - 3MVG9d6T2QxX9z5l7Y8P0qR1sT2uVwXyZAbCdEfGhIjKlMnOpQrStUvWxYz123456
+                - 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef
+            clientSecret:
+              type: string
+              description: |-
+                Salesforce client secret. Returned masked as `"******"`.
+                Re-send that value on update to keep it; it is not preserved if omitted.
+              x-celigo-ai-guidance:
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Provide the plain client secret value here to set/update it.
+                  - To keep the existing secret unchanged during an update, omit this field (or keep `"******"` as-is if returned).
+                - |-
+                  Use the Salesforce OAuth **client secret** value to configure or update the Salesforce iClient;
+                  integrator.io stores this secret encrypted at rest internally (for example as
+                  `clientSecret_crypt` and `clientSecret_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a secret is already set.
+                - |-
+                  Use the Salesforce OAuth **client secret** value to configure or update the Salesforce iClient;
+                  integrator.io stores this secret encrypted at rest internally (for example as
+                  `clientSecret_crypt` and `clientSecret_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a secret is already set.
+                - |-
+                  Use the Salesforce OAuth **client secret** value to configure or update the Salesforce iClient;
+                  integrator.io stores this secret encrypted at rest internally (for example as
+                  `clientSecret_crypt` and `clientSecret_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a secret is already set.
+            apiToken:
+              type: string
+              description: |-
+                Salesforce security token appended to the password for
+                username-password auth flows.
+              x-celigo-ai-guidance:
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Dependent on Salesforce user credentials or OAuth authorization flows.
+                  - Used in conjunction with the Salesforce instance URL and API endpoints.
+                  - May require additional headers or parameters as per Salesforce API specifications.
+                - |-
+                  ## IMPORTANT NOTES:
+                  - The API token is sensitive information and should be treated like a password.
+                  - Sharing or leaking the token can compromise Salesforce data security.
+                  - Ensure compliance with Salesforce security policies when handling tokens.
+                  - Different Salesforce environments (sandbox vs production) may require different tokens.
+                - |-
+                  ## EXAMPLES:
+                  - A long alphanumeric string like "00Dxx0000001gPFEAY!AQ0AQJ..."
+                  - OAuth access tokens obtained via Salesforce OAuth 2.0 flows.
+                  - Tokens generated from Salesforce connected apps for API access.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Store the token securely, such as in environment variables or secure vaults.
+                  - Avoid hardcoding the token in source code or exposing it in logs.
+                  - Implement token refresh logic if using OAuth tokens with limited lifespans.
+                  - Validate the token format before use to prevent malformed requests.
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Typically included in HTTP headers as "Authorization: Bearer {apiToken}".
+                  - May have scopes or permissions associated depending on how it was generated.
+                  - Tokens may be JWTs or opaque strings depending on the authentication method.
+                  - Salesforce APIs validate the token on each request to authorize access.
+                - |-
+                  The API token used to authenticate requests to the Salesforce API.
+                  This token acts as a secure credential that grants access to Salesforce
+                  resources and operations,
+                  ensuring that only authorized clients can interact with the Salesforce environment.
+                  It is typically generated within Salesforce or through an OAuth flow and must be
+                  kept confidential to prevent unauthorized access.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Used for authenticating API calls to Salesforce.
+                  - Must be included in the authorization header or as specified by the Salesforce API.
+                  - Typically has an expiration time and may require periodic renewal.
+                  - Invalid or expired tokens will result in authentication errors.
+                - |-
+                  The API token used to authenticate requests to the Salesforce API.
+                  This token acts as a secure credential that grants access to Salesforce
+                  resources and operations,
+                  ensuring that only authorized clients can interact with the Salesforce environment.
+                  It is typically generated within Salesforce or through an OAuth flow and must be
+                  kept confidential to prevent unauthorized access.
+                - |-
+                  The API token used to authenticate requests to the Salesforce API.
+                  This token acts as a secure credential that grants access to Salesforce
+                  resources and operations,
+                  ensuring that only authorized clients can interact with the Salesforce environment.
+                  It is typically generated within Salesforce or through an OAuth flow and must be
+                  kept confidential to prevent unauthorized access.
+            privateKey:
+              type: string
+              description: |-
+                Private key for Salesforce JWT bearer token flows (PEM
+                format). Returned masked as `"******"`.
+              x-celigo-ai-guidance:
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Provide the plaintext private key value here to set/update it (often PEM formatted).
+                  - To keep the existing private key unchanged during an update, omit this field (or keep `"******"` as-is if returned).
+                - |-
+                  Set the Salesforce private key value used for authentication flows such as JWT
+                  bearer token OAuth;
+                  this is the value you provide to configure or update the Salesforce iClient.
+                  Internally,
+                  integrator.io stores this key encrypted at rest (for example as
+                  `privateKey_crypt`/`privateKey_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a key is already set.
+                - |-
+                  Set the Salesforce private key value used for authentication flows such as JWT
+                  bearer token OAuth;
+                  this is the value you provide to configure or update the Salesforce iClient.
+                  Internally,
+                  integrator.io stores this key encrypted at rest (for example as
+                  `privateKey_crypt`/`privateKey_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a key is already set.
+                - |-
+                  Set the Salesforce private key value used for authentication flows such as JWT
+                  bearer token OAuth;
+                  this is the value you provide to configure or update the Salesforce iClient.
+                  Internally,
+                  integrator.io stores this key encrypted at rest (for example as
+                  `privateKey_crypt`/`privateKey_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a key is already set.
+            publicKey:
+              type: string
+              description: Public key corresponding to `privateKey` (PEM format).
+              x-celigo-ai-guidance:
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Dependent on the cryptographic algorithm and key pair generation process.
+                  - Used by authentication, encryption, or signature verification components.
+                  - May be linked to other security configurations such as certificates or token validation settings.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Accepts a string value representing the public key in a standard format (e.g., PEM, DER).
+                  - Used to encrypt data or verify signatures in cryptographic operations.
+                  - Must be provided in a format compatible with the consuming system.
+                  - Immutable once set for a given integration instance to maintain security.
+                - |-
+                  ## EXAMPLES:
+                  - A PEM-encoded RSA public key string starting with "-----BEGIN PUBLIC KEY-----".
+                  - An ECDSA public key represented in base64 encoding.
+                  - A public key string used to verify JWT tokens issued by Salesforce.
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Typically encoded in PEM or DER format.
+                  - May include metadata such as key type and length.
+                  - Should comply with relevant security standards (e.g., PKCS#1, X.509).
+                  - Size and algorithm choice affect security strength and performance.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Ensure the public key is generated using a secure and recognized cryptographic algorithm (e.g., RSA, ECDSA).
+                  - Validate the key format before accepting it to prevent errors during cryptographic operations.
+                  - Store the key securely and restrict access to prevent unauthorized modifications.
+                  - Update the key only through a controlled process to avoid breaking integrations.
+                - |-
+                  ## IMPORTANT NOTES:
+                  - The publicKey must correspond to the private key held securely by the entity performing signing or decryption.
+                  - Do not expose the private key in any API or configuration.
+                  - Incorrect or malformed keys will cause authentication or encryption failures.
+                  - Keep the key updated in case of key rotation policies.
+                - |-
+                  The publicKey property represents the public cryptographic key used for secure data encryption,
+                  verification, or authentication processes within the Salesforce integration.
+                  This key is typically part of a public-private key pair and is used to encrypt
+                  data or verify digital signatures without exposing the private key.
+                  It ensures secure communication and data integrity between systems.
+                - |-
+                  The publicKey property represents the public cryptographic key used for secure data encryption,
+                  verification, or authentication processes within the Salesforce integration.
+                  This key is typically part of a public-private key pair and is used to encrypt
+                  data or verify digital signatures without exposing the private key.
+                  It ensures secure communication and data integrity between systems.
+                - |-
+                  The publicKey property represents the public cryptographic key used for secure data encryption,
+                  verification, or authentication processes within the Salesforce integration.
+                  This key is typically part of a public-private key pair and is used to encrypt
+                  data or verify digital signatures without exposing the private key.
+                  It ensures secure communication and data integrity between systems.
+        ebay:
+          type: object
+          description: eBay REST/Trading API authentication credentials.
+          x-celigo-ai-guidance:
+            - |-
+              ## EXAMPLES:
+              - API key and secret for eBay developer account.
+              - OAuth tokens for user authentication with eBay.
+              - URLs for eBay REST or Trading API endpoints.
+              - Flags to enable or disable specific eBay features like inventory management or order processing.
+            - |-
+              ## FIELD BEHAVIOR:
+              - Holds all necessary eBay-related configuration details.
+              - Used to enable and customize eBay platform interactions.
+              - May include API keys, tokens, endpoint URLs, and feature toggles.
+              - Supports dynamic updates to eBay integration settings without redeploying the application.
+            - |-
+              ## TECHNICAL DETAILS:
+              - Typically structured as a nested object containing keys like clientId, clientSecret, accessToken, refreshToken, and apiEndpoints.
+              - May include metadata such as token expiration timestamps and scopes.
+              - Supports serialization and secure storage mechanisms.
+              - Designed to be extensible for future eBay API features and versions.
+            - |-
+              ## DEPENDENCY CHAIN:
+              - Dependent on eBay developer account and API access permissions.
+              - Interacts with authentication modules to manage tokens.
+              - Works alongside order management and inventory systems for synchronization.
+              - May depend on network connectivity and proxy settings for API calls.
+            - |-
+              ## IMPORTANT NOTES:
+              - Credentials must be kept confidential and never exposed in client-side code.
+              - Regularly update tokens and keys to maintain uninterrupted service.
+              - Comply with eBay's API usage policies and rate limits.
+              - Changes to this configuration may affect live eBay transactions and listings.
+            - |-
+              Contains configuration settings and credentials specific to eBay integration
+              within the application.
+              This property manages parameters required to connect, authenticate,
+              and interact with eBay's APIs and services.
+            - |-
+              ## IMPLEMENTATION GUIDANCE:
+              - Securely store sensitive information such as API credentials.
+              - Validate the presence and correctness of required fields before making API calls.
+              - Support environment-specific configurations (e.g., sandbox vs. production).
+              - Ensure compatibility with the latest eBay API versions.
+              - Provide clear error handling and logging for eBay-related operations.
+            - |-
+              Contains configuration settings and credentials specific to eBay integration
+              within the application.
+              This property manages parameters required to connect, authenticate,
+              and interact with eBay's APIs and services.
+            - |-
+              Contains configuration settings and credentials specific to eBay integration
+              within the application.
+              This property manages parameters required to connect, authenticate,
+              and interact with eBay's APIs and services.
+          properties:
+            appId:
+              type: string
+              description: eBay application ID from the eBay Developer Program.
+              x-celigo-ai-guidance:
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Typically a UUID or a unique string assigned by eBay.
+                  - Passed as part of HTTP headers or query parameters depending on the API.
+                  - Used by eBay servers to identify and authenticate the application making the request.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Obtain the appId by registering your application on the eBay Developer Program portal.
+                  - Keep the appId confidential to prevent unauthorized use.
+                  - Include the appId in the request headers or parameters as specified by the API documentation.
+                  - Validate the appId format before sending requests to avoid errors.
+                - |-
+                  ## EXAMPLES:
+                  - "12345678-1234-1234-1234-123456789abc"
+                  - "MyEbayAppID2024"
+                  - "APP-9876543210"
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Depends on successful registration with the eBay Developer Program.
+                  - Used in conjunction with other authentication credentials like OAuth tokens.
+                  - Required before making authorized API calls.
+                - |-
+                  The unique identifier assigned to an application registered with the eBay developer program.
+                  This ID is used to authenticate API requests and associate them with a specific application.
+                - |-
+                  ## IMPORTANT NOTES:
+                  - The appId is different from other eBay credentials such as client ID or client secret.
+                  - Using an invalid or expired appId will result in authentication errors.
+                  - Do not share your appId publicly to protect your application's security.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Must be included in API requests to identify the calling application.
+                  - Typically a string consisting of alphanumeric characters.
+                  - Used to track usage and enforce rate limits for the application.
+                  - Required for accessing most eBay APIs.
+                - |-
+                  The unique identifier assigned to an application registered with the eBay developer program.
+                  This ID is used to authenticate API requests and associate them with a specific application.
+                - |-
+                  The unique identifier assigned to an application registered with the eBay developer program.
+                  This ID is used to authenticate API requests and associate them with a specific application.
+              examples:
+                - MyCompan-MyApp-PRD-1a2b3c4d5-6e7f8a9b
+                - 12345678-1234-1234-1234-123456789abc
+                - MyEbayAppID2024
+                - APP-9876543210
+            devId:
+              type: string
+              description: eBay developer ID from the eBay Developer Program.
+              x-celigo-ai-guidance:
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Typically a string of alphanumeric characters.
+                  - Assigned by eBay upon developer registration.
+                  - Used in API request headers or query parameters depending on the API endpoint.
+                  - Validated by eBay servers to authorize API access.
+                - |-
+                  ## IMPORTANT NOTES:
+                  - The devId is distinct from other eBay identifiers such as appId, certId, or auth tokens.
+                  - Misuse or leakage of the devId can lead to unauthorized API access.
+                  - Changes to the devId require updating all applications using it.
+                  - Ensure compliance with eBay's developer policies when using the devId.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Must be included in API requests requiring developer authentication.
+                  - Used to identify the source of API calls.
+                  - Typically remains constant for a given developer or development team.
+                  - Should be kept confidential to prevent unauthorized use.
+                - |-
+                  ## EXAMPLES:
+                  - "1234567890"
+                  - "dev_abcdef123456"
+                  - "9876543210"
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Often used alongside appId and certId for full API authentication.
+                  - May be required before obtaining OAuth tokens or other credentials.
+                  - Linked to developer account settings and permissions on eBay.
+                - |-
+                  The unique identifier assigned to a developer or development team by eBay.
+                  This ID is used to authenticate and track API usage associated with the
+                  developer's applications.
+                  It ensures that API requests are properly attributed and helps manage access
+                  permissions and rate limits.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Obtain the devId by registering as a developer on the eBay Developer Program portal.
+                  - Include the devId in all relevant API request headers or parameters as specified by eBay.
+                  - Store the devId securely in your application environment.
+                  - Do not expose the devId in client-side code or public repositories.
+                - |-
+                  The unique identifier assigned to a developer or development team by eBay.
+                  This ID is used to authenticate and track API usage associated with the
+                  developer's applications.
+                  It ensures that API requests are properly attributed and helps manage access
+                  permissions and rate limits.
+                - |-
+                  The unique identifier assigned to a developer or development team by eBay.
+                  This ID is used to authenticate and track API usage associated with the
+                  developer's applications.
+                  It ensures that API requests are properly attributed and helps manage access
+                  permissions and rate limits.
+              examples:
+                - 1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
+                - '1234567890'
+                - dev_abcdef123456
+                - '9876543210'
+            certId:
+              type: string
+              description: |-
+                eBay certificate ID. Returned masked as `"******"`.
+                Re-send that value on update to keep it; it is not preserved if omitted.
+              x-celigo-ai-guidance:
+                - |-
+                  Use the eBay certificate ID value for authentication;
+                  this is the value you provide to configure or update the iClient. integrator.io
+                  stores it encrypted at rest (for example as `certId_crypt`/`certId_salt` fields
+                  in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a value is already set.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Provide the plaintext certificate ID value here to set/update it.
+                  - To keep the existing value unchanged during an update, omit this field (or keep `"******"` as-is if returned).
+                - |-
+                  Use the eBay certificate ID value for authentication;
+                  this is the value you provide to configure or update the iClient. integrator.io
+                  stores it encrypted at rest (for example as `certId_crypt`/`certId_salt` fields
+                  in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a value is already set.
+                - |-
+                  Use the eBay certificate ID value for authentication;
+                  this is the value you provide to configure or update the iClient. integrator.io
+                  stores it encrypted at rest (for example as `certId_crypt`/`certId_salt` fields
+                  in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a value is already set.
+            ruName:
+              type: string
+              description: |-
+                eBay Redirect URL Name (RuName) — the auth redirect
+                target registered in the eBay Developer Program.
+              x-celigo-ai-guidance:
+                - |-
+                  ## EXAMPLES:
+                  - "Электроника" (Electronics)
+                  - "Мода" (Fashion)
+                  - "Дом и сад" (Home and Garden)
+                - |-
+                  The Russian name associated with the eBay entity,
+                  typically used for localization and display purposes in Russian-language contexts.
+                  This field contains the name as it should appear to Russian-speaking users,
+                  ensuring proper representation and cultural relevance.
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Data type: string.
+                  - Character encoding: UTF-8.
+                  - Maximum length should conform to system constraints for name fields.
+                - |-
+                  ## IMPORTANT NOTES:
+                  - This field is optional if the entity does not have a Russian localization.
+                  - Avoid transliterations; use proper Russian language terms.
+                  - Consistency with other localized names is important for user experience.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Ensure the name is correctly translated and culturally appropriate.
+                  - Use Cyrillic characters as per Russian language standards.
+                  - Validate the string for encoding compatibility (UTF-8).
+                  - Update this field when the entity's Russian name changes.
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - May depend on the primary name or English name for context.
+                  - Used in conjunction with other localized name fields for multi-language support.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Represents the localized name in Russian.
+                  - Used primarily for display in Russian language interfaces.
+                  - Should accurately reflect the entity's name in Russian script.
+                  - May be omitted if no Russian localization is available.
+                - |-
+                  The Russian name associated with the eBay entity,
+                  typically used for localization and display purposes in Russian-language contexts.
+                  This field contains the name as it should appear to Russian-speaking users,
+                  ensuring proper representation and cultural relevance.
+                - |-
+                  The Russian name associated with the eBay entity,
+                  typically used for localization and display purposes in Russian-language contexts.
+                  This field contains the name as it should appear to Russian-speaking users,
+                  ensuring proper representation and cultural relevance.
+              examples:
+                - My_Company-MyCompan-MyApp-abcdefgh
+                - Электроника
+                - Мода
+                - Дом и сад
+        amazonmws:
+          type: object
+          description: Amazon Marketplace Web Service (MWS) authentication credentials.
+          x-celigo-ai-guidance:
+            - |-
+              ## IMPORTANT NOTES:
+              - Amazon MWS is being succeeded by the Selling Partner API (SP-API); consider migration plans.
+              - Credentials must be kept confidential to prevent unauthorized access.
+              - API access is subject to Amazon's terms of service and usage policies.
+              - Proper error handling is critical to manage API rate limits and service disruptions.
+            - |-
+              Configuration settings required to integrate with the Amazon Marketplace Web
+              Service (Amazon MWS) API,
+              enabling programmatic access to Amazon seller account data and operations.
+              This includes credentials and parameters necessary for authentication,
+              authorization, and interaction with various Amazon MWS endpoints.
+            - |-
+              ## EXAMPLES:
+              - Access Key ID: "AKIAIOSFODNN7EXAMPLE"
+              - Secret Access Key: "1234567890abcdef1234567890abcdef12345678"
+              - Seller ID: "A1XEXAMPLE123"
+              - MWS Auth Token: "amzn.mws.4ea38b7b-f563-7709-4bae-87aeaEXAMPLE"
+            - |-
+              ## FIELD BEHAVIOR:
+              - Contains all necessary authentication credentials such as Access Key ID, Secret Access Key, Seller ID, and MWS Auth Token.
+              - May include configuration options like marketplace IDs, region settings, and API version.
+              - Used to establish secure and authorized communication with Amazon MWS services.
+              - Typically required for operations such as order retrieval, inventory management, and report generation.
+            - |-
+              ## TECHNICAL DETAILS:
+              - Uses RESTful API calls with XML or JSON payloads.
+              - Authentication is based on AWS Signature Version 2 or 4.
+              - Supports multiple API sections including Orders, Reports, Feeds, and Products.
+              - Requires timestamp synchronization to prevent request rejection.
+            - |-
+              ## DEPENDENCY CHAIN:
+              - Requires valid Amazon seller account with MWS access enabled.
+              - Dependent on network connectivity to Amazon MWS endpoints.
+              - May depend on other configuration properties such as marketplace identifiers.
+            - |-
+              ## IMPLEMENTATION GUIDANCE:
+              - Ensure all credentials are stored securely and transmitted over encrypted channels.
+              - Validate the presence and correctness of all required fields before attempting API calls.
+              - Support refreshing or updating credentials as needed to maintain uninterrupted access.
+              - Handle error responses gracefully, including authentication failures or permission issues.
+              - Follow Amazon MWS best practices and rate limits to avoid throttling.
+            - |-
+              Configuration settings required to integrate with the Amazon Marketplace Web
+              Service (Amazon MWS) API,
+              enabling programmatic access to Amazon seller account data and operations.
+              This includes credentials and parameters necessary for authentication,
+              authorization, and interaction with various Amazon MWS endpoints.
+            - |-
+              Configuration settings required to integrate with the Amazon Marketplace Web
+              Service (Amazon MWS) API,
+              enabling programmatic access to Amazon seller account data and operations.
+              This includes credentials and parameters necessary for authentication,
+              authorization, and interaction with various Amazon MWS endpoints.
+          properties:
+            accessKeyId:
+              type: string
+              description: AWS access key ID for MWS API requests.
+              x-celigo-ai-guidance:
+                - |-
+                  ## TECHNICAL DETAILS:
+                  - Format: 20-character alphanumeric string.
+                  - Used in the AWS Signature Version 2 or 4 signing process.
+                  - Included in the HTTP headers or query parameters of API requests.
+                  - Validated by Amazon MWS servers to authorize API calls.
+                - |-
+                  ## DEPENDENCY CHAIN:
+                  - Requires a corresponding Secret Access Key for request signing.
+                  - Must be associated with an AWS IAM user or role with Amazon MWS permissions.
+                  - Used alongside other credentials such as Seller ID and MWS Auth Token for full API access.
+                - |-
+                  ## EXAMPLES:
+                  - "AKIAIOSFODNN7EXAMPLE"
+                  - "ABCD1234EFGH5678IJKL"
+                  - "A1B2C3D4E5F6G7H8I9J0"
+                - |-
+                  ## IMPORTANT NOTES:
+                  - The Access Key ID alone is insufficient for authentication; it must be paired with the Secret Access Key.
+                  - Exposure of the Access Key ID and Secret Access Key can lead to unauthorized access and potential data breaches.
+                  - If compromised, immediately revoke and regenerate the keys via the AWS console.
+                  - Access Key IDs are case-sensitive.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Retrieve the Access Key ID from your AWS Management Console or Amazon MWS developer account.
+                  - Ensure the Access Key ID corresponds to the correct AWS user with appropriate permissions.
+                  - Do not hard-code the key in publicly accessible code repositories.
+                  - Rotate keys periodically to maintain security best practices.
+                - |-
+                  ## FIELD BEHAVIOR:
+                  - Must be a valid, active Access Key ID issued by Amazon.
+                  - Used in conjunction with the Secret Access Key to sign API requests.
+                  - Should be kept confidential to prevent unauthorized access.
+                  - Typically a 20-character alphanumeric string.
+                - |-
+                  The Access Key ID is a unique identifier assigned to your Amazon MWS
+                  (Marketplace Web Service) account,
+                  used to authenticate API requests.
+                  It acts as a public credential that, together with the Secret Access Key,
+                  allows secure access to Amazon MWS services.
+                  This key is essential for programmatic interaction with Amazon's seller APIs,
+                  enabling operations such as order retrieval, inventory management,
+                  and report generation.
+                - |-
+                  The Access Key ID is a unique identifier assigned to your Amazon MWS
+                  (Marketplace Web Service) account,
+                  used to authenticate API requests.
+                  It acts as a public credential that, together with the Secret Access Key,
+                  allows secure access to Amazon MWS services.
+                  This key is essential for programmatic interaction with Amazon's seller APIs,
+                  enabling operations such as order retrieval, inventory management,
+                  and report generation.
+                - |-
+                  The Access Key ID is a unique identifier assigned to your Amazon MWS
+                  (Marketplace Web Service) account,
+                  used to authenticate API requests.
+                  It acts as a public credential that, together with the Secret Access Key,
+                  allows secure access to Amazon MWS services.
+                  This key is essential for programmatic interaction with Amazon's seller APIs,
+                  enabling operations such as order retrieval, inventory management,
+                  and report generation.
+              examples:
+                - AKIAIOSFODNN7EXAMPLE
+                - ABCD1234EFGH5678IJKL
+                - A1B2C3D4E5F6G7H8I9J0
+            secretKey:
+              type: string
+              description: |-
+                AWS secret key. Returned masked as `"******"`.
+                Re-send that value on update to keep it; it is not preserved if omitted.
+              x-celigo-ai-guidance:
+                - |-
+                  Use the Amazon MWS secret key value for authentication;
+                  provide this value to configure or update the iClient.
+                  Internally,
+                  integrator.io stores it encrypted at rest (for example as
+                  `secretKey_crypt`/`secretKey_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a value is already set.
+                - |-
+                  ## IMPLEMENTATION GUIDANCE:
+                  - Provide the plaintext secret key value here to set/update it.
+                  - To keep the existing value unchanged during an update, omit this field (or keep `"******"` as-is if returned).
+                - |-
+                  Use the Amazon MWS secret key value for authentication;
+                  provide this value to configure or update the iClient.
+                  Internally,
+                  integrator.io stores it encrypted at rest (for example as
+                  `secretKey_crypt`/`secretKey_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a value is already set.
+                - |-
+                  Use the Amazon MWS secret key value for authentication;
+                  provide this value to configure or update the iClient.
+                  Internally,
+                  integrator.io stores it encrypted at rest (for example as
+                  `secretKey_crypt`/`secretKey_salt` fields in the underlying model),
+                  and API responses typically return a masked value (e.g.,
+                  `"******"`) when a value is already set.
+        azureserviceprincipal:
+          type: object
+          description: |-
+            Azure AD service principal credentials. Required when `provider`
+            is `azureserviceprincipal`.
+          required:
+            - clientId
+            - tenantId
+          properties:
+            authMethod:
+              type: string
+              enum:
+                - client-secret
+                - certificate
+              default: client-secret
+              x-enumDescriptions:
+                client-secret: Authenticate with a client secret (`clientSecret`).
+                certificate: Authenticate with a PEM certificate + private key (`certificate`).
+              description: |-
+                Which credential the service principal presents. Defaults to
+                `client-secret` when omitted. Each method rejects the other
+                method's credential fields on save.
+            clientId:
+              type: string
+              description: Azure AD application (client) ID.
+              examples:
+                - a1b2c3d4-e5f6-7890-abcd-ef1234567890
+            clientSecret:
+              type: string
+              description: |-
+                Azure AD client secret. Required when `authMethod` is
+                `client-secret` (or omitted). Returned masked as `"******"`.
+                Re-send that value on update to keep it; it is not preserved if omitted.
+            certificate:
+              type: string
+              description: |-
+                PEM bundle (certificate + private key) for certificate auth.
+                Required when `authMethod` is `certificate`; rejected under
+                `client-secret`. Maximum 20 KiB of PEM text. Returned masked.
+              x-celigo-ai-guidance:
+                - |-
+                  If the PEM's private key is encrypted (BEGIN ENCRYPTED PRIVATE
+                  KEY / Proc-Type 4,ENCRYPTED), certificatePassword is required;
+                  if it is unencrypted, sending certificatePassword is rejected.
+            certificatePassword:
+              type: string
+              description: |-
+                Passphrase for an encrypted private key inside `certificate`.
+                Required exactly when the PEM's key is encrypted; rejected when
+                it is not. Maximum 256 bytes. Returned masked.
+            tenantId:
+              type: string
+              description: Azure AD tenant (directory) ID.
+              examples:
+                - f0e1d2c3-b4a5-6789-0abc-def012345678
+        googleserviceaccount:
+          type: object
+          description: |-
+            Google Cloud service-account credentials. Required when `provider` is
+            `googleserviceaccount`. Send the raw JSON key file in
+            `serviceAccountJSON`; the server parses out `project_id`,
+            `client_email`, and `private_key` and stores them (the private key
+            encrypted). Responses return only `clientEmail`.
+          properties:
+            serviceAccountJSON:
+              type: string
+              writeOnly: true
+              description: |-
+                Full Google service-account key file as a JSON string. Must parse
+                as JSON and contain `project_id`, `client_email`, and a valid PEM
+                `private_key` — otherwise the save fails with
+                ICLIENT_GOOGLESERVICEACCOUNT_INVALID_JSON_KEY (or _INVALID_PEM
+                when only the key material is malformed). On update, omitting it
+                (or sending the mask) keeps the stored credentials.
+            clientEmail:
+              type: string
+              readOnly: true
+              description: Service-account email parsed from the key file — the only field echoed in responses.
+              examples:
+                - integration@my-gcs-project.iam.gserviceaccount.com
+        awsIam:
+          type: object
+          description: |-
+            AWS IAM cross-account role credentials. Required when `provider` is `awsIam`.
+            Celigo assumes `roleArn` using `externalId` as the trust-policy external ID.
+          required:
+            - externalId
+          properties:
+            externalId:
+              type: string
+              description: |-
+                External ID Celigo presents when assuming the role; must match the
+                `sts:ExternalId` condition in the role's trust policy.
+              examples:
+                - celigo-7f3a9c2e1b
+            roleArn:
+              type: string
+              description: ARN of the AWS IAM role to assume for cross-account access.
+              examples:
+                - arn:aws:iam::123456789012:role/celigo-integration
+        jwt:
+          type: object
+          description: |-
+            JWT assertion configuration. Used when `enableJWT` is true to
+            generate a signed JWT for inclusion in OAuth token requests via
+            `{{{iClient.jwt.token}}}`.
+          x-celigo-ai-guidance:
+            - |-
+              ## IMPLEMENTATION GUIDANCE:
+              - Validate the JWT on the server side to ensure it is properly signed and not expired.
+              - Use secure algorithms (e.g., RS256 or HS256) for signing the token.
+              - Store sensitive information in the payload with caution, as JWTs can be decoded by clients.
+              - Refresh tokens should be used to obtain new JWTs when the current one expires.
+            - |-
+              ## FIELD BEHAVIOR:
+              - Must be a valid JWT string following the standard format: header.payload.signature.
+              - Used to authenticate API requests and authorize access to specific endpoints.
+              - Typically included in the Authorization header as a Bearer token.
+              - Should have an expiration time to enhance security.
+            - |-
+              A JSON Web Token (JWT) used for securely transmitting information between
+              parties as a JSON object.
+              This token is typically used for authentication and authorization purposes,
+              ensuring that the client has valid credentials to access protected resources.
+              The JWT contains encoded header, payload,
+              and signature sections that verify the token's integrity and authenticity.
+            - |-
+              ## IMPORTANT NOTES:
+              - JWTs should be transmitted over secure channels (HTTPS) to prevent interception.
+              - Do not store JWTs in insecure storage locations on the client side (e.g., localStorage) to avoid XSS attacks.
+              - Always verify the token's signature and claims before granting access.
+              - Be aware of token expiration and implement proper handling for expired tokens.
+            - |-
+              ## EXAMPLES:
+              - eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
+              - eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJleGFtcGxlLmNvbSIsInN1YiI6IjEyMzQ1Njc4OTAiLCJleHAiOjE2MjQ2MjQwMDB9.DQABCD1234abcd5678efgh9012ijkl3456mnop7890qrstuv
+            - |-
+              ## DEPENDENCY CHAIN:
+              - Depends on the authentication mechanism generating the JWT.
+              - Requires a
+            - |-
+              A JSON Web Token (JWT) used for securely transmitting information between
+              parties as a JSON object.
+              This token is typically used for authentication and authorization purposes,
+              ensuring that the client has valid credentials to access protected resources.
+              The JWT contains encoded header, payload,
+              and signature sections that verify the token's integrity and authenticity.
+            - |-
+              A JSON Web Token (JWT) used for securely transmitting information between
+              parties as a JSON object.
+              This token is typically used for authentication and authorization purposes,
+              ensuring that the client has valid credentials to access protected resources.
+              The JWT contains encoded header, payload,
+              and signature sections that verify the token's integrity and authenticity.
+          properties:
+            signatureMethod:
+              type: string
+              enum:
+                - hmac-sha256
+                - hmac-sha384
+                - hmac-sha512
+                - rsa-sha256
+                - rsa-sha384
+                - rsa-sha512
+                - es256
+                - es384
+                - es512
+                - ps256
+                - ps384
+                - ps512
+              x-enumDescriptions:
+                hmac-sha256: HMAC with SHA-256 (symmetric); signs with secret.
+                hmac-sha384: HMAC with SHA-384 (symmetric); signs with secret.
+                hmac-sha512: HMAC with SHA-512 (symmetric); signs with secret.
+                rsa-sha256: RSA with SHA-256 (asymmetric); signs with privateKey.
+                rsa-sha384: RSA with SHA-384 (asymmetric); signs with privateKey.
+                rsa-sha512: RSA with SHA-512 (asymmetric); signs with privateKey.
+                es256: ECDSA with P-256 and SHA-256 (asymmetric); signs with privateKey.
+                es384: ECDSA with P-384 and SHA-384 (asymmetric); signs with privateKey.
+                es512: ECDSA with P-521 and SHA-512 (asymmetric); signs with privateKey.
+                ps256: RSASSA-PSS with SHA-256 (asymmetric); signs with privateKey.
+                ps384: RSASSA-PSS with SHA-384 (asymmetric); signs with privateKey.
+                ps512: RSASSA-PSS with SHA-512 (asymmetric); signs with privateKey.
+              description: |-
+                Algorithm used to sign the JWT. HMAC methods sign with `secret`;
+                RSA/ECDSA/PSS methods sign with `privateKey`.
+            payload:
+              description: |-
+                JWT payload claims. Can be a JSON object or a stringified
+                JSON template with Handlebars expressions.
+            headers:
+              description: |-
+                JWT header claims. Can be a JSON object or a stringified
+                JSON template with Handlebars expressions.
+            privateKey:
+              type: string
+              description: |-
+                Private key for signing the JWT. Returned masked as
+                `"******"`. Re-send that value on update to keep it; it is not preserved if omitted.
+            token:
+              type: string
+              readOnly: true
+              description: |-
+                Server-computed signed JWT token. Returned masked as
+                `"******"` in responses.
+            secret:
+              type: string
+              description: |-
+                Shared secret for HMAC-based JWT signing (e.g. HS256).
+                Returned masked as `"******"`. Re-send that value on update to
+                keep it; it is not preserved if omitted.
+            isSecretBase64Encoded:
+              type: boolean
+              description: When true, the `secret` value is Base64-encoded.
+    ResourceResponse:
+      type: object
+      description: Response
+      x-celigo-ai-guidance:
+        - Core response fields shared by all Celigo resources
+      properties:
+        _id:
+          type: string
+          format: objectId
+          readOnly: true
+          description: Unique identifier for the resource. Format is a 24-character hexadecimal string.
+          x-celigo-ai-guidance:
+            - |-
+              The _id is used in:
+              - API endpoints that operate on a specific resource (e.g., GET, PUT, DELETE)
+              - References from other resources (e.g., flows that use this resource)
+              - Job history and error tracking
+          examples:
+            - 5f8d43a1b9e5a80011a35f2c
+        createdAt:
+          type: string
+          format: date-time
+          readOnly: true
+          description: Timestamp when the resource was created. Set automatically and cannot be modified.
+          x-celigo-ai-guidance:
+            - Recorded in ISO 8601 with a UTC timezone (Z suffix).
+          examples:
+            - '2023-04-01T09:15:32Z'
+        lastModified:
+          type: string
+          format: date-time
+          readOnly: true
+          description: Timestamp when the resource was last updated. Changes whenever any property is modified.
+          x-celigo-ai-guidance:
+            - Recorded in ISO 8601 with a UTC timezone (Z suffix); always equal to or later than `createdAt`.
+          examples:
+            - '2023-04-15T14:30:15Z'
+        deletedAt:
+          type:
+            - string
+            - 'null'
+          format: date-time
+          readOnly: true
+          description: Timestamp when the resource was soft-deleted. When null or absent, the resource is active.
+          x-celigo-ai-guidance:
+            - Non-null means the resource is soft-deleted (in the recycle bin) — recoverable within the retention period before permanent removal.
+          examples:
+            - '2023-05-20T11:45:32Z'
+      required:
+        - _id
+    IAResourceResponse:
+      type: object
+      description: Integration app response fields for resources that are part of integration apps
+      properties:
+        _integrationId:
+          type: string
+          format: objectId
+          x-celigo-refModel: integrations
+          readOnly: true
+          description: |
+            Reference to the specific integration instance that contains this resource.
+
+            This field is only populated for resources that are part of an integration app
+            installation. It contains the unique identifier (_id) of the integration
+            resource that was installed in the account.
+
+            The integration instance represents a specific installed instance of an
+            integration app, with its own configuration, settings, and runtime environment.
+
+            This reference enables:
+            - Tracing the resource back to its parent integration instance
+            - Permission and access control based on integration ownership
+            - Lifecycle management (enabling/disabling, updating, or uninstalling)
+          examples:
+            - 5f9a7b2c3d4e5f6a7b8c9d0e
+        _connectorId:
+          type: string
+          format: objectId
+          x-celigo-refModel: connectors
+          readOnly: true
+          description: |
+            Reference to the integration app that defines this resource.
+
+            This field is only populated for resources that are part of an integration app.
+            It contains the unique identifier (_id) of the integration app (connector)
+            that defines the structure, behavior, and templates for this resource.
+
+            The integration app is the published template that can be installed
+            multiple times across different accounts, with each installation creating
+            a separate integration instance (referenced by _integrationId).
+
+            This reference enables:
+            - Identifying the source integration app for this resource
+            - Determining which template version is being used
+            - Linking to documentation, support, and marketplace information
+          examples:
+            - 5e8d43a1b9e5a80011a35f1b
+          x-celigo-ai-guidance:
+            - |-
+              Read-only connector (Integration App template) reference; present only on
+              connector-owned resources. Never set or modify it when authoring resources.
+    iClient:
+      type: object
+      required:
+        - _id
+        - provider
+        - lastModified
+      description: |-
+        iClient object as returned by the API. Includes all request fields
+        plus server-managed metadata. `name` is optional on create and is
+        omitted from GET responses when the iClient was created without
+        one (the create response echoes it as `null`).
+      allOf:
+        - $ref: '#/components/schemas/IClientBase'
+        - $ref: '#/components/schemas/ResourceResponse'
+        - $ref: '#/components/schemas/IAResourceResponse'
+    Request:
+      type: object
+      description: |-
+        iClient configuration. The shape varies by `provider` — each provider
+        requires its own credential sub-object (`oauth2`, `netsuite`,
+        `salesforce`, `ebay`, `amazonmws`, `azureserviceprincipal`).
+        For `custom_oauth2`, credentials go in the `oauth2` sub-object.
+        Secrets (`clientSecret`, `privateKey`, etc.) are returned masked
+        as `"******"`. On update, re-send that masked value to keep the
+        existing secret; secrets are not preserved if omitted.
+      required:
+        - provider
+      allOf:
+        - $ref: '#/components/schemas/IClientBase'
+    Error:
+      type: object
+      description: Standard error response envelope returned by integrator.io APIs.
+      properties:
+        errors:
+          type: array
+          description: List of errors that occurred while processing the request.
+          items:
+            type: object
+            properties:
+              code:
+                oneOf:
+                  - type: string
+                  - type: integer
+                description: |-
+                  Machine-readable error code. Usually a string like
+                  `invalid_ref`, `missing_required_field`, or `unauthorized`;
+                  may be an **integer** when the error mirrors an upstream HTTP
+                  status (e.g. `500`) — most commonly returned by connection-ping
+                  and adaptor-proxy responses.
+              message:
+                type: string
+                description: Human-readable description of the error.
+              field:
+                type: string
+                description: |-
+                  Optional pointer to the document field that caused the error.
+                  Used by structural validation errors (`missing_required_field`,
+                  `invalid_ref`) to indicate which field is at fault
+                  (e.g. `_id`, `type`, `http.baseURI`).
+              source:
+                type: string
+                description: |-
+                  Optional origin layer for the error — e.g. `application` when
+                  the error came from the remote system the adaptor called,
+                  `connector` when the adaptor itself rejected the request.
+            required:
+              - message
+      required:
+        - errors
+    DependencyEntry:
+      type: object
+      description: A single resource that depends on the queried resource.
+      properties:
+        id:
+          type: string
+          description: Unique identifier of the dependent resource.
+          examples:
+            - 61f92026dd053843b5d72350
+        name:
+          type: string
+          description: Display name of the dependent resource.
+          examples:
+            - Import Orders to NetSuite
+        paths:
+          type: array
+          description: |-
+            Dot-notation paths within the dependent resource that reference
+            the target resource. `[*]` denotes array elements.
+          items:
+            type: string
+          examples:
+            - - hooks.preSavePage._scriptId
+        accessLevel:
+          type: string
+          description: The caller's access level on the dependent resource.
+          examples:
+            - manage
+        dependencyIds:
+          type: object
+          description: |-
+            Map of resource types to arrays of IDs that this dependent
+            resource references on the target. Keys are singular or plural
+            resource type strings; values are arrays of ID strings.
+          additionalProperties:
+            type: array
+            items:
+              type: string
+          example:
+            script:
+              - 64ff4b21612a134bd2f45531
+      required:
+        - id
+        - name
+        - paths
+        - accessLevel
+        - dependencyIds
+    DependencyResponse:
+      type: object
+      description: |
+        Map of dependent-resource types to arrays of dependency entries.
+        Keys are plural resource type strings (e.g. `flows`, `imports`,
+        `connections`). An empty object `{}` means no dependents.
+      additionalProperties:
+        type: array
+        items:
+          $ref: '#/components/schemas/DependencyEntry'
+      example:
+        exports:
+          - id: 64ff4b21612a134bd2f45534
+            name: Bank FTP Export
+            paths:
+              - hooks.preSavePage._scriptId
+            accessLevel: manage
+            dependencyIds:
+              script:
+                - 64ff4b21612a134bd2f45531
+        flows:
+          - id: 64ff4b22612a134bd2f45538
+            name: CAMT-053 to Celigo CAM Format
+            paths:
+              - pageGenerators[*]._exportId
+            accessLevel: manage
+            dependencyIds:
+              export:
+                - 64ff4b21612a134bd2f45534
+  responses:
+    401-unauthorized:
+      description: |-
+        Unauthorized. The request lacks a valid bearer token, or the provided token
+        failed to authenticate.
+
+        Note: the 401 response is produced by the auth middleware **before** the
+        request reaches the endpoint handler, so it does **not** follow the
+        standard `{errors: [...]}` envelope. Instead the body is a bare
+        `{message: string}` object with no `code`, no `errors` array. Callers
+        handling 401s should key off the HTTP status and the `message` string,
+        not try to destructure an `errors[]`.
+      content:
+        application/json:
+          schema:
+            type: object
+            properties:
+              message:
+                type: string
+                description: |-
+                  Human-readable description of the auth failure. Known values:
+                  - `"Unauthorized"` — no `Authorization` header on the request.
+                  - `"Bearer Authentication Failed"` — header present but token
+                    is invalid, revoked, or expired.
+            required:
+              - message
+          examples:
+            missing_token:
+              summary: No Authorization header sent
+              value:
+                message: Unauthorized
+            invalid_token:
+              summary: Bearer token invalid or revoked
+              value:
+                message: Bearer Authentication Failed
+    400-bad-request:
+      description: |
+        Bad request. The server could not understand the request because of malformed syntax or invalid parameters.
+      content:
+        application/json:
+          schema:
+            $ref: '#/components/schemas/Error'
+          examples:
+            default:
+              value:
+                errors:
+                  - code: invalid_request
+                    message: The request body failed validation.
+    403-forbidden:
+      description: |
+        Forbidden. The authenticated caller does not have permission to perform this operation.
+      content:
+        application/json:
+          schema:
+            $ref: '#/components/schemas/Error'
+          examples:
+            default:
+              value:
+                errors:
+                  - code: forbidden
+                    message: You do not have permission to access this resource.
+    422-unprocessable-entity:
+      description: |
+        Unprocessable entity. The request was well-formed but was unable to be followed due to semantic errors.
+      content:
+        application/json:
+          schema:
+            $ref: '#/components/schemas/Error'
+          examples:
+            default:
+              value:
+                errors:
+                  - code: unprocessable_entity
+                    message: The request could not be processed due to a semantic error.
+    404-not-found:
+      description: |
+        Not found. The requested resource does not exist or is not visible to the caller.
+      content:
+        application/json:
+          schema:
+            $ref: '#/components/schemas/Error'
+          examples:
+            default:
+              value:
+                errors:
+                  - code: not_found
+                    message: The requested resource was not found.
+x-enable-proxy: true
+x-internal: false