Is there a way to trigger a single Pipedream workflow from multiple different Typeform forms?

Help
,
1

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

Bharat Kilaru : Hi there! I’m new to Pipedream. We want to have the source trigger be multiple different Typeforms so we can take any responses from and trigger data creation in Firebase Firestore. Is there a way to listen to multiple different Typeforms? Thanks

2

Dylan Sather (Pipedream) : welcome! There are a couple of options here:

• You can create multiple Typeform sources, each of which would receive the data for specific form. Then you can use our subscriptions API to link each of those sources to a single workflow: https://docs.pipedream.com/api/rest/#subscriptions . Currently, linking multiple triggers to a workflow via the UI isn’t supported, but we’re tracking support for that here
• You could create one Typeform source to link your first form to a single Pipedream event source, then manually add webhook subscriptions within Typeform to point each of your other forms to the same URL tied to the Pipedream event source. The source would receive submissions for all forms, which could trigger your workflow
Let me know if you think either option would work for you.

3

Bharat Kilaru : Thanks! The second option sounds like it would work perfectly since we could use the Typeform API to create new forms that include this webhoook subscription.

I created the one Typeform source for the first form. The URL tied to this is the one listed as Endpoint correct?

image.png

4

Dylan Sather (Pipedream) : That’s correct. When you created the source, Pipedream created a subscription webhook in your Typeform account tied to that form, so you should see the same URL in Typeform, in your webhook settings

5

Dylan Sather (Pipedream) : By the way, you could create a Pipedream event source that listens for new forms (there’s not a webhook for that, but you could poll the GET /forms endpoint every N minutes). The event source would emit an event when you create a new form.

Then that event source could trigger a Pipedream workflow that creates a webhook subscription
tied to your “master” URL endpoint.

6

Dylan Sather (Pipedream) : happy to show you how the event source creation process works, if you wanted to automate end to end

7

Dylan Sather (Pipedream) : I guess if you’re automating the form creation process via API it’s not necessary, but just wanted to share in case that helps!

8

Bharat Kilaru : > you should see the same URL in Typeform
Ah perfect. Just saw that that the first form webhook is shown in the Typeform form.

9

Bharat Kilaru : > you could poll the GET /forms endpoint every N minutes…
> happy to show you how the event source creation process works, if you wanted to automate end to end
This would be really cool actually. Because I was just about to ask if I could use Pipedream to setup a cron job that polls Firebase and sends emails out based on inputs

10

Bharat Kilaru : I was going to use Firebase Functions for this, but am really enjoying the Pipedream experience so far

11

Dylan Sather (Pipedream) : That’s great! Yeah you have a couple of options here, too:

• You could start with a workflow that uses the Cron Scheduler trigger and polls Firebase, sending an email
• You could create an event source that polls Firebase on a schedule, emitting new events, and that can trigger a Pipedream workflow that sends the email. You can learn more about the source development process here: pipedream/QUICKSTART.md at master · PipedreamHQ/pipedream · GitHub
In general I like workflows for simple scripts that are run on a schedule, HTTP request, or email. On the other hand, event sources are great when you want the event retrieval / emitting logic to be de-coupled from a workflow. For example, if you find yourself commonly wanting to run code on new items in Firebase, it might make sense to separate that into a Firebase trigger that you can reuse.

Let me know if that makes sense.

12

Bharat Kilaru : Awesome. Will try option 1: the workflow setup and give it a shot. Will follow up if I run into an issue if that’s cool. Thanks again for the fast help. Really appreciate it

13

Dylan Sather (Pipedream) : np good luck, reach out anytime

14

Bharat Kilaru : Quick follow up issue - when adding the default Firebase Admin step, the step successfully works a few times, but on repeat triggers provides the error:

ErrorThe default Firebase app already exists. This means you called initializeApp() more than once without providing an app name as the second argument. In most cases you only need to call initializeApp() once. But if you do want to initialize multiple apps, pass a second argument to initializeApp() to give each app a unique name.
15

Dylan Sather (Pipedream) : Would you mind sharing your workflow with dylan@pipedream.com?

16

Bharat Kilaru : Yep, done :white_check_mark:

17

Dylan Sather (Pipedream) : could you try passing any string as to the second arg of initializeApp()?

admin.initializeApp({
  credential: admin.credential.cert({
    projectId,
    clientEmail,
    privateKey: formattedPrivateKey,
  })
}, 'name')
18

Dylan Sather (Pipedream) : If that doesn’t work, you can also try something like:

if (!admin.apps.length) {
  admin.initializeApp({
    credential: admin.credential.cert({
      projectId,
      clientEmail,
      privateKey: formattedPrivateKey,
    })
  })
}
19

Dylan Sather (Pipedream) : Any code within a step shouldn’t be shared across invocations, but I’d like to see if that works

20

Dylan Sather (Pipedream) : The Firebase app might be caching something to disk and reading it on initialize. You do share the same disk across invocations