What is the Most Efficient Way to Catch a Single Webhook and Start 10 Different Workflows?

Help
1

This topic was automatically generated from Slack. You can find the original thread here.

Hey,

Wondering the most efficient way catch a single webhook and then start 10 different workflows?

2

Wondering the most efficient way catch a single webhook and then start 10 different workflows?

3

To efficiently catch a single webhook and start 10 different workflows in Pipedream, you can follow these steps: 1. Create a Primary Workflow: Set up a primary workflow that will act as the entry point for the webhook. This workflow will receive the webhook event. 2. Emit Events to Other Workflows: Within this primary workflow, use the Pipedream REST API to emit events to other workflows. You can configure each of these events to trigger a different workflow. 3. Use the Emit Event Action: In the primary workflow, add an action to emit an event for each of the 10 workflows you want to trigger. You can use the $.send.http method or the Pipedream REST API to send the event data to each workflow’s unique webhook URL. Here’s a basic outline of how you might set this up in a Node.js code step within the primary workflow: ```
export default defineComponent({ async run({ steps, $ }) { const workflows = [ “https://your-webhook-url-1”, “https://your-webhook-url-2”, // Add all 10 webhook URLs here ]; const eventData = steps.trigger.event; // The data from the incoming webhook for (const url of workflows) { await $.send.http({ method: “POST”, url, data: eventData, }); } }, });

4

perfect so loop through webhook URL’s

5

and send to aech

6

each

7

Definitely works, can also do it this way: GitHub

8

nice, might do that

9

And there’s even a prebuilt action for it. I think one difference is $.flow.trigger will wait for each “child workflow” to complete its execution before moving to the next step or part of your code in the “parent workflow”.

10

Whereas Pi’s suggestion is just fire and forget

11

probs best to fire and forget. althought might play with flow.trigger and see how it operates

12

It’s part of the underlying API that powers the control flow features like if/else, switch, and parallel

13

that makes sense. the benefit would be to see the flow completion in one workflow i guess (which is interesting)