Can Trigger Events Identify the End_User in My Database or Do I Need to Create a Unique Webhook URL for Each Client?

Help
1

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

Hi all, just newly reading through all the docs today. I’m solely interested in the trigger->webhook flow via the sdk (worflowless setup). Would trigger events provide sufficient information to identify the end_user in my own database, or would you have to create some kind of unique webhook url per client on my side and do it that way? Seems like the trigger.event.context is geared towards workflows without that context?

2

Will you be triggering the webhook via the SDK from your application? As in, are you in control of that code?

3

Can you tell me more about your use case? What’s the triggering event, or what is consuming the emitted event?

4

Calling deploy trigger endpoint passing only a webhook_url - no workflow url using connect.

As I understand it this will allow me to collect events from app events out there on behalf of users?

5

I was expecting to pass my applications webhook

6

Got it, yea that’s right. Actually we don’t include metadata related to the external user ID in the payload currently, but that’s on the near term roadmap to add.

7

I see you can create paragon ones as well, but I don’t know what that’s for/why I’d want that (unless it’s a node in a workflow or something)

8

In the immediate interim you’d have to map webhook → user on your end, but I expect we’ll address that gap soon

9

paragon
… Pipedream? :wink:

10

woops lol. gawd, it’s not like I like them!

11

Thanks for the help!

12

Actually one more thing:

  • Is there a way to introspect the components event payloads (aka trigger payloads if I understand correctly that a trigger is a component)?
13

As in, you want to understand the shape of the event that a trigger emits?

14

Yes - the payload shape. Same with inputs to actions.

15

Not easily unfortunately, though that’s a pretty consistent ask. Both are tricky, since the output event shape from a source is often dependent on the inputs, and similarly with actions, we have a lot of dynamic and dependent props that render certain inputs based on the values that the user defines.

16

Right, guess I can scrape the pipedream repo as one option.

17

That’s not the issue. We expose the component definition for every trigger and action via our API, but it’s not always the “fully unwrapped” or flattened schema, due to dynamic props.

18

https://pipedream.com/docs/connect/api/#retrieve-a-component

19

Maybe I’m confused. Source/Trigger Components are essentially receivers/syncers for 3rd party events right? Props are how you configure them to do the sync, but the event payload they receive is distinct?

20

While I have you (thank you this is very helpful) - with the new MCP servers, can you create server urls for end customers thus calling MCP on their behalf? Or how does that work?