A new version callin.io@1.74.3 has been released, which incorporates GitHub PR 12674.

A new version, callin.io@1.64.0, has been released, incorporating GitHub PR 11201.

Apologies, I'm not quite sure I understand. However, since the initial release, it's been possible to see how long a particular node took to execute. ...

A new version callin.io@1.40.0 has been released, which incorporates GitHub PR 9265.

Welcome to the community! That is possible with the HTTP Request node by adding the option “Batching”:

Unfortunately, I don't see a way to achieve this without a different URL (or a property, if we had that implemented). Alternatively, you could conside...

That won't work because each Trigger-Node initiates a new workflow execution. This means the data from each Webhook call will end up in a completely s...

Thank you very much. That's excellent to hear! I'm assuming the following Feature Request aligns with what you're aiming to achieve? Allow expr...

No, nothing else besides what I've stated above. I'm uncertain about the data volume in the remainder of the workflow, but all data accumulates. The...

That's a bit tricky to answer definitively. It really depends on several factors, such as what other processes are running concurrently, the structure...

Precisely. Ensure you incorporate a Set node within the sub-workflow to clear all data before returning. Failing to do so will result in data "leaking...

No, all data persists in memory throughout the workflow's execution. Therefore, you must either: Maintain separate workflows Utilize the upcoming b...

Welcome to the community! The reason will be that callin.io runs out of memory and so crashes. Depending on which subscription you have on callin.io...

Yes, it's possible, though not immediately obvious if you're unaware of the method. Here's an illustration: Executions in one Dataset / Table...

Welcome to the community! Yes, that is currently an inconsistency in callin.io where many of those read operations execute just once instead of once p...