langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 12:05:30 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Proposal: Add output structure in parameters api #15700

New Issue
Closed
opened 2026-02-21 19:22:58 -05:00 by yindo · 3 comments
yindo commented 2026-02-21 19:22:58 -05:00
Owner
Copy Link
Copy Source

Originally created by @xinlmain on GitHub (Jul 27, 2025).

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

When integrating a Dify workflow into an external system — such as a batch scheduler that periodically triggers workflows — it’s essential for that system to understand the workflow’s input and output structures. This information enables proper execution and result handling.

🌐 Current Integration Pattern

In typical scenarios, we want to provide only a Dify application URL to the external system. Using that URL, we can call Dify’s public web APIs to retrieve workflow information and trigger executions — all without requiring login credentials.

Currently, we’re able to obtain the user_input_form from the /parameters API, which gives us the structure of the workflow’s inputs.

❗️Problem
• The workflow’s output structure is not available via any unauthenticated API;
• This makes it impossible for an external system to anticipate the output format when invoking a workflow;
• Without login, there’s no way to programmatically retrieve this information, creating a significant limitation for integration use cases.

✅ Suggested Solution

To address this issue, I propose either of the following:
1. Extend the existing /parameters API to include the output structure of the workflow;
2. Or, introduce a new unauthenticated API endpoint specifically for exposing output schema.

2. Additional context or comments

No response

3. Can you help us with this feature?

  • I am interested in contributing to this feature.
Originally created by @xinlmain on GitHub (Jul 27, 2025). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] Please do not modify this template :) and fill in all the required fields. ### 1. Is this request related to a challenge you're experiencing? Tell me about your story. When integrating a Dify workflow into an external system — such as a batch scheduler that periodically triggers workflows — it’s essential for that system to understand the workflow’s input and output structures. This information enables proper execution and result handling. 🌐 Current Integration Pattern In typical scenarios, we want to provide only a Dify application URL to the external system. Using that URL, we can call Dify’s public web APIs to retrieve workflow information and trigger executions — all without requiring login credentials. Currently, we’re able to obtain the user_input_form from the /parameters API, which gives us the structure of the workflow’s inputs. ❗️Problem • The workflow’s output structure is not available via any unauthenticated API; • This makes it impossible for an external system to anticipate the output format when invoking a workflow; • Without login, there’s no way to programmatically retrieve this information, creating a significant limitation for integration use cases. ✅ Suggested Solution To address this issue, I propose either of the following: 1. Extend the existing /parameters API to include the output structure of the workflow; 2. Or, introduce a new unauthenticated API endpoint specifically for exposing output schema. ### 2. Additional context or comments _No response_ ### 3. Can you help us with this feature? - [x] I am interested in contributing to this feature.
yindo added the 💪 enhancementstale labels 2026-02-21 19:22:58 -05:00
yindo closed this issue 2026-02-21 19:22:58 -05:00
yindo commented 2026-02-21 19:22:58 -05:00
Author
Owner
Copy Link
Copy Source

@QuantumGhost commented on GitHub (Aug 6, 2025):

First, thank you for your contribution.

However, "output" is not actually a form in the traditional sense.

More importantly, there's a core issue here: Workflow execution can follow multiple branches, and different branches may reach completely different End nodes. There doesn't seem to be a particularly good way to describe this scenario. (The current implementation in https://github.com/langgenius/dify/pull/23012/files simply appends all outputs to a single array.)

I think using an array to represent outputs from multiple different End nodes is acceptable, but each array element should include its corresponding End node ID, so that callers can understand the mapping relationship between End nodes and output schemas.

Another consideration is: since this is primarily for communication with external systems, would using JSON Schema as the mechanism to describe End output structure be better than directly using Dify's internal mechanisms?

While I find JSON Schema quite complex, in this specific scenario, we could retain only field names and type information, which wouldn't be overly complex. Moreover, JSON Schema is a public standard supported by many libraries and frameworks, eliminating the need to reinvent the wheel with our own implementation.

@QuantumGhost commented on GitHub (Aug 6, 2025): First, thank you for your contribution. However, "output" is not actually a form in the traditional sense. More importantly, there's a core issue here: Workflow execution can follow multiple branches, and different branches may reach completely different End nodes. There doesn't seem to be a particularly good way to describe this scenario. (The current implementation in https://github.com/langgenius/dify/pull/23012/files simply appends all outputs to a single array.) I think using an array to represent outputs from multiple different End nodes is acceptable, but each array element should include its corresponding End node ID, so that callers can understand the mapping relationship between End nodes and output schemas. Another consideration is: since this is primarily for communication with external systems, would using JSON Schema as the mechanism to describe End output structure be better than directly using Dify's internal mechanisms? While I find JSON Schema quite complex, in this specific scenario, we could retain only field names and type information, which wouldn't be overly complex. Moreover, JSON Schema is a public standard supported by many libraries and frameworks, eliminating the need to reinvent the wheel with our own implementation.
yindo commented 2026-02-21 19:22:58 -05:00
Author
Owner
Copy Link
Copy Source

@xinlmain commented on GitHub (Aug 7, 2025):

@QuantumGhost Thanks for the comments!

I think using an array to represent outputs from multiple different End nodes is acceptable, but each array element should include its corresponding End node ID, so that callers can understand the mapping relationship between End nodes and output schemas.

I agree. I will seek to add some structure to describe this.

since this is primarily for communication with external systems, would using JSON Schema as the mechanism to describe End output structure be better than directly using Dify's internal mechanisms?

Yeah.. we did use JSON Schema in our 'external system', and we currently perform the translation in that 'external system'. As this api mainly serves for the single and batch run from frontend, I don't want to make breaking changes, just trying to add output fields, following the input field formats.

Thanks again, looking forward to hearing your thoughts.

@xinlmain commented on GitHub (Aug 7, 2025): @QuantumGhost Thanks for the comments! > I think using an array to represent outputs from multiple different End nodes is acceptable, but each array element should include its corresponding End node ID, so that callers can understand the mapping relationship between End nodes and output schemas. I agree. I will seek to add some structure to describe this. > since this is primarily for communication with external systems, would using JSON Schema as the mechanism to describe End output structure be better than directly using Dify's internal mechanisms? Yeah.. we did use JSON Schema in our 'external system', and we currently perform the translation in that 'external system'. As this api mainly serves for the single and batch run from frontend, I don't want to make breaking changes, just trying to add output fields, following the input field formats. Thanks again, looking forward to hearing your thoughts.
yindo commented 2026-02-21 19:22:58 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Sep 8, 2025):

Hi, @xinlmain. I'm Dosu, and I'm helping the Dify team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You suggested enhancing the Dify API by including workflow output structures in the /parameters endpoint or a new unauthenticated API for better external integration.
  • The maintainer noted challenges due to multiple workflow branches producing different outputs and proposed using arrays with End node IDs and JSON Schema to represent output structures.
  • You agreed with adding structured output schema representation and currently handle JSON Schema translation externally.
  • Both sides aligned on improving output schema representation while avoiding breaking changes.
  • The issue was resolved with agreement on the approach to enhance the API accordingly.

Next Steps:

  • Please confirm if this enhancement is still relevant or if you have any further feedback on the latest version of Dify by commenting here.
  • Otherwise, I will automatically close this issue in 15 days.

Thanks for your understanding and contribution!

@dosubot[bot] commented on GitHub (Sep 8, 2025): Hi, @xinlmain. I'm [Dosu](https://dosu.dev), and I'm helping the Dify team manage their backlog and am marking this issue as stale. **Issue Summary:** - You suggested enhancing the Dify API by including workflow output structures in the /parameters endpoint or a new unauthenticated API for better external integration. - The maintainer noted challenges due to multiple workflow branches producing different outputs and proposed using arrays with End node IDs and JSON Schema to represent output structures. - You agreed with adding structured output schema representation and currently handle JSON Schema translation externally. - Both sides aligned on improving output schema representation while avoiding breaking changes. - The issue was resolved with agreement on the approach to enhance the API accordingly. **Next Steps:** - Please confirm if this enhancement is still relevant or if you have any further feedback on the latest version of Dify by commenting here. - Otherwise, I will automatically close this issue in 15 days. Thanks for your understanding and contribution!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label stale 💪 enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#15700
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?