langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-08-24 22:11:36 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Start node: Allow accessing incoming HTTP request headers, query parameters, and JSON body #20355

New Issue
Closed
opened 2026-02-21 20:07:00 -05:00 by yindo · 4 comments
yindo commented 2026-02-21 20:07:00 -05:00
Owner
Copy Link
Copy Source

Originally created by @r-hashi01 on GitHub (Nov 17, 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.

Yes.
When a workflow is triggered through the Dify API, the Start node only receives the user-input fields defined inside Dify, and cannot access the actual HTTP request that triggered the workflow.

In many real integrations, external systems send important information in:

  • HTTP headers (e.g., X-Customer-Id, feature flags, tenant IDs)
  • Query parameters
  • Raw JSON body
  • Request metadata (IP, user agent, timestamp)

Since the Start node cannot access any of this, the workflow and LLM cannot behave dynamically based on the caller context.
This creates a significant limitation for building system-to-system integrations or webhook-style automations where the incoming request structure cannot be pre-flattened into Dify’s limited input field schema.

This gap makes it impossible to handle real-world payloads or pass necessary data to the next nodes or the LLM.

2. Additional context or comments

This feature is especially important for real-world integrations where external services send structured events or metadata through headers or JSON payloads.

Typical scenarios include:

  • Webhooks from CRM, ERP, or e-commerce systems
  • Multi-tenant platforms that rely on headers to identify the caller
  • Backend services that send contextual JSON data for the agent to process
  • Event notifications where the event type is not part of the “user input text”
  • API integrations where the request body contains nested, complex objects

Other workflow/orchestration tools (such as n8n, Zapier, LangChain agents, Make.com) allow the trigger/start node to access the full incoming HTTP request.
Adding similar capabilities to Dify would dramatically expand its usefulness and flexibility, particularly for backend automation and B2B integrations.

This request is not related to logging or debugging; the goal is to allow the workflow and LLM to use relevant structured input data safely and intentionally.

3. Can you help us with this feature?

  • I am interested in contributing to this feature.
Originally created by @r-hashi01 on GitHub (Nov 17, 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. Yes. When a workflow is triggered through the Dify API, the Start node only receives the user-input fields defined inside Dify, and cannot access the actual HTTP request that triggered the workflow. In many real integrations, external systems send important information in: - HTTP headers (e.g., X-Customer-Id, feature flags, tenant IDs) - Query parameters - Raw JSON body - Request metadata (IP, user agent, timestamp) Since the Start node cannot access any of this, the workflow and LLM cannot behave dynamically based on the caller context. This creates a significant limitation for building system-to-system integrations or webhook-style automations where the incoming request structure cannot be pre-flattened into Dify’s limited input field schema. This gap makes it impossible to handle real-world payloads or pass necessary data to the next nodes or the LLM. ### 2. Additional context or comments This feature is especially important for real-world integrations where external services send structured events or metadata through headers or JSON payloads. Typical scenarios include: - Webhooks from CRM, ERP, or e-commerce systems - Multi-tenant platforms that rely on headers to identify the caller - Backend services that send contextual JSON data for the agent to process - Event notifications where the event type is not part of the “user input text” - API integrations where the request body contains nested, complex objects Other workflow/orchestration tools (such as n8n, Zapier, LangChain agents, Make.com) allow the trigger/start node to access the full incoming HTTP request. Adding similar capabilities to Dify would dramatically expand its usefulness and flexibility, particularly for backend automation and B2B integrations. This request is not related to logging or debugging; the goal is to allow the workflow and LLM to use relevant structured input data safely and intentionally. ### 3. Can you help us with this feature? - [x] I am interested in contributing to this feature.
yindo added the 🌊 feat:workflow label 2026-02-21 20:07:00 -05:00
yindo closed this issue 2026-02-21 20:07:00 -05:00
yindo commented 2026-02-21 20:07:00 -05:00
Author
Owner
Copy Link
Copy Source

@kurokobo commented on GitHub (Nov 17, 2025):

Have you tried the webhook trigger function?
https://docs.dify.ai/en/guides/workflow/node/webhook-trigger

@kurokobo commented on GitHub (Nov 17, 2025): Have you tried the webhook trigger function? https://docs.dify.ai/en/guides/workflow/node/webhook-trigger
yindo commented 2026-02-21 20:07:00 -05:00
Author
Owner
Copy Link
Copy Source

@kurokobo commented on GitHub (Nov 17, 2025):

Ah, sorry, I missed the fact that you're from LangGenius.
So do you want something other than the trigger feature?

@kurokobo commented on GitHub (Nov 17, 2025): Ah, sorry, I missed the fact that you're from LangGenius. So do you want something other than the trigger feature?
yindo commented 2026-02-21 20:07:00 -05:00
Author
Owner
Copy Link
Copy Source

@r-hashi01 commented on GitHub (Nov 17, 2025):

@kurokobo
There was feedback that when calling an app via API or through a chatbot, users want to view the HTTP request details in a way that is not visible to anyone else.

Right now, it’s inconvenient that this information can only be checked through the Trigger feature.

I’ll leave it to you to decide whether we should address this.

@r-hashi01 commented on GitHub (Nov 17, 2025): @kurokobo There was feedback that when calling an app via API or through a chatbot, users want to view the HTTP request details in a way that is not visible to anyone else. Right now, it’s inconvenient that this information can only be checked through the Trigger feature. I’ll leave it to you to decide whether we should address this.
yindo commented 2026-02-21 20:07:00 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Dec 18, 2025):

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

Issue Summary:

  • You requested enhancing the Start node to access full HTTP request details including headers, query parameters, raw JSON body, and metadata.
  • This enhancement aims to improve real-world integrations and webhook automations.
  • I acknowledged the existing webhook trigger feature but recognized your need for additional capabilities.
  • You clarified the importance of users privately viewing HTTP request details when calling apps via API or chatbot.
  • The issue remains unresolved and is pending a decision from the maintainers.

Next Steps:

  • Please let me know if this issue is still relevant to the latest version of Dify by commenting here to keep the discussion open.
  • Otherwise, this issue will be automatically closed in 15 days.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Dec 18, 2025): Hi, @r-hashi01. 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 requested enhancing the Start node to access full HTTP request details including headers, query parameters, raw JSON body, and metadata. - This enhancement aims to improve real-world integrations and webhook automations. - I acknowledged the existing webhook trigger feature but recognized your need for additional capabilities. - You clarified the importance of users privately viewing HTTP request details when calling apps via API or chatbot. - The issue remains unresolved and is pending a decision from the maintainers. **Next Steps:** - Please let me know if this issue is still relevant to the latest version of Dify by commenting here to keep the discussion open. - Otherwise, this issue will be automatically closed in 15 days. Thank you 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 🌊 feat:workflow
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#20355
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?