We need better Android/iOS programmatic access to Corvid APIs

Ask the community
1

I have spent a lengthy amount of time struggling to integrate my mobile app (Android, iOS) with my Wix-based website. My goal is seemingly simple - I want to be able to programmatically log on (or fail) a user, then once validated perform actions using various Corvid APIs to get/put data for that user in Member permitted collections.

I have documented my various attempts here .

Although the documentation for wix-http-functions clearly anticipates people doing what I am trying to do by stating:

Using Corvid you can create functions to expose the functionality of your site as a service. That means other people can use the functionality of your site by writing code that calls your site’s API as defined by Wix Functions you create. You might want to use HTTP functions to:

  • Integrate your site with an automation tool, such as Zapier or IFTTT .

  • **Receive notifications and information from external webhooks. **

  • Share a backend between your site and a native mobile application.

The last bullet is exactly what I’m trying to do. However, it doesn’t appear to be designed to truly support programmatic, authorized access:

  1. There is a login() function in wix-users-backend , but it requires a front-end page call to finalize the login using applySessionToken() .
  2. By default, queries from the back-end when called from my app using standard https/GET against member data will fail because of permission violations. I have to use the “no authorization required” option to work around this. They succeed when the same back-end function is called from a web page after the user has successfully logged in.

I would much rather have a back-end approach that allows me to programmatically log in, then have it return some sort of token that represents a valid user that I can then use with any API that requires a logged in user. I’m guessing that when Wix pages are calling Corvid APIs within the $w.onReady() function there is a check for a sessionID in the headers or some such, but that approach isn’t exposed or explained when working with back-end functions.

As an example of how this works well (in my opinion), check out how Dropbox surfaces their API (Java 2 for Android, they also have an iOS equivalent).