Passing requestURL response variable to open browser in AppGyver

i’m using AppGyver to call - the request works, it returns a 200 and the request_url string, just like the documentation here (Social and OAuth2 Logins - Backendless REST API Documentation) says.
But, I can’t get AppGyver to let me access that string in the response. I see request_url come back in the browser inspector. But have no way to get it into a variable or pass it through to open a web browser.

@olhadanylova already suggested in Slack, but something is still not correct.

I just get NULL in the requestURLResponse variable.


Many thanks

Hi Paul,

I think this is the kind of question that would be better addressed by the AppGyver support team. Since it is entirely in their system, they would know better how to access that value.


Thanks Mark - I have. Waiting on them to respond.

Hello @paul-barnes,

As I mentioned in Slack, we also have an article that shows the step by step instruction of how to integrate AppGyver with Backendless, maybe it could be useful too. The usage of variables and APIs is also described there.


1 Like

Hi @mark-piller , I am having the same issue as @paul-barnes .

However, as I understand it, the issue is that ‘application/json’ is requested and the response is plain text.

I find it quite strange that the Backendless API response should come back as plain text, because all other API responses are generally JSON. Furthermore, in the case of googleplus provider, I have noticed that not one but two URLs are returned in plain text, separated by a space. This makes for difficult usage of the response.

Is there any plan or possibility that Backendless could provide a JSON formatted response to this request ? Either depending on the Content-Type being accepted, or even via a request parameter in the body ? This last suggestion should enable backward compatibility, while enabling a better integration with AppGyver and the like.

Thank you for looking into this.

All our apis return JSON. Which one do you get plain text with?


This one : Social and OAuth2 Logins - Backendless REST API Documentation

Here’s quoting the doc : “Otherwise, the response body is a plain text containing the generated auth URL.” And indeed, the result is plain text.

@Nicolas_REMY, There may be a requirement why we do it that way.

@Andriy_Konoz could you please check and confirm?

1 Like

I’m sure there is a reason, which is why I was suggesting not to change the way the response comes out, but to enable an additional response type, perhaps as a reply to an additional parameter provided in the request.

Anyways, thanks for looking into this.

Hi @mark-piller and @Andriy_Konoz , have you had the opportunity to look into this ?
It would be very much appreciated if I could get the AppGyver-Backendless combination to work.

Hi @Nicolas_REMY ,

Sorry for delay with response.
Such response format preserved due to backward compatibility. We can’t change it’s response type since it can break existing clients in other applications.

I think, in AppGyver, you can just specify that response type is plain text and then assign entire body to your variable. Or it is not possible to do in the such way?

Regards, Andriy

Hi @Andriy_Konoz ,

First, thank you for the reply.

Unfortunately, AppGyver only accepts JSON content, and will not cope with two URLs back to back in plain text format, which is what the exsisting response looks like with the Google auth.

I totally understand that it is not possible to modify the behavior of the API so as not to break existing implementations. This is why I suggested that with an additional parameter in the request, it could be specified that the expected response format would be JSON.

Do you think this would be feasible ? It would be of great help because at the time being, a full Backendless-AppGyver is unfortunately not possible :frowning:

Best regards

@Nicolas_REMY ,

Yes, we can add additional body param for content type. I have created internal ticket BKNDLSS-26788 for this feature. Our team will reach you out when it released.

Regards, Andriy

1 Like

Wonderful, thanks !
Looking forward to its release.

Best regards

Hello @Nicolas_REMY

We added the following parameter for the request body: “contentType”,
now supports “application/json” and “text/plain”.
If "contentType": "application/json" is used, the authorization link will return like this:

  "url": "authorization URL"

Can you tell us if this solution worked for you?


1 Like

Thanks for the great news.
Will try it out as soon as I can and will provide feedback.

Best regards

Hi @Inna_Shkolnaya @Andriy_Konoz and @mark-piller

Just wanted to let you know that I have tested your fix and I now get a JSON response and I can use it to move on to the next step. So that’s great, thanks a lot !

Now I have to admit that once I managed to perform the social login of my users, I have to find a way to return to my app, which might be another blocking point. But it’s a separate issue.

So once again thanks a lot.