Feature Request: Throttle/Debounce Option for HTTP Request + Preserve Input Data (Telegram Example)

Hello n8n Team and Community,

I am requesting two related features for the HTTP Request node when handling Telegram methods like /sendChatAction.

1. Feature Request: Throttle/Debounce Option

Scenario:
I want to use the /sendChatAction method (e.g., typing) right before a /sendMessage node to simulate the bot is typing.

The Problem:
If the input to the /sendChatAction HTTP Request node contains many separate payloads, the node executes for each payload. This results in an unnecessary flood of API calls to Telegram, where only a single typing action is needed before the message is sent.

The Request:
Please add an optional “Throttle” or “Debounce” setting to the HTTP Request node (or a suitable utility node) to process many incoming items as a single API call when the action is idempotent (like a sendChatAction).


2. Feature Request: Data Preservation & Wait Duration

Scenario:
After the /sendChatAction node, the workflow needs the original input data to continue to the next action (the /sendMessage node).

The Problem:

  1. The sendChatAction node only outputs a simple success response ([ { "ok": true, "result": true } ]), causing the original, necessary payloads to be lost for the subsequent nodes.
  2. To properly show the typing action, a separate Wait node must be added, which breaks the flow simplicity.

The Request:

  1. Preserve Input Data: Add an option to “Pass Through” the original input data as the primary output, even after a successful execution, instead of replacing it with the node’s simple API response.

  2. Built-in Wait: Consider incorporating an optional “Duration” setting into such utility nodes (or the HTTP Re

    quest node for specific idempotent actions) to introduce a small, built-in wait (e.g., 2-3 seconds) before passing the data to the next node, ensuring the typing action is visible without needing a separate Wait node.

Thank you for considering these additions!

1 Like