> ## 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. # Supervisely > Computer-vision labeling — members, projects & access Connect Supervisely with a team admin's API token to sync team members with their roles and status, teams, workspaces and projects, and the team activity feed, and run access reviews. Read-only. Data feeds into your Access accounts, Inventory and Changes 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 every Supervisely **team** the token's user belongs to, combined into one roster: a person who is in several teams appears once, with their role in each team joined in the role column (for example **Admin**, **Developer**, **Annotator** or **Viewer**, or **Member** when Supervisely reports none). Each row shows the member's name, or their login when Supervisely carries no name; a member whose account has no email address is listed by login in the email column. Invitations that have never signed in are left out; annotator and viewer accounts are kept, since they may belong to external contractors. A member Supervisely reports as disabled in any team is shown as **Inactive**; everyone else is **Active**. Each row is stamped with the creation date Supervisely reports for the member, or the date of the sync when none is reported. Supervisely reports no per-user MFA state, so the **MFA** column is blank (shown as a dash). 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 team member rosters — names, logins, emails, roles, disabled state and creation dates — which appear on your **Access** page; your Supervisely **teams** (description), **workspaces** (team, description and whether hidden) and **projects** (type, item count and team), which appear on your **Inventory** page; and each team's **activity feed**, which appears on your **Changes** page. Workspaces, projects and activity are read best-effort per team after the roster, and projects appear once you have created one. Each activity event arrives as a change that has already happened — status **Deployed**, priority always **Low**, the action as its type, a title of the form *action by user*, the project, dataset, workspace, job or member it touched plus its time in the description, and the team name as the environment. Only the first 1,000 events of each team's feed are read, with no date window, and at most 1,000 changes are recorded in total. Members' last-login times and sign-in counts are not synced, and Supervisely's instance-wide user list is never read. Every call is a `POST` with a JSON body to `app.supervisely.com/public/api/v3` (or your Enterprise instance's host): * `/users.me` * `/teams.list` * `/members.list` * `/workspaces.list` * `/projects.list` * `/teams.activity` Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Supervisely environment. ## Troubleshooting The token is invalid or truncated, the **Host** points at the wrong Enterprise instance, or the token's user is a member of no team. Copy the token again from **Account Settings → API Token** as an admin of the team to review, leave the host empty for the Supervisely cloud, and connect again. A token whose first team lists no members is also rejected. Clicking **re-generate api key** on the **API Token** tab revokes the token DSALTA is using. Copy the new token, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from Supervisely. The token is personal: it only sees the teams its user belongs to. Use the token of an account that is an admin of every team you want reviewed. If one team's member list cannot be read, the sync fails rather than recording a partial roster. 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 Supervisely personal API token of a team admin. Teams are detected automatically. Read-only. **Before you begin** * A Supervisely account that is an admin of the team to review — the token carries that user's team roles. * For a self-hosted Enterprise instance, its host name; the Supervisely cloud needs none. You will need: | Field | Where to find it | Example | | - | - | - | | **API token** | Your name (top right) → **Account Settings → API Token** | 128-character token | | **Host (optional)** | Only needed for an Enterprise instance | `app.supervisely.com` when left empty | Open **Integrations** in the DSALTA sidebar, find **Supervisely**, and click **Connect** to open the connect panel. Sign in at [app.supervisely.com](https://app.supervisely.com) (or your Enterprise instance) with an account that is an admin of the team you want to review. The token is personal and only sees that user's teams. Click your name (top right), choose **Account Settings**, open the **API Token** tab and copy the token. **Do not click re-generate api key.** It revokes the current token, including one an already-connected integration is using. Return to the connect panel, paste the token, enter a host only for an Enterprise instance, and click **Connect**. Teams are detected automatically. DSALTA validates the token when you click **Connect**, by reading your own user record, listing the teams the token's user belongs to and reading the members of the first team. A token that sees no team, or whose first team lists no members, is rejected. 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 or truncated token, a wrong host for an Enterprise instance, an account that belongs to no team, or a token whose first team lists no members. 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/supervisely/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with Supervisely access is an active employee on the People page. | | [Offboarded users should not have active access](/integrations/supervisely/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active Supervisely access. | | Topic | Link | | - | - | | Setup | [Supervisely API authentication](https://developer.supervisely.com/getting-started/basics-of-authentication) | | General | [Supervisely](https://app.supervisely.com) | | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |