I’m integrating an app with Paddle, a payment processor that, unlike Stripe, doesn’t support specifying endpoints for each individual webhook. All I’m working with is a single field which says “URL for receiving webhook alerts” and then selecting which alerts I want to subscribe to:
Back in Bubble’s Settings > API, I activated “This app exposes a Workflow API” and copied the “Workflow API root URL” over into Paddle’s URL for receiving webhook alerts field visible in the pic above. I then set up my endpoints in Backend Workflows using automatic detection of parameters:
Now, where the problem begins is when this gets called in the actual app context — i.e. when the user creates a new subscription through the app – as Paddle’s webhook hits the root URI instead of the subscription_created endpoint I created:
Any ideas how to fix this? I feel like it’s probably something stupidly simple that I overlooked… I feel like it may have something to do with me not identifying the webhook manually in Bubble. To quote Paddle’s documentation…
I haven’t used Paddle in the past so I might be wrong here, but why does the URL not include subscription_created as you did in the simulator? From my understanding it’s trying to pass data to an endpoint that doesn’t exist
@ambroisedlg I haven’t, because I wouldn’t be able to use other webhooks such as subscription_cancelled or subscription_updated in that case. Though to be fair, I can’t use anything right now as nothing works.
@chaostorm tell me if I’m wrong but from my understanding Paddle only lets you setup one webhook right? If that’s the case there should be an “event type” field in the received JSON for your app to recognize which type of event it is (subscription_created, subscription_cancelled and so on). It there isn’t I don’t see how you could have multiple events with one webhook tbh
So I’m thinking you could use your endpoint in Bubble called “subscription_created” (or you could rename it to any other name), then have conditions on workflow actions depending on the “event type” field
@ambroisedlg You are the best! I’ve just restructured the backend so that there’s only one endpoint in Bubble, which handles business logic differently depending on what the webhook event type is and then updated Paddle to use that instead of the root URI - and everything works just fine now. Thanks a ton!
Hey was wondering if the different “event types” passed your endpoint a different JSON payload each time? And if so, how did you handle that scenario? Did you pass the JSON payload to another endpoint?
@felix1 In my case, all webhooks hit the same endpoint set up to accept different sorts of JSON payloads. See Paddle’s Subscription Alerts documentation for which key-value pairs are required and which are optional.
Once you set up the endpoint that successfully captures the webhook data, proceed to set up individual workflow actions that fire up based on the event type of the webhook like this:
I’m working with the Twilio Conversations API. It’s very similar to this Paddle thread in that the Twilio Conversations API sends a variety of webhooks to the same URL.
I understand using conditions to recognize EventTypes for each webhook, which is the solution given in this thread.
I don’t understand how you account for the different data that comes with each unique webhook in each unique workflow step.
If you look at the two screenshots, one is to add data to a conversation and the other is to add a “Body” value when the addMessage hook comes in.
When the endpoint autodetects an incoming hook, it settles on that payload. When another hook comes with a different payload, it’s making some of the workflow steps error.
I’ve just restructured the backend so that there’s only one endpoint in Bubble, which handles business logic differently depending on what the webhook event type is and then updated Paddle to use that instead of the root URI - and everything works just fine now. 
Thanks a ton!
