API export with view‑level permissions: how to ensure users can export only views they’re authorized for?

Developer Talk API
1

Hello SeaTable Team & Community,

I would like guidance on implementing secure API-based export when using custom views with different permissions per user.

Scenario

In one SeaTable base/table, we have:

  • Base: Sample_Base

  • Table: Sample_Table

  • Views: View_001, View_002, View_003

We use custom sharing / view-level permissions so that users have access only to certain views:

User Access Requirement

  • User_001

    • Read/Write: View_001

    • No access: View_002, View_003

  • User_002

    • Read/Write: View_002, View_003

    • Read-only: View_001

API Export Requirement

We want to auto export data using SeaTable API, but the export must follow the same permissions:

  • User_001 should be able to export only View_001

  • User_002 should be able to export only View_002 and View_003 (and possibly only read-level export of View_001)

Questions

  1. When using SeaTable API, is it possible to export colums specifically from a view (e.g., export only View_001 and not full table)?

  2. What is the recommended secure approach to ensure API export respects view-level permissions?

    • Should we generate API tokens per user?

    • Should we use separate tables or separate bases instead of views?

    • Is there any built-in feature (Enterprise or advanced permissions) that supports this?

Goal

We want to avoid a security gap where:

  • Full table data pulled by user who not owner of said table’s other columns.

  • Other table data pulled by user who has no permission for said table in SeaTable

Any official recommendation, limitation confirmation, or best-practice architecture would be appreciated.

Thank you,
Rupesh Bangar

2

Good questions. Let me address them one by one based on how the SeaTable API actually works.

1. Can you export data from a specific view via API?

Yes. There are two approaches:

  • Export View to Excel: Export View exports a specific view as an Excel file. You pass table_id, view_id (or view_name), and dtable_name.
  • List Rows with view filter: List Rows accepts an optional view_name parameter. When set, only the visible columns and filtered rows of that view are returned.

Both work well for exporting view-specific data.

2. Does the API respect view-level permissions?

This is the critical point: API authentication operates at the base level, not the view level. An API token (or Base token derived from it) grants access to all data in the base. Even if you query a specific view, the token holder could also query a different view or the full table. View sharing permissions (the user/group view shares you configure in the UI) control what users see in the SeaTable web interface, but they do not restrict API access.

So while you can export only View_001 via API, nothing prevents User_001 from also querying View_002 if they hold a valid token for that base.

3. Should you generate API tokens per user?

API tokens are scoped per base with read-only or read-write permissions — there is no per-view or per-table restriction. Generating separate API tokens per user gives you an audit trail and the ability to revoke individual tokens, but it does not solve the view-level isolation problem since every token for the same base has access to all its data.

4. Recommended architecture for true data isolation

If you need to enforce that User_001 can never access View_002/View_003 data via API, you have a few options:

  • Separate bases: Move View_001 data into Base_A and View_002/View_003 data into Base_B. Then issue API tokens per base. This is the most secure and simplest approach.
  • Middleware/proxy layer: Build a thin API gateway that authenticates your users, checks their permissions, and only forwards allowed requests to the SeaTable API using a server-side token. The users never see the actual SeaTable API token. Be aware that this approach requires significant development effort and ongoing maintenance — you need to keep the permission logic in sync with your SeaTable setup, handle edge cases, and update the middleware whenever your requirements change.
  • Custom sharing views with external links: External links can be scoped to specific views and generate their own access tokens. This might work for read-only export scenarios, though it’s not designed for programmatic multi-user setups.

5. Summary / Recommendation

If strict per-view data isolation is a hard security requirement, separate bases are the cleanest solution. The SeaTable API is base-scoped by design, so view-level restrictions in the UI don’t carry over to API access. If splitting into separate bases isn’t practical, a middleware proxy that enforces your permission logic is the next best option.

Hope this helps!