Plugin Working Fine In Testing, But Returning Empty Data In App


I’m back with another slightly less noob question. So I’ve got a plugin making a GET call to Facebook in order to retrieve the ID number for an interest. To explain this simply, I set up the call, used Lizzo as an example, and when I initialized it, it works great! It returns the name Lizzo, and the ID, and the plugin builder recognizes them both. I selected text for both when I was asked how I wanted the data to be handled, since that’s how the values will be used. They’ll be displayed in plain text to the user.

Here’s the problem. I’ve greenlit my app to use the plugin I’ve created, I’ve set up the authentication properly in the app editor, and I even included the generic redirect link in my authorized URL area within Facebook. I’m 99% sure this is not an authentication issue.

What’s happening is that when I create a group with a text box to display the ID, no matter how I try to set this up, the ID is empty. I set up a workflow to test this, and for some reason Bubble is recognizing the data as an “empty” type when the plugin should be returning a “text” type. I even tried to force the app to store the ID, but it just stores an empty value. The logs don’t show me anything, (they’re practically useless,) and at this point I have no idea what to do.

Here’s how the call is set up in the plugin builder:

Here are the returned values with the raw code:

This is how I know for certain the api call is working. I’ve even inserted the brackets to make the parameter dynamic and tested different celebrities.

Here’s the set up within the app editor plugin page (Credentials have been redacted but they are the correct credentials.):

Although I’m now seeing that maybe the 1.1 in that generic redirect URL might be causing me issues since my plugin runs on version 2 of the plugin editor. I’m not sure, I’ll let the pros speak to that.

Here’s the workflow:

It’s recognizing that the artist ID lookup call is available, but there are no other options besides conditional triggers.

Here’s part two:

I’ve tried both the testing and live version of my plugin. I even pushed an update to make them identical. Neither works once we’re in the app. As you can see the data handler recognizes “id” as a proper item, meaning if the app were actually making the call and getting the array back, the id would be getting put where it needs to go. For some reason though, no matter what I do, I can’t get the app to actually make the call. I’m on the verge of scrapping this whole thing since the logs are inadequate and don’t even tell me what’s going on.

Here’s the final screenshot:

You can see that even though the data handler recognizes that Facebook Callers Data’s Id should be a valid string, the workflow system seems to believe that it’s returning an empty value even though the plugin is set to return it as a text. This is very frustrating and any help would be greatly appreciated.

@NigelG Perhaps this one is advanced enough for you to take a look at. I’m completely lost here since I have done everything the bubble documentation has asked for. If you have the time, please bail a brother out here.

1 Like

@romanmg or @emmanuel perhaps you could take a look? This doesn’t make any sense any more and I’m pretty sure there’s a bug at play here. I’ve switched the API call type from “Data” to “Action” and all it did was remove my ability to even select it from anywhere but the workflows tab. I’m again met with the same issue that within the workflow my only option with this call is to select when it does or does not fire with no way to set the “Path” variable. I see a lot of the answered forum threads date back to 2017. Does anyone still use this platform?

These are all of my approved URLs. Again, the call works fine in the plugin editor, but returns 0 data when I try it via the app preview.

This one is a doozy and there is indeed either a bug or a missing feature within the Bubble OAUTH protocol. The API provider I’m using requires not only an app ID and app secret for each call, but also a token. Now based on the documentation I was under the impression that Bubble was handling the creating of a token for each call. I guess assuming makes a you-know-what out of you-know-who. Anyways, I have two solutions for this.

(It’s also worth noting that the only way I found out that this was a token issue was that I just started building and sending every call in the API provider’s documentation until one gave me the authentication error. Seems like Bubble is eating these error codes for GET calls and showing them for some POST calls. No rhyme or reason there, just luck I suppose. )

Also worth noting that there was literally no way for me to get these calls working as a “Data Type.” I had to make them all an action and use the workflows to force them to trigger. This has some interesting implications for creating search inputs and repeating groups to display the results, but I’m getting along just fine.

Solution 1: Get a long lived access token and swap it out every few months/run a scheduled API call to generate one and use it as a dynamic parameter. Not every API provider allows for this, such as 1/3 I’m using on this project. If the API provider you’re using doesn’t allow for this, see:

Solution 2: Create another API call in your plugin strictly for generating an access token. In this case I’m using Facebook and they have four unique types of access tokens, so make sure you’re asking for the right token before you dive into this rabbit hole. Once you have this call set up, you have to set up whichever call you were trying to use before, and then in your workflow, you have to set the token request up first, then use the return value as a dynamic parameter in your second call.

Again, if Bubble’s authentication system did what it should be doing, this would be unnecessary. I actually don’t fully understand why we have to provide an app ID, and an app secret if Bubble isn’t doing this. In my use case, the only authentication being sent to Facebook is this token, and since it’s from a whitelisted URL, the call is approved. The app ID and secret are only used to generate tokens in the Facebook API, so asking me to provide them and then not using them to generate a token is a bit of a pain in the rear. Anyhow, if you find this, just know that not every API provider is the same, and Bubble may or may not do this properly for some.

Tags: Facebook API, Facebook Call Not Triggering, Invalid Oauth Token Bubble, Bubble API call not firing, Bubble API call not sending