Create data resources

In the main navigation bar click on DATA and then ADD DATA RESOURCE.

In the newly created resource under BASE complete the info like below. Most importantly replace the Resource URL with your Bubble signup workflow URL. If you've created a new Bubble app and using the default domain then simply replace the app name part of the URL(highlighted in yellow here). Since the signup endpoint doesn't require authentication we wont add an header here.

Now click on the CREATE RECORD (POST) to setup the post request.

All Bubble workflow endpoints are POST requests so in AppGyver you will always use the CREATE RECORD (POST) to setup the request.

Check the box Method enabled.

Leave the Relative path field empty as our base contains the full path.

Under the Responses key path enter response. The reason why we enter response in the here is that the structure of the response object from bubble looks like this. So specifying response here will allow us to only that value without the status value. If you want to have the whole object you can leave this field empty (but to follow along this tutorial set it up as shown).

{
  "status": "string",
  "response": {
    "user_id": "string",
    "token": "string",
    "expires": 0
  }
}

We now need to create a request scheme for our endpoint call. Click on the SCHEMA tab and then ADD PROPERTY to add the three parameters for our signup call.

Note the names should match exactly as defined in the Bubble workflow endpoint.

To test the newly created request and generate a response schema, click on the TEST tab and enter some example values. Click on RUN TEST and you should receive a Status: OK response with the returned response data like below.

Click on SET SCHEMA FROM RESPONSE to create a schema based on the test response. You will be taking to the SCHEMA page and see the request and response schema. Now you're ready to use this data resource in your app.

The login data resource setup is very similar to the signup with the only difference being that the request parameters are only email and password.

So here is the setup.

As can be seen in the response, the expires value is the number of seconds that this token is valid for until the user logs out. Here it is 31536000 seconds, i.e. 1yr. This means after year this token will expire and becomes invalid.

To keep things simple in this tutorial we didn't handle token expiration. But in your production app you should have some logic to handle it. There are a number of ways to do this. You can calculate the date it expires and store this on device. So that anytime the app launches you can compare it to the current date. The downside is that if the user changes date on their phone it can cause some error in your logic. Alternatively you can always make a test call with the current token when the app launches and if the call fails with the token expire message you redirect the user to the login screen to log in again to get a new token. Note that Bubble currently doesn't refresh tokens.

User data resource

The user data resource unlike the signup and login endpoints requires authentication so we will add the Authorization key to the header as shown below.

In this tutorial we will only be retrieving a user's information so will only setup the GET RECORD (GET) call. To retrieve a user we need to pass the user's id as a url parameter.

Click on the GET RECORD (GET) page. In the Relative path enter /{id}.

Under URL placeholders create the id key as shown below.

The GET user endpoint doesn't require any body so we won't define any request schema.

Test the call and generate a schema from the response. In the Authorization field enter Bearer <token> (replace <token> with the token from the login call). In the id field enter the user id obtained from the login call.

Click on SET SCHEMA FROM RESPONSE to create the response schema.