> ## Documentation Index > Fetch the complete documentation index at: https://help.dsalta.com/llms.txt > Use this file to discover all available pages before exploring further. # SeaTable > Spreadsheet database — members, MFA & access Connect SeaTable with a team administrator's Account-Token to sync team members with their two-factor status, bases, and groups, and run access and MFA reviews. Read-only. Data feeds into your Access accounts and Inventory pages. **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product. **What you'll see.** The Access page lists the **members** of the SeaTable team the Account-Token belongs to — a SeaTable user belongs to exactly one team — with their name (or their contact email address when SeaTable stores no name), their contact email address (SeaTable's internal `…@auth.local` login id is used only when the member has no contact email), their team role (**Team Administrator** or **Member**) and the date their account was created. SeaTable has no pending-invitation state on the team roster, so every row is a member. SeaTable's own status is respected: a member the team administration has marked inactive is shown as **Inactive**, everyone else as **Active**. SeaTable does report per-user two-factor authentication, so the **MFA** column shows **Yes** or **No**, and is blank (a dash) for a member whose record carries no value. DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York. ## What DSALTA reads DSALTA reads the SeaTable team member roster — names, contact emails, team roles, active state, two-factor flags and creation dates — which appears on your **Access** page; and your SeaTable **bases** (row count, whether the base is encrypted, its group and its owner) and **groups** (member count and owner), which appear on your **Inventory** page. Bases and groups are read best-effort after the roster: bases come from the team administration's base list, falling back to the workspaces the token's user can see when that list is empty or cannot be read (rows from the fallback carry no row count or owner), and a failure on either call leaves that part of the Inventory page empty without failing the sync. The rows inside your bases are never read, and neither are the team's operation log and login log. Members' last-login times are not synced. It calls these SeaTable endpoints on `cloud.seatable.io` (or the host you enter for a self-hosted server): * `/api2/account/info/` * `/api/v2.1/org/admin/info/` * `/api/v2.1/org/{orgId}/admin/users/` * `/api/v2.1/org/{orgId}/admin/dtables/` * `/api/v2.1/workspaces/` — only when the base list above is empty or fails * `/api/v2.1/org/{orgId}/admin/groups/` Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your SeaTable environment. ## Troubleshooting The token is not an Account-Token: a base **API-Token** (created per base in the SeaTable UI) or a **Base-Token** cannot read the team and is rejected. An Account-Token minted from an account that is not a team administrator is rejected too, because only a team administrator can list the team's members — the first person who registered the team is one, and a member added later is not until promoted. For a self-hosted server, a wrong **Host** is rejected the same way as a bad token. DSALTA matches members by the contact email address stored in SeaTable. A member whose SeaTable account has no contact email falls back to the internal `…@auth.local` login id, which matches nobody. Give the member's SeaTable account a contact email, then click **Sync from integrations** on the **Integrations** page. Bases and groups are read best-effort after the roster: a failure on either call leaves that part of the Inventory page empty without failing the sync, and a team that has not created a base or a group yet has nothing to list. Click **Sync from integrations** on the **Integrations** page to retry. Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**. Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state. On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side. A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results). Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once. There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again. **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors). That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again. A SeaTable Account-Token minted from the team administrator's login. The team is detected automatically. Read-only. **Before you begin** * A SeaTable team administrator account — the first registrant is one; a member added later is not until promoted. * A way to send one HTTP POST request: there is no button in SeaTable for an Account-Token. You will need: | Field | Where to find it | Example | | - | - | - | | **Account-Token** | Minted with `POST https://cloud.seatable.io/api2/auth-token/` from the team administrator's email and password | 40 characters | | **Host (optional)** | Only for a self-hosted SeaTable server | `cloud.seatable.io` (default) | Open **Integrations** in the DSALTA sidebar, find **SeaTable**, and click **Connect** to open the connect panel. The token must come from a team administrator. Team management lives at [account.seatable.com](https://account.seatable.com/); every API call goes to `cloud.seatable.io` (or your self-hosted server). There is no button for it. Send your login to `POST https://cloud.seatable.io/api2/auth-token/` with the form fields `username` (your email) and `password`; if two-factor authentication is on for your account, add the `X-SEAFILE-OTP` header with your current code. The response is `{"token": "<40 characters>"}`. **Do not use a base API-Token or a Base-Token.** A base API-Token is created per base in the SeaTable UI and a Base-Token reads row data; neither can read the team, and DSALTA rejects both at connect time. You mint the token yourself and paste only the token: DSALTA never sees your password, and it never calls the token endpoint. Return to the connect panel and paste the Account-Token. Enter a host only if you run a self-hosted SeaTable server; leave it empty for SeaTable Cloud. Then click **Connect**. DSALTA validates the token when you click **Connect**, by reading its account record, checking that the account is a team administrator, and listing the team's members. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync. **If the connection is rejected.** An invalid token, a base API-Token or Base-Token instead of an Account-Token, an account that is not a team administrator, or a wrong host for a self-hosted server. The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages). Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance. | Check | Severity | What it verifies | | - | - | - | | [User access to Critical System should be valid](/integrations/seatable/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with SeaTable access is an active employee on the People page. | | [Offboarded users should not have active access](/integrations/seatable/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active SeaTable access. | | [MFA should be enabled for all users](/integrations/seatable/mfa-enabled-for-all-users) | High | Checks that every SeaTable team member has two-factor authentication enabled. | | Topic | Link | | - | - | | Setup | [SeaTable API: get an Account-Token](https://api.seatable.com/reference/getaccounttokenfromusername) · [Authentication](https://api.seatable.com/reference/authentication) | | Remediation | [Team management features overview](https://seatable.com/help/team-management-features-overview-seatable/) | | General | [SeaTable Cloud](https://cloud.seatable.io) · [Team management](https://account.seatable.com/) | | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |