🪲 Troubleshooting Workflows

There are a lot of errors you can run into when setting up workflows.

When you're first starting out, it can be daunting but you'll soon get the hang of it and avoid the most common mistakes, like:

• trying to update a number field in your backend using a text input in your frontend (see example 2 below),
• binding a field to the wrong variable (see example 3 below),
• forgetting to pass through a parameter that is required by your backend, or
• typing in invalid login credentials (see example 1 below).

In this article, we'll show you how to find out why a Workflow is failing with four examples:

1. Server error code using the REST API plugin
2. Error message using the Airtable plugin
3. Client error code using the REST API plugin
4. Hitting an API rate limit

We'll also provide you with a debugging checklist that solves 90% of workflow issues.

But first, let's learn about the Workflow Debugger, HTTP status codes, and how to read error messages.

How to Find Out Why a Workflow is Failing

If you're experiencing issues with a workflow, the easiest way to find out why it's not working is to go to the Workflow, and click on Test Workflow at the top:

This will run the entire Workflow and you will be able to see where it's going wrong in the debugger on the right (more on that below).

If you're working with a more complex Workflow and think you know where the Workflow is breaking down, you can click on Test Action instead of testing the entire Workflow.

🔥 Pro Tip 🔥

When testing individual Actions, keep in mind that some Actions use the result from preceding Actions in the Workflow. You might need to test those prior Actions as well to ensure your test is relevant.

HTTP Status Codes

When you test your workflow, a debugger window will open and display a status code for every API request you make.

It would be impossible to go through all the status codes you may encounter – though we will go through a few examples below – but it is helpful to understand the five types of status codes that exist:

• 100s: Informational code that indicates the request initiated by the browser is continuing.
• 200s: Success code that indicates the browser request was received, understood, and processed by the server.
• 300s: Redirection code that indicates a new resource has been substituted for the requested resource, e.g. a page is no longer under one url but under another.
• 400s: Client error code that indicates there was a problem with the request
• 500s: Server error code that indicates the request was accepted but there was an error on the server that prevented the fulfillment of the request.

Detailed HTTP Response

In addition to the HTTP Status Code, WeWeb's workflow debugger will show you the full response from the API service you are making the request to.

You can find this response in the debugger under response > data .

Let's look at a few specific examples.

Example 1: Invalid Credentials

In the example below, we tested the Xano Login Action in the Workflow.

You can see a lot of helpful information in the debugger on the right.

The first thing we can see is that we got an Error because the "Request failed with status code 500". This is a pretty vague error code that tells me the server is having an issue with my request.

Not a problem, there's more info in the debugger under response > data :

This tells us we tried to login using invalid credentials.

The solution is pretty simple in this case. All we have to do is check our credentials and try again 🙂

Ok, next example.

Example 2: Incorrect Input Type

This time, we're attempting a CRUD using Airtable.

When we test the Workflow, we can see two things right off the bat:

1. Action 2 never starts, meaning the Workflow failed during Action 1, and
2. Airtable returns a 422 error code

If we dig deeper in response> data, we can get more information:

• the error is "INVALID_VALUE_FOR_COLUMN", and
• the message is "Field "Mileage" cannot accept the provided value".

Now, this might seem cryptic to you and understanding error messages from APIs is a form of art at times but you'll get the hang of it 🙂

In this case, it's telling me something about the "Mileage" field in my Airtable base. It's telling me it can't accept the value WeWeb is sending.

And sure enough, if I check the Input type I'm using in WeWeb to send the mileage information to Airtable, I notice I used a "Short answer" instead of a "Number":

Again, once you understand the error, the solution is simple.

All I need to do is change that Input type in WeWeb to match the Field type in Airtable, refresh my page, and test the Workflow once more:

Now Action 2 goes through as well and red error messages are replaced by green success messages.

Example 3: Incorrect Variable

In a similar case with Xano, you could get a response saying you are trying to send an "Invalid email format":

The first thing you would do is to check that the input field is of the correct Type, i.e. "Email"

If that were the case as it is above, the next thing you would do is check if the "email" field in your API request is mapped to the correct input field variable:

In the example above, you can see we made a mistake, we were trying to send a text value to the email field in Xano.

That's why Xano's API returned a 400 error with a message saying "Invalid email format."

The solution is simple: bind the email field to the correct email variable.

Example 4: API Rate Limits

Something that can happen often when you are using third-party APIs is that you can run into API rate limits.

When that happens, you will see a 429 status error message.

This has nothing to do with a mistake you made but everything to do with rate limits imposed by the API you're using.

When that happens, you might want to read your API provider's documentation to check if there's something you can optimize on your side or if you can upgrade your plan with them to set higher limits.

🔥 Pro Tip 🔥

If you are working with an Airtable Collection in Dynamic Mode, you will probably run into this at least once so it's a good error code to keep in mind.

Debugging Checklist

Ok, now that we've gone through a few examples of errors you can run into when working with workflows, let's recap the questions that will help you uncover mistakes and fix errors.

1. Do I have the correct trigger on the correct element? (e.g. "on submit" if I'm using a "Form Container")
2. Does my Form Input Type match the Field Type in my backend? (refer to example 2)
3. Did I use the correct API endpoint URL?
4. Did I use the correct API request method? (e.g. POST, GET, DELETE)
5. Do the names of my keys in WeWeb match the names of my keys in my backend? (bearing in mind these are case sensitive)
6. Did I bind the correct variable to each key? (refer to example 3)
7. Am I hitting API limits (refer to example 4)
8. Did I input the correct values in the Form Input fields (refer to example 1)
9. Does the API request I am making require authentication headers?
10. Does the API I am working with accept client-side requests or do I need to enable the server-side option?