1. Have a way to dynamically create Google OAuth tokens on the fly

First, create a function to generate Google OAuth tokens and ensure they have the proper scopes (for Google Calendar).

Get 10% off Xano!

2. Configure Google Workspace correctly

If you are using Google Workspace and you want invitees to receive calendar invitations, you must (as an Admin) navigate to the below menu:

Apps > Google Workspace > Calendar > Sharing Settings

And disable the setting “Warn users when inviting guests outside of domain.”

This took me forever to figure out but was the only way I could actually generate notifications for the target email (with it enabled, the API call will still generate an event on their calendar, strangely).

Get google_calendar_id

This is relatively straightforward and can be done from your Google Calendar UI.

Get google_calendar_event_id

This is trickier. ChatGPT told me that you can get this from the Google Calendar user interface but that is not correct. What you need to do is execute a GET request against the existing google_calendar_id, sort through the responses, and get the event, e.g.:

GET https://www.googleapis.com/calendar/v3/calendars/«google_calendar_id»/events

Subscribe now

You can then access the items array in the response to find your event’s id:

Build function stack

Alright, now you are ready to build your function stack. Below is the full thing but I break down each part in the subsequent sections.

Conditional logic for getting OAuth token

This setup allows me to default to using whichever OAuth token is passed to the function, usually dynamically generated immediate before using the token generation function I built previously. But because I generally store the Google OAuth token as an environment variable, I want to allow pulling it from there if no value is passed to help save time in development.

Create authorization string

I use this to generate a variable that I can plug directly into the headers for the API call, but it isn’t strictly necessary. Note that there is a space after the word “Bearer”.

Get existing attendees

I could not find a way to simply update the list of attendees, even when using a PATCH request. Thus, unless you want wholesale replace any existing attendee(s) with another one, you’ll need to GET the existing attendees.

Generate URL string

Similar to the authorization string, I create the target URL string in a separate variable just for ease of use and readability.

GET API request

Create an object in which you set the email to be added

set responseStatus to needsAction so that it requires response from the invitee.

Extract attendee emails

This just pulls out existing attendees as an array.

Conditional logic to check if attendee list is empty

If the current_attendee_emails is empty, you’ll want to create an empty array to which you can add the new_attendee_object. Otherwise current_attendee_emails would be null if there are no existing attendees, which would throw an error.

Update current_attendee_emails

Add new_attendee_object to the current_attendee_emails array.

Rebuild the url_string

Append ?sendUpdates=all to send updates to everyone, but you can customize based on the Google API documentation.

Make the PATCH request

1. Ensure you have the proper API (Google Calendar) enabled for the project you are working on.

Make sure this says “Manage” rather than “Enable.”

2. Install the Google OAuth Extension

Check out this video for a deep dive:

Optionally, include an Authorized redirect URI of http://localhost if you don’t actually need to use this as part of user authentication flow but are rather using it only for API purposes.

Subscribe now

Importantly, make your Client ID and Client secret environment variables in Xano.

3. Ensure you have the proper scopes enabled in the Google Cloud Console.

This a little tricky, but you should use the minimum necessary to accomplish your task in order to avoid providing excessive privileges to the application.

4. Generate an authentication link

Using the google_oauth_getauthurl function from the Google OAuth extension to generate an authentication URL and go through the process to authenticate to your Google account.

If that is successful, you will get a code parameter from the destination URL. Copy this.

5. Generate refresh token.

I made this separate function, but it is really just a single API call that takes as its inputs the code from the above step, your existing redirect_uri, as well as the environment variables for the Google Client ID and Client Secret. and generates a refresh token.

I recommend storing this as environment variable, as you will not need to regenerate it frequently.

Get 10% off Xano!

6. Generate OAuth token

Another single API call here. It just takes your refresh token, Client ID, and Client Secret to generate an access token. These expire pretty quickly (defaulting to about 3600 seconds / 1 hour), so I recommend creating a separate function for this.

You can then dynamically generate tokens when need for your app.

Conclusion

Generating OAuth tokens for Google accounts was pretty challenging for me, and I had been using Zapier to handle the authentication side of things. But I decided to give it a try with Xano and eventually got it working.

Subscribe now

This can let you do all kinds of cool things, like building Google Slides and Sheets using the API, manipulating your calendar automatically, and similar.

And if you want a super-quick walkthrough of the procedure without Xano, check out this video:

Ensuring Xano correctly identifies the data type (string, integer, array) of inputs and variables is important to making things work as expected.

Subscribe now

There is already a very long community thread about how to take a string input containing integers in an array and have Xano treat them as an array, rather than a string.

This is just one side of the problem, however, because it doesn’t address how to handle this issue when calling an external API; it only addresses when Xano is the API being called.

An example where this is important is when making calls to the OpenAI GPT-3.5/4 API. In my use case, I use a system message instructing the model to return the results as an array. It does this, but from Xano’s perspective, the response is a string:

This is problematic if you have subsequent logic that needs to use this as an actual array.

Get 10% off Xano!

Fortunately, I found a very simple, but lame, workaround: just create a Lambda function that returns the variable in question:

So all you need to do is write a JavaScript snippet that returns whichever input or variable is the original array (in string form), like this:

return $input.array_string

That’s it.

I first learned how to code in Python, which is a relatively forgiving and easy language to start out with. And because of that, most of my coding frame of reference centers around it.

In Python, if you run the following, it will return True

isinstance(5, int)

If you run the below, it will return False

isinstance(5.5, int)

Now, you can attempt to force any value into the data type of int. For example:

int(5.5) will return the int of 5.

Get 10% off Xano!

If you attempt the below, however, you will get a ValueError:

int("cat")

That’s because you can’t turn a cat into an integer (just like you can’t feed one into an ATM).

But Xano works differently.

The is_int filter checks if the data type is int, not whether value is a valid int.

And you can force a text string into int.

So the below will return True (confusingly, in my mind):

So how do you test if something is actually a valid int?

You need to do a weird workaround where you:

• Force the value into an int (using to_int)

• Multiply the value by 1

The result will either be 0 or a valid int. You can then run your conditional logic on whether or not the output is 0 or not 0.

A major problem with this approach is that zero is a valid integer! And if you plug in zero to your function, it will return…zero. But if your logic is set up to act differently on whether or not the output is zero, you might get an unanticipated result.

Subscribe now

Unfortunately I don’t have a good fix for this, but this should hopefully be a corner case for most people. Otherwise, I hope this is helpful.

If you know a better way, please tell me in the comments!

Do not use a decimal as the key for accessing a value in an a Xano object; convert the key to an integer first. Trying to access a value with a decimal key will return null.

E.g. do this:

Get 10% off Xano!

Not this:

I couldn’t find an explanation of this behavior in the documentation, so thought I would share it with you here.

This is probably something I should know if I were a trained developer, but I’m not. And you probably aren’t either, so here you go.

TL;DR

1. Add X-Data-Source headers to all of your front-end API calls when first building them. In Bubble (my front-end), unfortunately you cannot make this a shared header, as the header needs to be set dynamically.

2. Make sure these headers are not private and are optional.

   

3. Create an app_version field for the user custom data type.

4. Build a workflow that sets the app_version upon login for each user. Conditionally set to the arbitrary text of either test (development in Bubble) or live (live in Bubble) whenever the user logs in.

5. Make sure that your authentication token is also generated using the test header, otherwise you will trigger an error when making API calls from a test API token to a live data source, or vice versa.

6. Set all of your API calls to Xano to dynamically pass the current user’s app_version in the header, like this:

   

7. Copy any data you need from your live to your test environment to make sure everything works.

8. Now you can access test data from the development version of your app and live data from the live version.

Get 10% off Xano!

Detailed comments

A handy feature of Xano (when using the Scale and above plans) is that you can have both test and live data. The Xano documentation explains this in depth, but suffice to say, this allows you to try out your business logic without impacting customers in production.

For full-code or “normal” developers, segregating these two things will probably seem obvious. A benefit of no-code is that people from non-development backgrounds can build applications quickly. But they might not also think about this ahead of time due to their lack of experience in development.

While allowing for test data is easy to configure using the Xano back-end once you want to turn this functionality on, it is harder to do so on the front-end side if you haven’t considered this from the start.

And in the early days you probably aren’t thinking about how you will maintain your application at the same time customers are using it. But you should be, because you are also more likely to break functionality if configuring it after the fact.

So, check out the above steps and make sure you incorporate the ability to dynamically switch between test and live data from the earliest stages of development.

After resolving the back-end problems associated with parsing a CSV on the Xano side, I turned to the front-end. Although I could now get Xano to process CSVs, I was having problems sending them from Bubble.

After encoding the file as base64 and having it sent via API to Xano, it would decode into weird text:

{"error_class":"Unauthorized","args":{"code":"1670957944426x137539456986082160"},"message":null,"translation":"Permission denied"}

After much troubleshooting, reviewing Xano and Bubble blogs, and going to Xano office hours, I figured out what the problem was.

The error I got was the result of me marking the file as “private” in Bubble. Having the data be publicly available was not an option for me, so I needed a way to protect it.

Bubble, however, does not let you send private files through the API connecter. Fortunately, I found a crazy workaround that still allows you to keep the file private. Check out this post for the original, but see below for more details and explicit steps.

1) Enable the Bubble API for workflows and generate a Bubble API token.

2) Combine the file’s URL (the location where it is stored after using the Bubble FileUploader) with a Bubble API token to give the Bubble API connector access to the underlying data and send it to Xano.

Get 10% off Xano!

3) For good measure, delete the file at the end of the process to prevent your storage from being overloaded and also set the encoded value to 0. There is no reason to retain any data in the front end that you don’t need, so deleting it removes a potential security risk.

For those of you here who just Googled the title tho this post, I’ll just dive into the meat of the post.

TL;DR

1. Make sure your database is set up correctly.

2. Get the CSV file as an input from the API call.

3. Use “Get File Resource Data” to prepare the CSV for decoding.

4. Take the data path of the result of step 2 and apply the csv_decode filter.

5. This will create an array of arrays, with the first array being your column titles and each subsequent array representing a row of the CSV.

6. Access the first (index == 0) array in your decoded_csv, which represents the column headings of your CSV and will be the keys to the objects you are going to build. Store as a new variable

7. Remove the first array (use the keys variable as the target for removal) from the decoded_csv, leaving behind only arrays of values.

8. Create a new array_of_values_to_add_to_db to which you will add the objects you are going to build.

9. Run a for loop through your array of values. In each iteration, use the create_object filter to build an object, with keys as the value when creating the variable and values as the values when using the create_object filter. Each resulting object represents one row in your database.

10. Add each object to the empty array_of_values_to_add_to_db you created previously.

11. Bulk add records to the database, using the array_of_values_to_add_to_db.

Get 10% off Xano!

Tips

• I have some conditional logic here to only run this if the CSV input isn’t null.

• You probably want to make at least part of this a generic function and use it whenever you need to parse a CSV file.

• As of this writing, there is a bug (of which Xano is aware) that breaks the Get File Resource Data function if there are other inputs to the same API that are booleans. My hope is it will be resolved soon, but please be aware of this if you are reading this post soon after publication.

Mistakes to avoid

Figuring out the above took me a long time, unfortunately, as I had to pull together a bunch of videos, sparse documentation, and back-and-forth with the Xano tech support team.

I was really struggling with how to upload a CSV to my app, and considered using Bubble (which I am using only as my front end) to do some of the parsing and then send each record one-by-one to Xano via API call. Building a for loop in Bubble is very complex, so strongly recommend you don’t do that if you don’t have to. And in my case this would have put some of the back-end logic into Bubble, creating something of a Frankenstein’s monster of an app.

Additional resources

Here are some videos I found along that way that might be useful as well.

Convert an array to CSV in Xano

Transform data into CSV file and store in database

Building out effective telemetry collection - allowing you to track your users’ experience with the product - is critical to making it successful over the long run. Especially in the early days, detecting errors encountered by your users is the highest priority in this respect.

When building an app quickly, you no doubt will unintentionally introduce bugs into your code. That’s just a fact a of life. But how quickly you identify and resolve these bugs, however, is critical to your product’s - and business’ - success.

Subscribe now

Isn’t all of this information already contained in the “Request History” for every Xano API, you might ask? Yes, it is, but as of this writing, there is no way to collect this information in a centralized location or get any sort of notification when a customer hits an error. Thus, I thought it made sense to build out the functionality myself.

A few notes before proceeding:

• I recommend only implementing this functionality for errors triggered by the front end. That is because if you somehow designed it on the back end, then it’s possible that an API gets bombarded with calls that trigger errors in an automated manner, which will fill up your database, potentially cause performance issues, and make it difficult to identify the source of the problem. If you only are tracking manual errors that result from mouse clicks, you’ll be much more discerning in what you capture.

• While I conceived of this idea independently, during my research on the topic I also identified this post - which is specific to Bubble - that covers a very similar technique.

Two options for capturing error data

Capturing all unhandled errors

You should probably have something like this in place for any application, as just getting a browser prompt in response to an error (which is Bubble’s default behavior) can confuse your users.

On a related note, you’ll also want to minimize the amount of information you display in case of an error to prevent an attacker from determining the structure of your application and database. Xano preconditions provide an effective way to customize the response sent back under certain conditions.

The only drawback to this more broad-brush approach is that I have not found a way to capture the response code (400, 500, etc.) from the error. This isn’t a huge deal but will make it harder to sort and filter the information in your feedback database.

Finally, this technique works most easily on a single page application (SPA), but you could conceivably add the same workflow to address when “an unhandled error occurs” to every page if you would like.

For a specific API call

If you want to implement specific logic in response to an error triggered as part of a specific API call (back end) or worfklow (front end), then this is the way to go.

Get 10% off Xano!

Capture the error

In order to capture the API error, you’ll need to make sure that it gets grabbed from the API. In Bubble, you’ll need to check this box on the API connector plug-in:

Make sure that, once you initialize the API call, you get the following fields back from Xano (in addition to the normal ones containing the desired data). This information will allow you to run a custom event to take action when there is an API call error.

I built a custom event in Bubble to do this. Their documentation is not very clear, but this is how you create it:

You’ll want to set up this event to capture the following parameters from the API call to Xano:

error status_code | type: number

error status_message | type: text

error body | type: text

returned_an_error | type: yes / no

Once you have a way to capture the parameters from an error, you’ll need to kick off the workflow conditionally if the API response returned_an_error is yes (aka true).

This is what it looks like in Bubble:

Now that you have captured the correct information on the front end, you can build out a workflow that sends it to your back end.

Get 10% off Xano!

Before proceeding, I would recommend that you build out a feedback system like the one I developed here. You can layer in the bug-catching telemetry on top of it in a way that gives you quick way to sort through the feedback (and errors) experienced by your users over time.

Having already built out the feedback APIs, I simply added a nullable column to the feedback table called error_code, of type integer. If it is filled, then you know the given row an error entry generated automatically by your front end. If not, you know it a user manually sent you feedback from within the app.

Additionally, you may want to consider adding if / then logic to your feedback POST request that allows you to not send emails if anyone from your domain triggers the error (or does so in a non-production or live environment). This will prevent you from being inundated with notifications or emails during testing.

Finally, as I mentioned in the post on creating feedback functionality, you’ll want to send the current URL the user is viewing as part of the call.

Reinitialize the POST API call on your front end if necessary, and the go back to your workflow.

Note: if you need to reinitialize and hadn’t already been capturing the API data, this may break your existing workflows, groups, and repeating groups. Your desired data will now be in the body of the API response.

Additional note: this custom event can only fire after a “pure” API call in Bubble, i.e. not after a displaying data in a group or a list in a repeating group.

Finally, plug in the appropriate parameters captured from your custom workflow and then set up the API call so that it pushes the information to Xano.

So now you have a reusable API call that you add as the last step of all of your API calls to collect errors from users interacting with your front end!

Early in the development of your app (and business in general), you are going to be starved for information and feedback. You don’t have product-market fit and you have no idea if you are close to it. Thus, being able to learn quickly from your users and customers (if anyone is paying you) is critical to your success.

Get 10% off Xano!

That is why I built a feedback API early in the development of my app. This allows you to capture your user’s thoughts either directly from API calls or, more realistically, from your front end.

Doing so allows you to collect the feedback in a centralized location that you can query easily. And by integrating it with SendGrid (or any other email, messaging, or ticketing app), you can be alerted to it and tee it up for action by your team.

I’ll note that this is potentially duplicative of systems like Intercom. And if you want to use that product, go ahead. I thought it was so simple to build out (only requiring one POST API endpoint) that it was worth doing on my own. This is compared to paying for more than the monthly subscription cost for Xano to get features I didn’t need at the time.

Subscribe now

Below is the entirety of my back end for the feedback API. There is some additional functionality here that I will save for discussion in next week’s edition - mainly the error_code and app_version inputs and the conditional logic determining if the app_version is test or not - but you can just do without it when building v1 of this feature.

One of the great things about Xano is its simplicity. It’s easy to get up and running in no time with a database and APIs. What is a little trickier, however, is doing more advanced things. For example, applying versions to records.

To explain what I mean, consider what happens whenever you edit a record in Xano. By default, when this happens, Xano either partially or entirely modifies the old record (“version 1”) instead of creating a new record and calling the new one “version 2” or something similar.

This behavior is helpful in that it allows you to maintain existing references to (and from) other tables. But it is unhelpful if you want to maintain a historical record of what certain entries were at a given point in time. For example, if you wanted to offer any kind of undo or audit trail capability in your product, you would need to maintain at least some historical record of what records were at some point in the past.

Get 10% off Xano!

How to version records in Xano

The best solution to this problem I have found is to create a copy of your original table with the suffix _archive or something similar. I’ll give a hat tip to this Reddit thread for giving me a general outline of how to proceed.

As part of your function or API call that modifies the original record, you should use conditional logic to create a copy of the original record in the _archive table, as in:

Additionally, you should use all of the original record’s attributes, including its created_at timestamp when adding the new record in the _archive table.

Finally, you should add a table reference column in the _archive table that refers back to the id (index) of the original record. This way you can quickly lookup all of the historical records for a given entry.

This method allows you to query the _archive table using the original records index id, so you can sort by time of modification, person editing the record, or any other characteristic.

What you should NOT do

The first time I approached this problem, I though I would keep all of the data in just one table but create a new column called version. Every time I created a new record, the new record’s version would increment by +1. This necessitated creating the following:

• A record_id, separate from the auto-generated index id, to uniquely identify each record referring to the same thing.

• A record_version to identify which version of the record_id the query was referring to.

• A function that would look up the highest record_version for a record_id record. This required a for loop through all of the existing records.

If you are computer science expert, you are probably laughing already, but suffice to say, this did not go well. As soon as I had a few hundred records in the database, the for loop took an extremely long time to execute and basically prevented my application from running.

Additionally, this approach made it impossible to use table references within Xano, greatly complicating my application development efforts.

Conclusion

In summary, unless you are aware of a better approach (please comment with it), then you should version records in Xano in this manner:

• Create a base and base_archive table.

• Add in function/API logic that copies records from the base table into the base_archive table whenever a record in the former is modified.

• Create a table reference from the base_archive table back to the base table to allow for lookups of all historical records for a given id in the base table.

If this post has been helpful, then give it a like and let me know! Until next time, keep plugging away on your app.

Welcome to Xanomorph, a newsletter and blog that will dive deep into best practices, tips, and tricks for building on Xano.

What is Xano, you might ask?

In one sentence, Xano is a no-code platform for building application programming interfaces (APIs), which can be used as the “back end” for an application.

This is distinct from a “front end,” which is what most people are familiar with when they think about applications. The front end has buttons, inputs, and displays that you can click on and interact with.

The back end, however, is where the magic happens, and database lookups, data transformations, and interactions with other applications occur.

Get 10% off Xano!

When you combine a back and front end, you get a “full stack.”

Xano’s main selling point is that it doesn’t require you to write code to develop your back end. Especially when building APIs, this is a huge time saver. As a self-taught developer, I attempted to build a series of APIs for my application StackAware using Python on Microsoft Azure Web Apps, and it took a long time to just build a single endpoint. As soon as I switched over to Xano, though, I was off to the races very quickly.

You can build a wide variety of applications for all sorts of use cases with Xano. While there are some limitations, if you are going the no-code route, it’s likely that you’ll be able to solve most of your problems using the tool.

There are a growing array of no-code offerings on the market, and sometimes it can be hard to distinguish between them. To simplify things, I would break them down into three categories, along with a non-exhaustive list of examples:

Full stack

• Bubble

• Adalo

Front end only

• Webflow

• Vev

• WeWeb

Back end only

• Supabase

• Xano

All of these platforms have their owns quirks, and many of them (especially Bubble) have thriving communities of builders who use them. While Xano does have decent documentation and a great YouTube channel, both of which I recommend, I haven’t yet seen an alternative source of information on the product and how it works.

Thus, my goal with Xanomorph is get deep in the weeds to fill the gaps in the existing content available about Xano. As someone who is actively building an app with the tool, I’ll share my insights along the way, hopefully saving you a bunch of time and effort.

This is not a beginners guide or an A → Z type tutorial. My goal is to clearly explain certain confusing or troublesome aspects of the platform and how I got around them. The Xano documentation is the place to start if you want the former type of content.

Finally, as a disclosure, I want to make clear I am not affiliated with Xano, Inc. except for being a customer. They didn’t ask me to write this blog. If, however, you sign up for a paid plan using my referral link, I will get compensated by Xano. This is available to every one of their customers, though, so I don’t consider it to be special treatment.

That’s all for this issue. Next time I’ll discuss how to set up versioning for items in your database.