{
  "schemaVersion": "1.0",
  "title": "Dify connector changelog",
  "description": "Use this page to decide whether a Dify connector change requires a new artifact, admission record, migration, caller update, or qualification result. It records only changes established from the reviewed Git range.",
  "canonical": "https://getaip.org/docs/connectors/dify/changelog",
  "route": "/docs/connectors/dify/changelog",
  "source": "docs/connectors/dify/changelog.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Connectors",
  "documentType": "Connector",
  "language": "en",
  "downloads": {
    "md": "/docs/download/connectors/dify/changelog.md",
    "txt": "/docs/download/connectors/dify/changelog.txt",
    "json": "/docs/download/connectors/dify/changelog.json",
    "pdf": "/docs/download/connectors/dify/changelog.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Dify connector changelog\ndescription: >-\n  Track the reviewed Dify connector snapshot, compatibility pins, migration\n  boundary, and versioning decisions\nkind: release-reference\naudience: operator\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\nconnector: dify\n---\n\n# Dify connector changelog\n\nUse this page to decide whether a Dify connector change requires a new\nartifact, admission record, migration, caller update, or qualification result.\nIt records only changes established from the reviewed Git range.\n\n> **Release status:** the reviewed snapshot is not a tagged release. The\n> repository tags `034a5206` as `v1.0.0`; the documentation revision is five\n> commits later and still declares workspace version `1.0.0`.\n\nUse full source, artifact, manifest, and provider identities to distinguish\nthese states.\n\n## Identify the exact version\n\n| Identity | Published `v1.0.0` baseline | Reviewed source snapshot |\n|---|---|---|\n| Source commit | `034a520608eea44e6b14e61c34734bd402d989c0` | `97be86e9efedf07ecf1783b03800f683f107fb04` |\n| Source position | Tagged | `v1.0.0-5-g97be86e` |\n| Publication status | Published tag in reviewed repository | Unreleased source in reviewed ancestry |\n| Workspace version | `1.0.0` | `1.0.0` |\n| Native AIP version | `1.0` | `1.0` |\n| Dify surface | One alias per configured app | Alias plus mode-projected app operations and Knowledge operations |\n| Credential model | One connector-wide app key | Per-app keys and independent Knowledge keys, with legacy app-key option |\n| Target placement | Bundled library connector | Separately built and admitted standalone host |\n\nAn operator record for the reviewed snapshot needs the full source commit,\ntree, immutable image digest, manifest digest, connector version ID, release\nID, descriptor hashes, and provider identity.\n\nThe string `1.0.0` cannot replace that identity tuple.\n\n## Reviewed source snapshot\n\nThe entries below describe Dify-relevant differences between tagged `v1.0.0`\nand `97be86e9`. They are source changes, not evidence that an artifact was\nbuilt, published, deployed, or qualified.\n\n### Added\n\n- A frozen catalogue of 79 Dify operations pinned to upstream commit\n  `f8d47616c15d0959f604f6a5e2e1d32d3108991b`.\n- Thirty-three app operation templates with mode-dependent projection.\n- Forty-six workspace-scoped Knowledge operation templates.\n- Per-app and per-Knowledge credential bindings.\n- Bounded query, JSON, multipart, binary, and response handling.\n- Typed Dify failure codes with retry and uncertainty metadata.\n- Composite health across every configured credential.\n- Cluster-safe task correlation through runtime profile state.\n- A dedicated `aip-host-dify` binary and common standalone image path.\n- Registry admission, tenant routing, leases, durable runtime storage, and\n  recovery integration.\n- Standalone image and controlled product-fleet qualification procedures.\n\n### Changed\n\nApp aliases remain under `cap:dify:<app_id>`. Each app now also publishes the\noperation suffixes permitted by its configured mode.\n\n| Mode | App operations | Alias | Total per app |\n|---|---:|---:|---:|\n| `workflow` | 23 | 1 | 24 |\n| `completion` | 19 | 1 | 20 |\n| `chat` | 27 | 1 | 28 |\n| `advanced-chat` | 29 | 1 | 30 |\n| `agent-chat` | 27 | 1 | 28 |\n| `agent` | 27 | 1 | 28 |\n\nEvery configured Knowledge credential publishes 46 capabilities under\n`cap:dify:knowledge:<credential_id>:<operation>`.\n\nThe manifest is now descriptor-dependent. Callers must discover capability\nIDs instead of assuming the tagged baseline's one-capability-per-app surface.\n\n### Credential isolation\n\nThe tagged connector stored one shared API key. The reviewed connector stores\nseparate app keys and separate Knowledge keys.\n\nThe standalone host accepts a legacy global app key only when every app\nintentionally shares it. It cannot be mixed with per-app files and cannot\nauthorize Knowledge operations.\n\nThis is a deployment and secret-ownership migration. It does not change the\npublic identity of an existing app alias by itself.\n\n### Transport and response bounds\n\nThe reviewed provider client requires an HTTPS origin outside loopback,\nrejects credentials and path material, disables authenticated redirects, and\nuses bounded connection and request behavior.\n\nIt enforces query, JSON, upload, response, SSE frame, and event limits.\nCatalogue response kinds select JSON, normalized SSE, or bounded base64 binary\noutput.\n\nAll non-GET catalogue operations require approval and an AIP idempotency key.\nOnly GET operations publish safe retry support.\n\n### Streaming and cancellation durability\n\nApp aliases retain blocking and streaming execution. The reviewed connector\nadds explicit SSE operations and normalizes event kinds, terminal results,\nhuman-input pauses, and provider failures.\n\nRemote task identity is stored without destructive read. Cancellation can\nsurvive restart through instance-scoped profile state in the standalone host.\n\nMissing task identity remains an unconfirmed remote stop. Cancelling an event\nsubscription closes only the local stream and never infers workflow stop.\n\n### Standalone security boundary\n\nThe reviewed topology fixes provider origin, descriptors, key files, connector\nidentity, artifact, manifest, tenant, lifecycle route, and credential revision\noutside Action input.\n\nThese controls describe reviewed source. They do not qualify an arbitrary Dify\ndeployment or make direct provider calls part of AIP.\n\n### Deprecated, removed, or renamed\n\nNo Dify capability is declared deprecated, removed, or renamed in the reviewed\nrange. The operation suffixes and Knowledge domain are additions.\n\nFuture provider aliases or route removals must not be inferred from upstream\nnames. Record them only when reviewed connector source or release policy\ndefines the change and migration.\n\n## Apply the required migration\n\n| Change encountered | Required action | Do not do |\n|---|---|---|\n| Bundled connector to standalone host | Preserve tenant, app, key, Action, task, approval, and idempotency evidence through the fleet migration | Run both mutation paths without a fence |\n| Same version string on a new snapshot | Admit a new immutable connector version with exact source, image, manifest, and release identities | Overwrite an existing record or identify it only as `1.0.0` |\n| Alias-only manifest expands | Refresh discovery, policy, generated clients, expected counts, and catalogue digest | Construct suffixes from provider route names |\n| Shared app key becomes scoped | Create owner-only per-app files and bind each descriptor explicitly | Copy one key into unrelated app or Knowledge scopes |\n| Knowledge is enabled | Add independent workspace descriptors, keys, policy, and 46-capability admission per credential | Reuse an application key |\n| Durable cancellation is enabled | Provision coherent host storage and preserve instance-scoped profile state | Use process memory as restart-safe evidence |\n| Response treatment changes | Revalidate bounds, SSE terminal behavior, binary consumers, and uncertainty handling | Infer treatment only from `Content-Type` |\n| Upstream revision changes | Re-audit methods, paths, schemas, mode support, and exclusions, then requalify | Promote new provider bytes under the old compatibility claim |\n\nStabilize standalone identity and credential isolation before adopting new\nKnowledge mutations or a provider upgrade.\n\n## Retain compatibility pins\n\n| Surface | Reviewed pin |\n|---|---|\n| Connector ID | `dify` |\n| Connector profile | `aip.connector.dify.v1` |\n| Manifest format | `aip-manifest/v1` |\n| Workspace and host version | `1.0.0` |\n| Native AIP version | `1.0` |\n| Dify upstream commit | `f8d47616c15d0959f604f6a5e2e1d32d3108991b` |\n| Frozen operation templates | 33 app and 46 Knowledge |\n| Default provider-response limit | 8 MiB |\n| Maximum configurable response limit | 64 MiB |\n| Standalone host | `aip-host-dify` |\n| Standalone version-ID shape | `cver_dify_1_0_0_<release-id>` |\n\nThe upstream commit identifies reviewed source, not a built Dify image or\ndeployment. Changing provider bytes does not establish compatibility with the\nnew artifact.\n\n## Decide when a new connector version is required\n\nCreate and admit a new immutable connector version when a change affects:\n\n- capability IDs, projection, schemas, contracts, kind, risk, approval, retry,\n  idempotency, or compensation;\n- provider method, path, query, body, multipart, response, event, or status\n  mapping;\n- descriptor semantics, app mode, credential scope, secret handling, URL\n  policy, health probe, or request bounds;\n- task-store namespace, task identity, cancellation certainty, stream\n  terminal behavior, or cleanup;\n- artifact bytes, dependencies, manifest digest, upstream baseline, host\n  lifecycle, or storage behavior.\n\nA documentation clarification alone does not require a connector version. It\nstill needs the source revision that proves the corrected statement.\n\n## Record future entries completely\n\nEach future entry should state:\n\n1. release or explicit unreleased status and UTC review date;\n2. full source commit, tree, and reconstructable dirty state when applicable;\n3. connector, image, manifest, catalogue, release, descriptor, and upstream\n   identities;\n4. added, changed, fixed, security-relevant, deprecated, and removed surfaces;\n5. caller, operator, storage, credential, and provider migration actions;\n6. rollback and compatibility boundary;\n7. exact connector, image, fleet, and live qualification result, or `not_run`;\n8. replacement and removal date only when source defines them.\n\nDo not reconstruct release history from filenames, mutable tags, or source\npresence. Mark unknown history as unknown.\n\n## Related documentation\n\n- [AIP release notes](../../reference/release-notes.md)\n- [Migrate bundled connectors to the fleet](../../guides/migrate-bundled-connectors.md)\n- [Dify connector configuration](reference/configuration.md)\n- [Dify capability index](capabilities/README.md)\n- [Qualify the Dify connector](qualification/README.md)\n",
    "text": "Dify connector changelog\n\nUse this page to decide whether a Dify connector change requires a new\nartifact, admission record, migration, caller update, or qualification result.\nIt records only changes established from the reviewed Git range.\n\nRelease status: the reviewed snapshot is not a tagged release. The\nrepository tags 034a5206 as v1.0.0; the documentation revision is five\ncommits later and still declares workspace version 1.0.0.\n\nUse full source, artifact, manifest, and provider identities to distinguish\nthese states.\n\nIdentify the exact version\n\n| Identity | Published v1.0.0 baseline | Reviewed source snapshot |\n\n| Source commit | 034a520608eea44e6b14e61c34734bd402d989c0 | 97be86e9efedf07ecf1783b03800f683f107fb04 |\n| Source position | Tagged | v1.0.0-5-g97be86e |\n| Publication status | Published tag in reviewed repository | Unreleased source in reviewed ancestry |\n| Workspace version | 1.0.0 | 1.0.0 |\n| Native AIP version | 1.0 | 1.0 |\n| Dify surface | One alias per configured app | Alias plus mode-projected app operations and Knowledge operations |\n| Credential model | One connector-wide app key | Per-app keys and independent Knowledge keys, with legacy app-key option |\n| Target placement | Bundled library connector | Separately built and admitted standalone host |\n\nAn operator record for the reviewed snapshot needs the full source commit,\ntree, immutable image digest, manifest digest, connector version ID, release\nID, descriptor hashes, and provider identity.\n\nThe string 1.0.0 cannot replace that identity tuple.\n\nReviewed source snapshot\n\nThe entries below describe Dify-relevant differences between tagged v1.0.0\nand 97be86e9. They are source changes, not evidence that an artifact was\nbuilt, published, deployed, or qualified.\n\nAdded\n• A frozen catalogue of 79 Dify operations pinned to upstream commit\n  f8d47616c15d0959f604f6a5e2e1d32d3108991b.\n• Thirty-three app operation templates with mode-dependent projection.\n• Forty-six workspace-scoped Knowledge operation templates.\n• Per-app and per-Knowledge credential bindings.\n• Bounded query, JSON, multipart, binary, and response handling.\n• Typed Dify failure codes with retry and uncertainty metadata.\n• Composite health across every configured credential.\n• Cluster-safe task correlation through runtime profile state.\n• A dedicated aip-host-dify binary and common standalone image path.\n• Registry admission, tenant routing, leases, durable runtime storage, and\n  recovery integration.\n• Standalone image and controlled product-fleet qualification procedures.\n\nChanged\n\nApp aliases remain under cap:dify:. Each app now also publishes the\noperation suffixes permitted by its configured mode.\n\n| Mode | App operations | Alias | Total per app |\n\n| workflow | 23 | 1 | 24 |\n| completion | 19 | 1 | 20 |\n| chat | 27 | 1 | 28 |\n| advanced-chat | 29 | 1 | 30 |\n| agent-chat | 27 | 1 | 28 |\n| agent | 27 | 1 | 28 |\n\nEvery configured Knowledge credential publishes 46 capabilities under\ncap:dify:knowledge::.\n\nThe manifest is now descriptor-dependent. Callers must discover capability\nIDs instead of assuming the tagged baseline's one-capability-per-app surface.\n\nCredential isolation\n\nThe tagged connector stored one shared API key. The reviewed connector stores\nseparate app keys and separate Knowledge keys.\n\nThe standalone host accepts a legacy global app key only when every app\nintentionally shares it. It cannot be mixed with per-app files and cannot\nauthorize Knowledge operations.\n\nThis is a deployment and secret-ownership migration. It does not change the\npublic identity of an existing app alias by itself.\n\nTransport and response bounds\n\nThe reviewed provider client requires an HTTPS origin outside loopback,\nrejects credentials and path material, disables authenticated redirects, and\nuses bounded connection and request behavior.\n\nIt enforces query, JSON, upload, response, SSE frame, and event limits.\nCatalogue response kinds select JSON, normalized SSE, or bounded base64 binary\noutput.\n\nAll non-GET catalogue operations require approval and an AIP idempotency key.\nOnly GET operations publish safe retry support.\n\nStreaming and cancellation durability\n\nApp aliases retain blocking and streaming execution. The reviewed connector\nadds explicit SSE operations and normalizes event kinds, terminal results,\nhuman-input pauses, and provider failures.\n\nRemote task identity is stored without destructive read. Cancellation can\nsurvive restart through instance-scoped profile state in the standalone host.\n\nMissing task identity remains an unconfirmed remote stop. Cancelling an event\nsubscription closes only the local stream and never infers workflow stop.\n\nStandalone security boundary\n\nThe reviewed topology fixes provider origin, descriptors, key files, connector\nidentity, artifact, manifest, tenant, lifecycle route, and credential revision\noutside Action input.\n\nThese controls describe reviewed source. They do not qualify an arbitrary Dify\ndeployment or make direct provider calls part of AIP.\n\nDeprecated, removed, or renamed\n\nNo Dify capability is declared deprecated, removed, or renamed in the reviewed\nrange. The operation suffixes and Knowledge domain are additions.\n\nFuture provider aliases or route removals must not be inferred from upstream\nnames. Record them only when reviewed connector source or release policy\ndefines the change and migration.\n\nApply the required migration\n\n| Change encountered | Required action | Do not do |\n\n| Bundled connector to standalone host | Preserve tenant, app, key, Action, task, approval, and idempotency evidence through the fleet migration | Run both mutation paths without a fence |\n| Same version string on a new snapshot | Admit a new immutable connector version with exact source, image, manifest, and release identities | Overwrite an existing record or identify it only as 1.0.0 |\n| Alias-only manifest expands | Refresh discovery, policy, generated clients, expected counts, and catalogue digest | Construct suffixes from provider route names |\n| Shared app key becomes scoped | Create owner-only per-app files and bind each descriptor explicitly | Copy one key into unrelated app or Knowledge scopes |\n| Knowledge is enabled | Add independent workspace descriptors, keys, policy, and 46-capability admission per credential | Reuse an application key |\n| Durable cancellation is enabled | Provision coherent host storage and preserve instance-scoped profile state | Use process memory as restart-safe evidence |\n| Response treatment changes | Revalidate bounds, SSE terminal behavior, binary consumers, and uncertainty handling | Infer treatment only from Content-Type |\n| Upstream revision changes | Re-audit methods, paths, schemas, mode support, and exclusions, then requalify | Promote new provider bytes under the old compatibility claim |\n\nStabilize standalone identity and credential isolation before adopting new\nKnowledge mutations or a provider upgrade.\n\nRetain compatibility pins\n\n| Surface | Reviewed pin |\n\n| Connector ID | dify |\n| Connector profile | aip.connector.dify.v1 |\n| Manifest format | aip-manifest/v1 |\n| Workspace and host version | 1.0.0 |\n| Native AIP version | 1.0 |\n| Dify upstream commit | f8d47616c15d0959f604f6a5e2e1d32d3108991b |\n| Frozen operation templates | 33 app and 46 Knowledge |\n| Default provider-response limit | 8 MiB |\n| Maximum configurable response limit | 64 MiB |\n| Standalone host | aip-host-dify |\n| Standalone version-ID shape | cverdify100 |\n\nThe upstream commit identifies reviewed source, not a built Dify image or\ndeployment. Changing provider bytes does not establish compatibility with the\nnew artifact.\n\nDecide when a new connector version is required\n\nCreate and admit a new immutable connector version when a change affects:\n• capability IDs, projection, schemas, contracts, kind, risk, approval, retry,\n  idempotency, or compensation;\n• provider method, path, query, body, multipart, response, event, or status\n  mapping;\n• descriptor semantics, app mode, credential scope, secret handling, URL\n  policy, health probe, or request bounds;\n• task-store namespace, task identity, cancellation certainty, stream\n  terminal behavior, or cleanup;\n• artifact bytes, dependencies, manifest digest, upstream baseline, host\n  lifecycle, or storage behavior.\n\nA documentation clarification alone does not require a connector version. It\nstill needs the source revision that proves the corrected statement.\n\nRecord future entries completely\n\nEach future entry should state:\n1. release or explicit unreleased status and UTC review date;\n2. full source commit, tree, and reconstructable dirty state when applicable;\n3. connector, image, manifest, catalogue, release, descriptor, and upstream\n   identities;\n4. added, changed, fixed, security-relevant, deprecated, and removed surfaces;\n5. caller, operator, storage, credential, and provider migration actions;\n6. rollback and compatibility boundary;\n7. exact connector, image, fleet, and live qualification result, or notrun;\n8. replacement and removal date only when source defines them.\n\nDo not reconstruct release history from filenames, mutable tags, or source\npresence. Mark unknown history as unknown.\n\nRelated documentation\n• AIP release notes (../../reference/release-notes.md)\n• Migrate bundled connectors to the fleet (../../guides/migrate-bundled-connectors.md)\n• Dify connector configuration (reference/configuration.md)\n• Dify capability index (capabilities/README.md)\n• Qualify the Dify connector (qualification/README.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "549f4cafc93638590c1c0b9a1855f0f1c366aacc8ddfaff8c19f6e3447a232a5"
  }
}