Skip to main content

Prerequisites

  • Dify Plugin CLI
  • Basic Python programming skills and understanding of object-oriented programming
  • Familiarity with the API documentation of the model provider you want to integrate

Step 1: Create and Configure a New Plugin Project

Initialize the Project

Choose Model Plugin Template

Select the LLM type plugin template from the available options. This template provides a complete code structure for model integration.
Plugin Type: LLM

Configure Plugin Permissions

For a model provider plugin, configure the following essential permissions:
  • Models: Base permission for model operations.
  • LLM: Permission for large language model functionality.
  • Storage: Permission for file operations (if needed).
Model Plugin Permission

Directory Structure Overview

After initialization, your plugin project has a directory structure similar to this (assuming a provider named my_provider that supports LLM and Embedding):

Step 2: Understand Model Configuration Methods

Dify supports two model configuration methods that determine how users interact with your provider’s models:

Predefined Models (predefined-model)

Predefined models require only unified provider credentials. Once a user configures their API key or other authentication details for the provider, they can immediately access all predefined models. Example: The OpenAI provider offers predefined models like gpt-3.5-turbo-0125 and gpt-4o-2024-05-13. A user only needs to configure their OpenAI API key once to access all these models.

Custom Models (customizable-model)

Custom models require additional configuration for each model instance. This approach is useful when models need individual parameters beyond the provider-level credentials. Example: Xinference supports both LLM and Text Embedding, but each model has a unique model_uid. Users must configure this model_uid separately for each model they want to use. The two configuration methods can coexist within a single provider. For instance, a provider might offer some predefined models while also allowing users to add custom models with specific configurations.

Step 3: Create Model Provider Files

Creating a new model provider involves two main components:
  • Provider configuration YAML file: Defines the provider’s basic information, supported model types, and credential requirements.
  • Provider class implementation: Implements authentication validation and other provider-level functionality.

3.1 Create the Model Provider Configuration File

The provider configuration is a YAML file that declares the provider’s basic information, supported model types, configuration methods, and credential rules. Place it in the root directory of your plugin project. Here’s an annotated example of the anthropic.yaml configuration file:

Custom Model Configuration

If your provider supports custom models, add a model_credential_schema section defining the additional fields users must configure for each model. This is typical for providers that support fine-tuned models or require model-specific parameters. Here’s an example from the OpenAI provider:
For the complete model provider YAML specification, see Model Schema.

3.2 Write the Model Provider Code

Next, create a Python file for your provider class in the /provider directory, named after your provider (e.g., anthropic.py). The provider class must inherit from ModelProvider and implement at least the validate_provider_credentials method:
Dify calls validate_provider_credentials whenever a user saves provider credentials, so it should:
  1. Attempt to validate the credentials by making a simple API call.
  2. Return silently if validation succeeds.
  3. Raise CredentialsValidateFailedError with a helpful message if validation fails.

For Custom Model Providers

For providers that exclusively use custom models (where each model requires its own configuration), you can implement a simpler provider class. For example, with Xinference:

Step 4: Implement Model-Specific Code

After setting up your provider, implement the model-specific code that handles API calls for each model type you support. This involves:
  1. Creating model configuration YAML files for each specific model.
  2. Implementing the model type classes that handle API communication.
For detailed instructions, see:

4.1 Define Model Configuration (YAML)

For each specific model, create a YAML file in the appropriate model type directory (e.g., models/llm/) to define its properties, parameters, and features. Example (claude-3-5-sonnet-20240620.yaml):

4.2 Implement Model Calling Code (Python)

Create a Python file for each model type you support (e.g., llm.py in the models/llm/ directory). This class handles API communication, parameter transformation, and result formatting. Here’s an example implementation structure for an LLM:
The most important method to implement is _invoke, which handles the core API communication. This method should:
  1. Transform Dify’s standardized inputs into the format required by the provider’s API.
  2. Make the API call with proper error handling.
  3. Transform the API response into Dify’s standardized output format.
  4. Handle both streaming and non-streaming modes.

Step 5: Debug and Test Your Plugin

Dify supports remote debugging, so you can test your plugin during development:
  1. In your Dify instance, go to Plugin Management and click Debug Plugin to get your debug key and server address.
  2. Configure your local environment with these values in a .env file:
  3. Run your plugin locally with python -m main and test it in Dify.

Step 6: Package and Publish

When your plugin is ready:
  1. Package it using the scaffolding tool:
  2. Test the packaged plugin locally before submitting.
  3. Submit a pull request to the Dify official plugins repository.
For more details on the publishing process, see the Publishing Overview.

Reference Resources

Last modified on July 2, 2026