Get Started Free

Dify: connection and validation

Estimated reading time: 5 minutes

Limited coverage · Reviewed 2026-09-07

The installable tool plugin passes actual Dify Plugin SDK 0.10.2 loading and authenticated managed MCP prepare, checkpoint and approved resume. Official CLI 0.6.10 produces its local package.

Connect Dify through the managed companion

Create a workspace for Dify Open Dify setup · Start with the free sample

  1. Create your free workspace and verify your email. On the dashboard, run the local allow/block sample and inspect the saved audit and actual signing status. This requires no model or external target; it does not connect a client or create independently verified proof.
  2. Return to your saved Dify setup. Create its real managed-mcp installation, then download the configuration and local package commands bound to that installation. Agent association is optional. Configuration starts read-only.
  3. Load the creator’s scoped API credential on the controlled companion host and run the one-use connection challenge there. Credentials never belong in a public workflow, model prompt or exported configuration. Recorded credential proof does not attest native installation or a target effect.
  4. Package the matching managed-mcp/clients/dify source with the official dify plugin package command and install that local .difypkg under your deployment’s signature policy. The Python client is included. Configure the provider’s companion endpoint/token and organization/installation fields; start with its connection operation.
  5. Inspect connection from the native client. To execute, bind an authorized registered target and obtain its public signing key independently. Preparation stops for a different human reviewer. Resume needs the exact stored approval, request commitment and explicit confirmation; ambiguous attempts must not be retried blindly.
  6. Refresh the workspace and inspect the server-returned action bound to this installation. A successful connection or copied guide is not execution evidence.

For n8n, Dify and Langflow, the operator supplies a reachable authenticated HTTPS companion endpoint and a separate companion bearer in the client secret store. One companion has one creator and installation; workflow or chat identities do not establish separate delegated users.

Exact local package, credential and native client instructions · Read-only public configuration template

Source paths in those instructions refer to the matching checkout supplied by your deployment operator. No public package or marketplace release is assumed. Free setup remains available; protected execution requires proof.actions and the appropriate role and scopes. Payments are currently unavailable. Provider usage may have separate charges.

Connection acceptance comes before a coverage claim

This distribution profile is separate from native runtime enforcement. Check the exact client version, transport, authentication, and tool surface with the operator. No marketplace listing or automatic interception is implied.

Setup instructions for this profile come from the SDK documentation your deployment operator provides.

  1. Configure a dedicated test connection with minimum scopes. Never paste a runtime secret into a public workflow or repository.
  2. Discover the tools and allow only the intended tool set. Confirm the exact transport supported by your installed client.
  3. Make one harmless managed call. Check denial and revoked credentials; a client that continues after a failed policy hook does not enforce that hook.
  4. Inspect the action ID in Praesidia. Report whether the test covered a managed call, native interception, or observation only.
  • Only explicit tools on the configured Praesidia companion are governed; unrelated native tools remain outside this boundary.
  • Packages are local release candidates. Real API/backend datastore installation-bound acceptance is pending the combined customer run; publication and deployed customer workspaces need separate acceptance.
  • One companion uses one operator-configured creator and installation. It does not infer end-user delegation from a workflow or chat identity.
  • The SDK executes the real plugin against owned fixtures. A deployed Dify server, tenant credential store, signature policy and model workflow have not been exercised.
  • Operation and resume confirmation are operator form inputs. The managed client rejects redirects; the older generic OpenAPI example is outside this tested transport.

Alternative: earlier narrow source example

This separate example is not the managed companion setup above and does not establish an installation-bound connection. Preserve its narrower scope when evaluating it.

Download dify-protected-http.openapi.json · All source instructions

Provide your operator's endpoint, registration, and credential reference. No secret belongs in these files. This example only prepares registered HTTP requests and reads owned checkpoints. It does not approve or resume them. Configuration and isolated fixture checks do not establish a completed client authentication run.

Set up this alternative

Create a custom API tool from dify-protected-http.openapi.json in a disposable Dify workspace. The schema exposes exactly two operations: preparePraesidiaHttpRequest and readPraesidiaHttpCheckpoint. It does not expose approval, resume, revocation, arbitrary target URLs, or native tool interception. The API origin is fixed to https://api.praesidia.ai; an operator using another deployment must edit that origin before import.

Configure API Key authentication in Dify's credential store with header Authorization, Bearer prefix, and the personal caller credential as the value. Do not select query-string authentication or paste the credential into this schema or a workflow prompt. The same real-user, agents:invoke, workflows.execute, and proof.actions requirements described for n8n apply.

The current Dify importer exposes object body parameters as text fields. Supply valid JSON strings in the body and checkpoint fields; the request serializer converts them to JSON objects. For a harmless preparation, set:

{
  "orgId": "REPLACE_WITH_ORGANIZATION_UUID",
  "targetId": "REPLACE_WITH_REGISTERED_TARGET_ID",
  "body": "{\"message\":\"harmless evaluation\"}",
  "checkpoint": "{\"runtime\":\"custom\",\"threadId\":\"REPLACE_WITH_STABLE_RUN_ID\",\"nodeId\":\"dify-checkpoint\"}",
  "description": "Dify request for separate human review"
}

Retain the returned approvalId, actionId, and requestCommitment. Use the read tool with that organization and approval ID to inspect fresh state. Preparation creates a pending request; neither an approved response nor a read dispatches it. A separate caller following the protected HTTP guide must resume the exact approved request. If any request fails or returns an unknown outcome, inspect the existing checkpoint and do not assume success.

Validation on 2026-09-06: OpenAPI 3.0.3 validation passed. The actual Dify parser and Pydantic parameter models at commit dde1d500b5bcbf8a05b37b3615ebaff6219b84b4 were executed in an offline, isolated fixture: two operation IDs, required fields, and exact JSON-object serialization passed. This is not a Dify server import, credential-store, transport, or authentication acceptance run. The generic Dify HTTP client follows redirects; this schema does not override that behavior. Validate the actual deployment's origin, redirect behavior, access, and credential handling before use.

Primary contracts: Dify API tool parser and request serializer and authentication, read 2026-09-06. No marketplace submission is claimed.

Local SDK setup · Inspect evidence · Runtime catalog