> ## 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.

# LambdaTest

> Cross-browser & app testing cloud — members, MFA & access

<Tabs>
  <Tab title="Overview">
    Connect LambdaTest with an Admin user's username and access key to sync organization members with their MFA status, service accounts, and organizations, and run access and MFA reviews. Read-only. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **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.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the **members** of the one LambdaTest **organization** the credential belongs to — the organization is implicit in the credential, and the members of sub-organizations are not listed separately. Each row shows the member's name (falling back to their username, then their email address), their email, and their LambdaTest role as LambdaTest reports it — **Admin**, **User** or **Guest** — or **Member** when none is reported. Pending invitations and service accounts are not organization members and never appear; a Guest is a read-only member and does appear. LambdaTest reports no account status on this roster, so every member is shown as **Active** and stamped with the date of the sync. LambdaTest does report per-user MFA, so the **MFA** column shows **Yes** or **No**, and is blank (a dash) for a member whose record carries no value.
    </Info>

    <Note>
      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.
    </Note>

    ## What DSALTA reads

    DSALTA reads the LambdaTest organization member roster — names, usernames, emails, roles and MFA status — which appears on your **Access** page; and your organization's **service accounts** (username, creation date, teams and tags — never a token or access key) and the **organization** itself together with any **sub-organizations** (creation date and the number of available concurrency entries), which appear on your **Inventory** page. Service accounts appear once you have created one; the organization row appears whenever the organization call succeeds. Members' last-login times and access-key dates are not synced, and the organization's audit log is not read.

    It calls these LambdaTest endpoints on `auth.lambdatest.com` (or `eu-auth.lambdatest.com` when the region is `eu`):

    * `/api/organization/users`
    * `/api/organization/service-accounts`
    * `/api/organization/sub-org`

    Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your LambdaTest environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected">
        A wrong username or access key; a credential that is not an organization **Admin**'s — the organization endpoints are Admin-gated, and a service account's credential cannot read the members; or the wrong region: an EU-resident organization's credential sent to the US host is refused with the same error as a bad key. Enter `eu` as the region only if your organization signs in at `eu-auth.lambdatest.com`; any other value, or none, selects the US host.
      </Accordion>

      <Accordion title="The connection stopped working">
        If your organization has an **Access Key Expiry** policy, LambdaTest regenerates the access key when it expires and the connection stops working without warning. Set the policy to **Never** or add the connected user to its **Excluded Users**, copy the new key from **Account Settings → Passwords & Security**, then disconnect and connect again. Note that disconnecting permanently deletes the data already collected from LambdaTest.
      </Accordion>

      <Accordion title="Inventory shows the organization but no service accounts">
        Service accounts and the organization tree are read best-effort after the member roster: a failure on either call leaves that part of the Inventory page empty without failing the sync, and an organization that has not created a service account has nothing to list. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        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.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        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).
      </Accordion>

      <Accordion title="Data looks out of date">
        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.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **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).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        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.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    An Admin user's LambdaTest username and access key. The organization is detected automatically. Read-only.

    **Before you begin**

    * An **Admin** user of the LambdaTest organization — the organization endpoints are Admin-gated, and a service account cannot use them.
    * Your data region: leave it empty for the default host, and enter `eu` only if your organization signs in at `eu-auth.lambdatest.com`.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Username** | **Profile** (upper right) → **Account Settings → Passwords & Security** | Shown on the page |
    | **Access key** | The same **Passwords & Security** tab | Shown on the page — do not regenerate it |
    | **Region (optional)** | Your sign-in host | `eu` for eu-auth.lambdatest.com |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **LambdaTest**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in as an organization Admin">
        Sign in to LambdaTest (TestMu AI) with an Admin user of the organization you want to connect. A service account cannot read the organization's members.
      </Step>

      <Step title="Copy the username and access key">
        Click **Profile** (upper right) → **Account Settings** → **Passwords & Security**. Copy the **Username** and the **Access Key** shown there.

        <Warning>
          **Do not click any regenerate action.** That rotates the access key and breaks every pipeline that uses it. DSALTA never regenerates a key.
        </Warning>
      </Step>

      <Step title="Check the Access Key Expiry policy">
        If your organization has an **Access Key Expiry** policy, set it to **Never** or add this user to its **Excluded Users**. Otherwise the key rotates silently and the connection stops working.
      </Step>

      <Step title="Connect LambdaTest">
        Return to the connect panel, paste the username and the access key, enter `eu` as the region only if your organization is EU-resident, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the credential when you click **Connect**, by listing your organization's members with it on the host the region selects — the call that only an Admin's credential can make. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** A wrong username or access key, the wrong region, or a credential that is not an organization Admin's.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    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/lambdatest/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with LambdaTest access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/lambdatest/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active LambdaTest access. |
    | [MFA should be enabled for all users](/integrations/lambdatest/mfa-enabled-for-all-users) | High | Checks that every LambdaTest organization member has multi-factor authentication configured. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [LambdaTest user management API](https://swagger-api-support.lambdatest.com/user_management/) |
    | Remediation | [Multi-factor authentication](https://www.testmuai.com/support/docs/multi-factor-authentication/) · [Password and access key expiration policy](https://www.testmuai.com/support/docs/password-and-access-key-expiration-policy/) |
    | General | [LambdaTest sign-in](https://accounts.lambdatest.com/login) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>