Intro to Middleware

Middleware lets you easily create reusable rules to control what users can access.

How they work

In the Security panel of API Endpoints, and in the access settings of table views, you have the ability to add Middleware you wish to run.

To open them, click the access button at the top of the API Endpoint (it shows Public or Auth) or in the table view header (it shows Public or Authenticated). Then click Add middleware for more control and pick your Middleware in the Select middleware dropdown. If you add several Middleware, they run one after the other, in the order you added them. Once an API Endpoint has Middleware, its access button adds +WF to its label (for example Public+WF).

Adding Middleware allows you to have more granular security controls beyond simply checking if a user is signed in or if they have a certain role.

When you add Middleware, the Middleware will be the first thing that runs (right after the Public, Authenticated and role checks). For example, if you add Middleware to an API Endpoint, then the Middleware will run before the API Endpoint.

This ensures the user has the necessary permissions to access the API Endpoint.

Example use cases

Ownership check

Make sure the current user owns the record they’re trying to edit or read.

Example use: run in an update-order API Endpoint to ensure the user has access to the order they're trying to update.

Team or workspace membership

Only allow access if the user belongs to a given team/workspace.

Example use: in a get-project API Endpoint, check that the user is a member of the project’s team that they're trying to retrieve.

Feature or plan gating

Allow access only for certain plans or features you’ve enabled.

Example use: in a generate-invoice API Endpoint, check that the user is on the plan that gives them access to this feature.

Block suspended or flagged users

Stop any action if the account is marked as suspended/flagged.

Example use: in all API Endpoints, check that the user's status is not 'suspended'.

Core parts of Middleware

Input Parameters

Input parameters allow dynamic values to be passed into your Middleware, so the values can then be used in the logic of the Middleware. You add and manage them from the Parameters panel.

For example, if you had Middleware to check if an order belongs to a given user before letting them retrieve an order, you may have an orderId input parameter for the Middleware.

Logic

The logic is where you create the core checks the Middleware needs to perform.

To make your logic dynamic, you can use the values that have been passed into the inputs.

In the example of Middleware to check if a given order belongs to the user trying to retrieve it, the logic would look something like the following:

1. Retrieve the order where order_id = the input orderId
2. Have a True/False split where the condition of the split checks if the user_id the order is linked to is the auth.id (the user making the request)
3. In the False branch (the logic to run if the order does not belong to the user), use the Send Response action to send a 403 - Forbidden error

Error response

Returning an error response if your checks are not successful is critical for your Middleware to perform as expected.

Like in step 3 in the 'Logic' section above, if your checks do not pass, then you need to use the Send Response action to return a 403 - Forbidden response.

Returning an error response is critical because it will mean that the API Endpoint or table view you are using the Middleware on will not run. If your Middleware ends without sending a response, the request continues as if the checks had passed.

If you want to let the request continue early (for example, in one branch of a True/False split, without running the rest of the checks), use the Next action. It ends the Middleware right away and moves on to the next Middleware, or to the API Endpoint or table view itself.

Since the Middleware is the first thing to run, if the Middleware throws an error, then nothing after the Middleware will run: