Securing API Endpoints

Security in your API Endpoints is crucial to ensure you protect sensitive operations with the right access controls and checks.

There are various ways you can secure your API Endpoints, depending on exactly how granular you need the security measures to be.

Authentication restrictions (broad restrictions)

At a base level, API Endpoints have a quick way to apply the following access controls to limit who can call the API Endpoint:

• Public — Anyone can call the endpoint (only for non‑sensitive reads)
• Authenticated — Only signed‑in users can call it
• Role‑based — Only users with a specific role (for example, admin) can call it

You can manage roles in Data & API → Auth → Users and roles.

To learn more, see: Users and roles →

Restricting data to specific users (row‑level access)

To make sure users only see their own data in lists and lookups, combine a User column with a filtered view:

1. In your table, add a column of type User (for example, owner_user_id)
2. Create a view on the table
3. Add a filter: owner_user_id = auth.user.id
4. Set the view's security restriciton to Authenticated, so only users who are signed in can access it

Now, when a signed‑in user fetches data through this view, they only get rows where they are the owner.

Custom logic for permissions (Middleware)

If you need to add your own security logic, you can utilize Middleware.

Middleware sits between the request to the API Endpoint and the API Endpoint itself.

Because middleware sits between the interface and API Endpoint, it is the ideal place for us to add custom security checks to make sure the user has the necessary credentials and privileges, such as:

• Verify that the user owns the resource they're trying to access
• Limit access by subscription/plan features (e.g., only Pro can call export endpoints)
• Limit the amount of sensitive actions per user/IP to prevent abuse
• Validate inputs before touching the database
• Time‑bound access windows (e.g., only allow submissions before a deadline)

Example flow:

1. Retrieve the incoming inputs (e.g., record_id)
2. Fetch the record from a table
3. Compare the record's owner to auth.user.id (or verify role)
4. If not allowed, return an error response (e.g., 403)
5. If allowed, continue with your table updates or external API calls

This approach ensures only the right users can proceed, even if someone tries to call the API Endpoint directly.

CONTINUE LEARNING

Put it into practice by creating an API Endpoint and applying access controls.

Create your first API Endpoint →