General Specification Definitions

This article will briefly introduce common structures in plugin development. During development, it is strongly recommended to read this alongside Basic Concepts of Plugin Development and the Developer Cheatsheet for a better understanding of the overall architecture.

​

Path Specifications

When filling in file paths in Manifest or any yaml files, follow these two specifications depending on the type of file:

• If the target file is a multimedia file such as an image or video, for example when filling in the plugin’s icon, you should place these files in the _assets folder under the plugin’s root directory.
• If the target file is a regular text file, such as .py or .yaml code files, you should fill in the absolute path of the file within the plugin project.

​

Common Structures

When defining plugins, there are some data structures that can be shared between tools, models, and Endpoints. These shared structures are defined here.

​

I18nObject

I18nObject is an internationalization structure that conforms to the IETF BCP 47 standard. Currently, four languages are supported:

• en_US
• zh_Hans
• ja_JP
• pt_BR

​

ProviderConfig

ProviderConfig is a common provider form structure, applicable to both Tool and Endpoint

• name (string): Form item name
• label (I18nObject, required): Following IETF BCP 47
• type (provider_config_type, required): Form type
• scope (provider_config_scope): Optional range, varies based on type
• required (bool): Cannot be empty
• default (any): Default value, only supports basic types float int string
• options (list[provider_config_option]): Options, only used when type is select
• helper (object): Help document link label, following IETF BCP 47
• url (string): Help document link
• placeholder (object): Following IETF BCP 47

​

ProviderConfigOption(object)

• value (string, required): Value
• label (object, required): Following IETF BCP 47

​

ProviderConfigType(string)

• secret-input (string): Configuration information will be encrypted
• text-input (string): Plain text
• select (string): Dropdown
• boolean (bool): Switch
• model-selector (object): Model configuration information, including provider name, model name, model parameters, etc.
• app-selector (object): app id
• tool-selector (object): Tool configuration information, including tool provider, name, parameters, etc.
• dataset-selector (string): TBD

​

ProviderConfigScope(string)

• When type is model-selector
  • all
  • llm
  • text-embedding
  • rerank
  • tts
  • speech2text
  • moderation
  • vision
• When type is app-selector
  • all
  • chat
  • workflow
  • completion
• When type is tool-selector
  • all
  • plugin
  • api
  • workflow

​

ModelConfig

• provider (string): Model provider name containing plugin_id, in the form of langgenius/openai/openai.
• model (string): Specific model name.
• model_type (enum): Enumeration of model types, refer to the Model Design Rules document.

​

NodeResponse

• inputs (dict): Variables that are finally input to the node.
• outputs (dict): Output results of the node.
• process_data (dict): Data generated during node execution.

​

ToolSelector

• provider_id (string): Tool provider name
• tool_name (string): Tool name
• tool_description (string): Tool description
• tool_configuration (dict[str, Any]): Tool configuration information
• tool_parameters (dict[str, dict]): Parameters that need LLM reasoning
  • name (string): Parameter name
  • type (string): Parameter type
  • required (bool): Whether required
  • description (string): Parameter description
  • default (any): Default
  • options (list[string]): Options

​

Related Resources

• Basic Concepts of Plugin Development - Comprehensive understanding of Dify plugin development
• Developer Cheatsheet - Quick reference for common commands and concepts in plugin development
• Tool Plugin Development Details - Understanding how to define plugin information and the tool plugin development process
• Model Design Rules - Understanding the standards for model configuration