Debugging workflows

Debugging is an inherent part of app building.

When you start working with workflows, there's a good chance you'll run into errors at times.

The Debug panel allows you to see in detail exactly what workflows ran, and how they ran.

Testing workflows in the Debug panel

If you're experiencing issues with a workflow, open the Debug panel in the Interface left sidebar and check the Logs tab while you run the workflow.

In the example below, we see that the issue comes from the first action – which is highlighted in red – and if we look into the API's response, we can see the issue is that the user tried to login with invalid credentials:

If you're working with a more complex Workflow, you can test an individual Action instead of the entire Workflow.

In the example below, we test the first action and see the same API response informing us that the user tried to login with invalid credentials:

Status Codes

When you test your Workflow, the Debugger will display a status code for every API request you make.

It would be impossible to go through all the status codes you may encounter but let's review the ones you'll encounter most often.

200 Success

When your API request was processed as expected, you'll get a 200 success message.

For example, when you successfully created a new record in your database:

401 Unauthorized

When the server will not process your request because it lacks valid authentication credentials.

For example, when you try to create a new record in a table that's protected by an Authentication System without providing valid auth credentials:

The solution: check the credentials you are using to authenticate and try again.

403 Forbidden

When the server understood the request but refuses to fulfill it.

For example, when a normal user tries to perform an action that is reserved to users with an admin role.

The solution: make sure you are testing the Workflow with a user who has the right to perform the action.

422 Invalid value

When the server doesn't like the data type you're sending

In the example below, you can see the Mileage value we send on the left is a string ("7864") and returns an error whereas the value we send on the right is an integer (506) and returns a success message:

The solution: make sure you are sending the data in a format that is expected by your database.

In the example above, we mistakenly used a Short answer input on our first tried and finally got a success message when we changed the input type to Number.

429 Too many requests

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.

TIP

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

Network error and CORS

Interface workflows that call external APIs from the browser can fail with a network or CORS error when the API does not allow client-side requests.

For APIs that require server-side calls or secrets:

1. Create the request in a backend workflow in the Data & API tab (for example, an HTTP Request action)
2. Call that backend workflow from your interface workflow with Execute workflow

Do not put private API keys in interface workflows. Sensitive calls belong in backend workflows where credentials stay on the server.

For public APIs that support browser requests, you may still see CORS errors if the provider blocks your domain. In that case, route the call through a backend workflow instead.

Debugging Checklist

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

• Am I hitting API rate limits?
• Did I bind the correct variable to each key?
• Do my form input types match the field types in my database?
• Does the API request I am making require authentication headers?
• Does the API I am working with accept client-side requests or do I need to enable the server-side option?
• Do I have the correct trigger on the correct element? (e.g. "on submit" if I'm using a "Form Container")
• Did I use the correct API endpoint URL?
• Did I use the correct API request method? (e.g. POST, GET, DELETE)
• Do the names of my keys in WeWeb match the names of my keys in my backend? (bearing in mind these are case sensitive)