Keeping a user logged in with no token


Hi all!

I’m in need of some advice. I am working with an API that when logged in it doesn’t return any kind of access token. So in turn I can’t store anything in the device keychain for later use. Or maybe I can and I’m going about it incorrectly. My question to you all is do any of you have any experience keeping a user logged in with no token or session ID? Possibly, in this case, I would just auto log in the user. Even then I’m lacking in knowledge of how to accomplish this.

If anyone has any advice on how to accomplish this, I would greatly appreciate it. Thanks!


Hmm, sounds a little weird. If you aren’t getting a token, then how is there a delineation between “logged in or not”. How is there also a delineation between who the user is in the Requests. If there’s parameters you’re sending with each request like a UserID or something, then you can store that as a device variable and with each request, I would assume there’s a "4xx error code setup for “user not logged in or whatever”, so in that API response event you could handle the whole “user needs to login again workflow”.

But basically this is odd to me because Access tokens have expirations. The concept of “Logged In” translates to “Access Token is not expired”. When a user is “logged out”, Access Tokens are revoked, force expired, etc. If you’re not receiving a Access Token then you need to figure out how they know who the user is (user id) and how they report back that the user needs to log in again (API response codes)


Hey @wade, I thought the same thing. I reached out the company that is providing this api and their response was “all API’s are stateless. So you will need to keep track of that on your end.” I’m not sure at this point exactly the best way to handle this. My assumption is that they are looking at their API from a browser based perspective where you can grab some header information and cache it in the browser in case the browser window is closed? That’s my best guess.

When I responded to the stateless api response they rebutted with “There is no notion of being logged in. You pass the “Customer-Authorization” header to tell us who should be logged in.” So how the endpoint works is that the logged in users info isn’t sent via the body of the request but as the request path parameters. What do you think? Seen anything like that before?


Hmm… I’m not quite sure in this situation. At least it sounds like they are responsive though.

You might was to see if they will help you work up the appropriate Swagger file so that we can potentially work with them based on their required rules here.


Hey Wade,

From what it sounds like, they don’t provide a way for a user to stay logged in. It just gets stored in the header and cached when you access via a web browser. I’m not sure there is anything we can put into a swagger file to make this function like they expect it to function if it were initiated from a browser. They keep users logged in within their own applications so I have inquired with them on how they implement this. Hopefully they can share some insight.

I’m going to add a little backstory here on what we are trying to accomplish in case this helps anyone in the Dropsource community. This is app that I am building is for a restaurant group that has a loyalty program for beer. The point of sale software captures the customer information and then we have access to their API to use that data how we please. Ultimately, all we really need from this API is the customers loyalty points balance, their list of beers they have purchased and then any balances if they have any money on their account to use in our stores. After doing some fairly heavy testing of multiple scenarios, I have come to the idea that I will probably need to utilize 2 API’s for this project. I believe that Backendless provides the necessary components to handle a more robust customization of our customers profiles and how we can communicate with them via push messages and emails. We can also control their sessions while using the app and handle the experience a little bit better. It’s a bit of a challenge but I think I have found a way to register a customer in both Backendless and our other API at the same time. Since the customers loyalty account is tied to a specific loyalty card number, we can actually our POS’ API with the card number, store that in our Backenedless customer data and then access this loyalty data at any moment without actually having to login to the POS API. That gives us a ton of flexibility and allows to take advantage of Backendless’ many offerings.

Our POS provider is hopefully going to respond today with how they handle customer logins. Their web applications are written in Java and I have my fingers crossed that they will shed some light on what their process is. My assumption is that they using a mix of both browser caching and some server side scripting to accomplish this. I can see that a java session token is created when I login to any of their sites and then that is cached in the browser.

Sorry for the long winded post. Hopefully that provides some insight on what we are accomplishing and maybe it will help someone else to accomplish their development goals as well.


Thanks for the context here. I have reached out to engineering here to see if perhaps they have a little more insight on this particular spot than I. When it comes to some of the ways Auth is done and how we leverage a Swagger file to accomplish it, the concepts and limitations can go over my head and I think we’re there right now.

It’s very well possible that I’m not asking the right questions here to get to the answer as well… let’s get the big gun in on this topic.

@fertrig and/or @nate_frechette… do you have any insight on how Matt might utilize this API and perhaps how he might need to manually customize his headers to play by their rules for access?


Thanks @wade.

Right after I read your response, I got a call from our POS company. They explained it like this. Currently, they don’t handle any session data because their API is stateless. They require a call to be made every time data is needed. They designed it for web based access for simple viewing of data. Since it was designed for web based access, the browser, using cookies and caching will keep the user session active. In our case, we are just viewing the data but we need to actually keep someone logged in and perpetually active. They have plenty of customers who do this the way that we are trying but they are using their own business logic.

So what I’ve been attempting with using Backendless to handle the business logic is actually the way that they recommend. Ultimately, to pull any customer data, I don’t have to actually “log in” or athenticate the customer. Just need their customerID from the POS database. Then I can make a call to the database with my API ID and token to authenticate my calls. I’m going to work on some custom logic within Backendless to store their customerID and their beer club card number in my data table and then I can handle the login session.

Hope that makes sense.


Thanks so much for the info! I hope this works out. If you have questions on making this work with Backendless, @markpiller is a great resource for more info too!


Absolutely. I’m glad I was able to get some more information from my guys.

@markpiller Hope you are well my friend. I was going to post this in the Backendless forum but thought it might benefit here as well. In the codeless business logic, there is an option to import a service. The options are Swagger, RAML and couple others. I have my other API fully documented in Swagger but I’m unable to import. This is the error that is thrown out.

I placed the Swagger file into our Backendless files and created a directory for it. Maybe I’m interpreting this incorrectly?

Thanks Mark!


Hi Matt,

Could you please send me the Swagger document you’re trying to import or share the link for it?



Absolutely, I just sent you a direct message.


I’m peeking in on the interaction here. This is a bit over my head but it looks like a valuable error to know how to handle for future developers too.

Thanks for posting it here too!


@matt, the problem is that one of the operations, specifically /customer/{email}/{password} is missing the operationId element.

You can find the modified version of the JSON document at:

I know that operationId is an optional element, however, Backendless currently requires it. We will rework the parsing logic to avoid the requirement for its presence.



Fantastic. Thanks Mark! I will clean up my swagger doc on my end to include operation ID’s. Thank you for taking the time to look into this.