⚠️ Handling API errors in your #NoCode SaaS app - Issue #26

Hi there,

I’m back to writing the NoCode SaaS newsletter after a few weeks off busy building my own app.

If you’re new here - this newsletter is all about sharing with you my tips and tricks for building a successful SaaS business using the Bubble no code platform.

This issue is all about API error monitoring.

If you’re building a SaaS, it’s likely your app will be utilising external APIs to complete important tasks for your users.

It’s important to monitor the performance of those APIs and to catch any errors as quickly as possible to make sure your users are always having a good experience.

My app UserLoop is deeply integrated with the Shopify API, and it’s important those connections are reliable.

I’ve added several error monitoring techniques to my app to alert me to any failed API calls so I can fix them as quickly as possible - hopefully with no unhappy customers!

So, let’s get started and dive in…

Setting up Error Monitoring in the Bubble API Connector

Back in 2021, Bubble added a feature to their API Connector plugin which lets you monitor for errors in your API calls.

This is super useful, as it not only gives you the option to allow workflows containing failed API calls to continue, but also allows you to trigger different actions depending on whether there was an error.

If you set up an API connection before May 2021 when Bubble announced the new error monitoring feature, you may need to go back and re-initialise your connections.

Up until this update, all Bubble API calls would ‘fail silently’ - you’d only really know a call had failed by searching through your logs.

Now, you’ll see a checkbox called “Include errors in response and allow workflow actions to continue” when setting up an API call.

Clicking this box means Bubble will collect information about every time the API is called (including error types etc) and make them available to you in workflows as dynamic logic.

Turn on the 'Include errors in response' option

You should then ‘Initialize’ your API call again.

When you do that, you will noticed some new data in the returned values which Bubble stores…

Notice the extra fields you get when you enable errors in response

As you can see in the image above you will now get the following additional fields you can use in your logic and workflows…

• Error Status Code. What status coded the API return. 200 is OK etc…

• Error Status Message. What was the error message returned from the API, if any.

• Error Body. This is where you usually get the biggest clues on why your API request failed. This should tell you the exact problem and what you need to fix.

• Returned an Error. This gives you a boolean YES or NO value you can use in your workflow’s logic to decide to do different things depending on whether the API call failed or not.

Once you’ve got this all set up, we can start updating our workflows with logic on what to do when an API call fails.

Handling API Errors in your Workflows.

So when a workflow runs and uses an external API, we might want to do some different things depending on whether an API call fails.

To give you an example of this, I’m going to show what my app does when my app makes a request to update an order’s note on Shopify.

This happens whenever a new feedback message is left - my app goes to Shopify’s API and attempts to add that feedback to the order’s notes.

Sometimes these API calls can fail for various reasons, perhaps the store reduced my app’s access permissions and I’m no longer able to write notes to their orders.

In this case, I need my workflow to understand that the API call has failed and take appropriate action.

When this API request fails, I want my app to…

• Turn off this feature for this user, if one API request has failed because of a permissions issue, I don’t want to keep sending failed API calls and get into issues with Shopify.

• Post a message to my internal Slack, telling me which customer has had the error and the exact nature of the error (code, name and body)

Here is the workflow we are going to be working with. This is triggered whenever a new feedback message is received.

There is some conditional logic on this workflow which means it will only run when the company’s ToggleShopifyOrderNotes is YES.

This means I can control programmatically whether this feature is enabled for this customer or not (important for later)

The Request to Shopify is made in Step 2 of this workflow

The request to Shopify is made at step 2 in this workflow.

Step 3 will send a internal message to my Slack channel if an API call fails.

To do this, we add an ‘Only when…’ condition to this step which says. ‘Only when result of step 2’s returned an error is yes’

That means this step in the workflow will only run if the API call has failed.

Only run this step if the previous step returned an error.

That will in turn post a message to my internal Slack channel telling me a customer’s API call has failed.

This is what it looks like in Slack.

This is an example of an API error posted to Slack

The next thing I want to do if an API call has failed is to stop the app from making any more of those requests for this user until the issue is resolved.

To do this, we need to turn the toggle for this feature for this company off.

Using the same logic as above, we add another step to our workflow which will set the toggle for this feature (ToggleShopifyOrderNotes) to ‘false’ when the API request fails.

Here’s how that looks in the workflow…

Disable a specific feature when a API call fails to avoid repeated failures.

Adding these toggles to individual features means you can easily disable a specific feature if an API call repeatedly fails.

This can also be handy when gating features to certain pricing plans.

I also highly recommend adding a session replay recording tool to your application to monitor for errors on your app’s front end.

This can help you identify where APIs are failing and causing breaks in your app’s user experience. Services like LogRocket and FullStory offer free plans to get you started.

That's it for this week!

I hope you found this issue helpful.

Bubble is extremly powerful at letting you add many complex APIs to your application so it’s important to monitor all the ones you’ve integrated to make sure they’re working smoothly.

Any questions? Are there any other topics you’d like to see me cover? Drop me a reply to this email, I read and respond to every one!

Thanks so much for reading, happy building!

James.