Connecting a Dropsource app to Backendless


I’ve published a tutorial on using Backendless for your Dropsource app API:

It covers setting up your data in Backendless, creating your Swagger/OpenAPI specification, and connecting to it in your Dropsource project - to log users in, retrieve user data, and post user data from the app.

I found Backendless really quick to set up, it has the advantage of automatically exposing REST API endpoints for your data tables, so you don’t need to actually create the API, all you do is define your data model and it does the rest. One drawback when comparing to Bubble is that Backendless doesn’t export a Swagger spec from the default setup (it does if you use custom business logic), so you need to author your spec to use it in Dropsource, however I’ve included a sample that should hopefully help get our users started, the tutorial also outlines what steps to take in order to create your own.

I’d say the process took about the same time in Bubble and Backendless so they’re both great options for use with Dropsource, which one suits you best will come down to your own use case, skill set, and preferences…

Hope this helps someone!


Hi Sue. Thank you for this. I’m hoping you can provide some clarity on using the backendless plugin variable data type.

I have read and re-read all examples I can find. I’m having difficulty formatting the backendless friendly URL in Dropsource.

I have an endpoint in backendless when queried wants to see something like this:


This is looking for column prodId with string value ‘12345’ on products table. It works swell in postman.

I am aware that in Bubble there is a few hoops to jump through in order to format the string. I’m assuming the same is true for backendless. And while there is specific instructions on the using Bubble for formatting, the backendless instruct is not as descriptive.

I am using the GET query param WHERE in the API and sending a page var data type /data/products get body Data Type available under the plugins section for page var data types.

When I set the value of the variable using a text field to prodId%20%3D’54321’ and run in the browser watching for events I find that Dropsource is sending prodId%2520%253D%2520’12345’

I’m stumped and hoping you can point me in the right direction.


Hi @edar, I’m really not an expert on Backendless but at first glance it looks like a url encoding issue - are you planning on sending the parameter from a text field like this or from somewhere else in your app? Also can I check what platform you’re on (ios or android)?


Yes will send params from somewhere else in the ios app. The text field was for troubleshooting. For certain is an encoding issue. Is there a tutorial you can point me to for backendless query?


We don’t have tutorials specifically on backendless except the intro one you’ve seen above. Let me see if our engineers have any thoughts on how you can send that data reliably.


Actually could you point me at the backendless info where you got that query string structure?


Log into backendless
Select the db icon on the far left
Select an App table from the left menu
Click the Rest Console tab
Enter a param for the WHERE field (prodId = ‘12334’)
The request URL is generated and displayed near the top of the dialog box


I don’t have a Backendless setup I can do that with and am not familiar with the structure they expect for the different types of query. The parameter you’d be passing from Dropsource would typically have the name e.g. “prodid” and the value you pass from your ui would typically just be the “12345” part. You would need to ensure your swagger spec was set up correctly to pass the data that way though, and for that I’d recommend using Stoplight, Postman, or maybe the Swagger Editor to test your requests before attempting to connect to Dropsource - other than that I would check with Backendless support that you have the correct url structure.

You’ll also find examples of declaring query string parameters in a spec file in our sample repo:


Tested in postman and working.

The link you provided has nothing regarding making queries.

Using backendless with Dropsource is not at all viable if there is no way to make queries. The sample todo app does not make use of any, so not sure that this has been fully tested?

Bubble is not viable because of no accurate way of predicting costs at high volume.

Sheetsu does not have a user/login - unless perhaps creating a user table? The DS sheetsu tutorial makes no mention of creating users/maintaining state/user-token.

Not sure what to do next.


The link I provided has an example of how to define a query string parameter in your spec file that will work in Dropsource - the detail needs to be tailored to your own endpoints.

Can you attach or link to your spec file so that I can see how you’re defining the query parameter?


GETting the entire table works.

My understanding in order to get a specific record based on a column value backendless uses WHERE.

I do not see in your example how to retrieve a specific row based on a column value. Perhaps I’m missing something. Appreciate you patience.


OK so I’m not able to provide specific guidance for all of the backend platforms people are connecting to, there are hundreds of them… The api spec I linked above includes an example of passing a query parameter to a request, which is what you are trying to do, but it’s not an example of the specific query you are making (e.g. retrieving a specific row based on a column value, that depends on how each backend/request is set up). I’ll need to see your spec file to give you guidance on making your approach work in Dropsource.


Thanks for looking, Sue.


OK this is definitely an odd setup, can you try passing the parameter in Dropsource as a static input string but specify it without urlencoding it first, like (in the API tab for the request - Parameters section instead of passing it from your text field):


I’m not honestly sure whether this is going to work in Dropsource, I’ve never seen the actual SQL where clause nested inside the query parameter for a request…


Thanks for looking into it. It still misbehaves even when sending it as a static var definition.


Any suggestions for using sheetsu with multi-user?


The example you included above had a space character in it which may have caused an issue, do you have an example of a full url from e.g. the backendless documentation or one that you’ve successfully used in Postman?

I don’t know about sheetsu and multi users, you would need to ask sheetsu support about that.


And did you try it with the string not urlencoded? Your example above has it encoded.


The reason I ask is that your example of what Dropsource was sending was urlencoding your parameter (which was already urlencoded) which may have been messing things up for you.


Yes have tried unencoded. Backendless does not like that at all.

Try this in postman (prodId since changed to UPC). Removed token requirement so should work if you paste and send.

Thanks for looking.