Both POST & GET methods for the same Backend API endpoint?

Hey!

I think I have reached a dead-end.

Context
Using Twitter Webhook to notify events to Bubble app.

Challenge
According to Securing webhooks | Docs | Twitter Developer Platform

  1. The webhook URL must be Twitter-validated at setup by GET method to the specified (Bubble app) endpoint. The endpoint should send a token back in response (Challenge-Response Check) to validate the webhook, which is now ready to receive events at this point.
  2. BUT this CRC check via GET is performed every 24 hours. Failure to do so invalidate the said endpoint for security reasons.
  3. However, this webhook URL is also used to listen to Twitter using POST method.

If I am not mistaken, it implies that the Bubble app Backend API endpoint must support both GET and POST methods - which is not possible in Bubble apparently, only GET or POST.

Any solution?

1 Like

Sounds like a good use case for xano. I can help you out :wink: you can set this exact thing up in Xano.

Of course, but using a middle provider is not authorized.

Any solution using Bubble?

In a situation like this I would probably use a CloudFlare service worker. I’ve done this previously to handle converting GET requests to POST requests (pre Bubble supporting GET requests natively).

Sure it’s an intermediary, but it’s in your own CloudFlare account and isn’t doing any processing, it’s just passing the request through.

1 Like

Isn’t bubble considered middleware?

2 Likes

Except Bubble :slight_smile:

@grace.hong @emmanuel Can we add this as a feature request?

  • Ability to expose the same endpoint in Backend API Workflow with multiple methods.

I simply can’t use Twitter webhooks for my app without this, which is using both methods for security reasons.

3 Likes

Hi, did you find a solution? I am also facing the same issue with facebook messenger integration

No. I would recommend to raise this suggestion to Bubble.

I sent an email to their support.

For Facebook I am using an alternative call for messaging (that incredibly enough do not rely on webhook but it is rather a workaround)