Return

Securing Table Views & APIs

Protect your table views and API Endpoints so users only retrieve and change the data they should.

Steps at a glance

1. Secure the table view that retrieves data.
2. Secure the API Endpoint that changes or returns sensitive data.
3. Add middleware when simple access rules are not enough.
4. Test while signed in, signed out, and with the wrong user role.

1) Secure the table view

Use the view as your first line of protection when your interface retrieves rows from a table.

1. Open Data & API → Tables.
2. Open the table view your interface uses.
3. In the view settings, set Access to Authenticated if users must be signed in.
4. Add filters so users only retrieve the rows they should see.

Common examples:

• A User column stores who owns each row.
• The view filter checks that column against the signed-in user.
• The result is that each user only retrieves their own records.

This matters because hiding items in the interface is not enough on its own. The table view itself should only return allowed data.

2) Secure the API Endpoint

Use the API Endpoint Security panel when users should not be able to call an endpoint freely.

1. Open Data & API → API Endpoints.
2. Select your endpoint.
3. In Security, choose the smallest access level that fits:
   • Public For non-sensitive actions anyone can use.
   • Authenticated For actions that require a signed-in user.
   • Role-based For actions only certain roles should use, such as admin.

3) Add middleware for custom checks

Use middleware when you need more than a simple signed-in or role check.

Examples:

• Make sure the current user owns the record they are trying to update.
• Block an action unless the user belongs to the right workspace or team.
• Stop the workflow and return a 403 response when the check fails.

Because middleware runs before the main API Endpoint, it protects the endpoint even if someone tries to call it directly.

4) Test it quickly

1. In preview mode, retrieve data through the table view while signed in and signed out.
2. Trigger the API Endpoint with an allowed user.
3. Trigger it again while signed out or with the wrong role.
4. Confirm the view returns only allowed rows and the API blocks access when it should.

Common pitfalls

The page looks secure, but users can still retrieve the data

• Protect the table view or API Endpoint itself, not only the interface.

Signed-in users can still see each other's rows

• Add a filter to the table view so it only returns rows linked to the current user.

The API is protected, but it still changes the wrong record

• Add middleware to check ownership before the main workflow runs.

Everything works in preview but fails in production

• Check that your live app uses the right auth setup, roles, and environment values.

Related guides

Using user roles

Control what users can see and do by assigning roles and checking them in your app.

Beginner7 min

Using table views

Use views to save filters and reuse the same dataset across your project.

Beginner6 min