Instagram Webhook Testing

We’re attempting to build an api endpoint to receive a webhook from Instagram mentions. Leaving out the issues getting the Instagram webhook permissions approved by Facebook, my particular question is relating to the actual response data that is being sent by Facebook for the the webhook. While in development mode, Instagram/Facebook limits a developer’s ability to test a webhook to a function within the console of the Facebook app dashboard.

Our problem is that, we don’t seem to be able to receive a response from the tests initiated by the Facebook console test function. That said, we have exhausted reasonable explanations of why our Bubble endpoint is not consuming the webhooks.

  1. The Bubble endpoint is setup and the Detect Response Data function seems to have worked as expected. When we click the Modify Types button, the API Workflow Request Data definition is exactly as defined by the Facebook reference documentation.

  2. When we send a Postman test of the response data to our Bubble enddpoint, it is received just fine.

  3. Given the data is received correctly by our Bubble endpoint via a Postman test, it would follow that there is something off with the Facebook console test function …or that would seem logical. To test this, Facebook provides a sample app that can be deployed on Heroku for the simple purpose of seeing the webhook response. We did this, and found that the Facebook test data was exactly the same as when we did a Postman test.

If not obvious, we checked the Bubble server logs and there are no entries when the test is sent from the Facebook console.

So given we know the Bubble endpoint works when data is sent from Postman, we also know the data sent from the Facebook console test is accurate, but does not even show in the server logs, our thinking now is that there may be something not handled well in the domain forwarding between our apps assigned domain name url and the “bubble app name” url. So we directed the Facebook test to our https://[appname].bubbleapps.io/version-test/api/1.1/wf/[endpoint_name] url

…but still no change.

So I’m reaching out to the community for any similar experiences or suggestions?

Did you remove the /initialize in Instragram?

Actually, I had to do the initialize via Postman. The Instagram console tester did not allow me to enter the subscription url with the /initialize. It gave me: HTTP Status Code = 403; HTTP Message = Forbidden. Certainly, we’ve removed it from all other calls after the initialization was completed.

If I understand your problem correct I have a similar problem. If I setup a webhook with postmaster with a json code stripe invoice it works perfectly. When the bubble api endpoint is setup and I point a stripe webhook to this api endpoint, an invoice is created but no data is placed in Bubble. It seems that, accept for the raw data, the api endpoint has data “under the hood” saying that the response should come from postmaster, not from Stripe. Do you recognise this behaviour?

In our case, the issue was a missing Instagram/Facebook permission (and not a Bubble issue). The wording for the required permissions in the FB documentation was a little confusing. Our app was granted all of the seemingly needed permissions, but we did not apply for manage_pages (now pages_manage_metadata in graph v7.0). IG/FB allowed the webhooks in dev mode (via their console) without the permission, but for live mode, the additional permission had to be granted to receive the webhooks.

1 Like

I’m wondering how you were able to get around the fact that Bubble doesn’t allow users to trigger an API workflow from a GET request (last I checked). Are you using some sort of middleware to convert the GET to a POST before passing to Bubble?

Yes. We’re using AWS API Gateway as a proxy for the IG response to then relay to the Bubble endpoint. It’s very flexible and inexpensive.
Friendly note: If you choose this option, the only gotcha that caught us a bit is when making changes to the AWS API, there is a manual step to publish/build the API to a “stage” each time you make a change. Although the configuration is quite easy, the changes are not auto applied to the running instance.