> ## 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. # TiDB Cloud > Distributed SQL cloud — members, clusters & access Connect TiDB Cloud with an organization API key pair to sync organization members with their roles and status, API keys and clusters, and the console audit log, 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 one TiDB Cloud **organization** — the one the API key pair belongs to — with their first and last name (or their email address when TiDB Cloud reports no name), their email, their organization role (**Organization Owner**, **Organization Member**, **Billing Admin**, **Billing Viewer**, **Audit Admin** or **Organization Viewer**; a member who holds only project roles shows the first of them, for example **Project Owner**, and a member with neither shows **Member**) and the date they were invited (or the date of the sync when TiDB Cloud reports none). People whose invitation is still pending are left out. A member whose status TiDB Cloud reports as active — or reports no status for — is shown as **Active**; any other status is shown as **Inactive**. TiDB Cloud 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 TiDB Cloud organization member roster — names, emails, roles, status and invitation dates — which appears on your **Access** page; the organization's **API keys** (display name, role, creator and creation date — never the access key or the secret, which are dropped before the rows leave the API client) and its **clusters**, both the Starter and Essential instances and the Dedicated clusters (name, region, state and version), which appear on your **Inventory** page; and the organization's **console audit log**, which appears on your **Changes** page. Each audit entry arrives as a change that has already happened — status **Deployed**, priority always **Low** because the log carries no severity, the event name and the acting user in the title, the source IP and the result in the description, and **TiDB Cloud console** as the environment. Up to 1,000 entries are read, with no date window. The Changes page stays empty until Console Audit Logging is enabled in the TiDB Cloud console, and events before enablement are never recorded. Members' last-login times are not read. It calls these TiDB Cloud endpoints, on three hosts: * `https://iam.tidbapi.com/v1beta1/members?pageSize=100` * `https://iam.tidbapi.com/v1beta1/apiKeys?pageSize=100` * `https://iam.tidbapi.com/v1beta1/auditLogs?pageSize=100` * `https://serverless.tidbapi.com/v1beta1/clusters?pageSize=100` * `https://dedicated.tidbapi.com/v1beta1/clusters?pageSize=100` Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your TiDB Cloud environment. ## Troubleshooting The key pair is not an organization-scoped key with the **Organization Owner** role. A key created with the **project** scope cannot list the organization's members, and the public/private pair minted under **Data Service → Data App → API Keys** looks identical but only queries a Data App. Create the pair under **Organization Settings → API Keys** with the organization scope and the Organization Owner role, and connect again. A pair that authenticates but returns no members is rejected for the same reason: the organization always has its owner, so an empty list means the key cannot see the roster. Console audit logging is off by default in TiDB Cloud, and events before it was enabled are never recorded. In the console, open **Console Audit Logging** in the left navigation, then **Settings**, and enable it; only the Organization Owner or a Console Audit Manager can see this option. The audit log is read best-effort after the member roster, so a failure on that call leaves the page empty without failing the sync. Click **Sync from integrations** on the **Integrations** page to retry. API keys and clusters are read best-effort after the member roster: a failure on either cluster call leaves those rows out without failing the sync. Clusters appear once you have created one; the Dedicated cluster list may be unavailable to an organization without Dedicated clusters and then contributes nothing. The key you pasted into DSALTA always appears as an API-key row. 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 TiDB Cloud organization API key pair (public + private key) with the Organization Owner role. The organization is detected automatically. Read-only. **Before you begin** * The TiDB Cloud **Organization Owner** role — only the owner can create organization API keys. You will need: | Field | Where to find it | Example | | - | - | - | | **Public key** | **Organization Settings → API Keys → Create API Key** (`tidbcloud.com/org-settings/api-keys`) | Copied from the API Keys page | | **Private key** | Shown next to the public key when the key is generated | Shown once, at creation | Open **Integrations** in the DSALTA sidebar, find **TiDB Cloud**, and click **Connect** to open the connect panel. Sign in at [tidbcloud.com](https://tidbcloud.com) as the Organization Owner and pick the organization in the upper-left switcher. Other roles cannot create organization API keys. In the left navigation open **Organization Settings → API Keys** and click **Create API Key**. Add a description, choose the **organization** scope with the **Organization Owner** role, click **Generate API Key**, and copy both the public key and the private key, then click **Done**. **The private key is shown once.** TiDB Cloud warns that after you leave the page you will not be able to get the full private key again. Choose the organization scope, not a project: a project-scoped key cannot list the organization's members. Do not use the keys under **Data Service → Data App → API Keys**: they look the same but only query a Data App, and DSALTA rejects them at connect time. For the Changes page, enable Console Audit Logging in the console: left navigation → **Console Audit Logging** → **Settings**. It is off by default, and events before enablement are never recorded. Return to the connect panel, paste the public key and the private key into their fields, and click **Connect**. DSALTA validates the key pair when you click **Connect**, by listing your organization's members with it; a pair that returns 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 key pair, a project-scoped key, a Data Service key instead of an organization API key, or a pair that 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/tidb-cloud/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with TiDB Cloud access is an active employee on the People page. | | [Offboarded users should not have active access](/integrations/tidb-cloud/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active TiDB Cloud access. | | Topic | Link | | - | - | | Setup | [TiDB Cloud API overview and API keys](https://docs.pingcap.com/tidbcloud/api-overview/) · [Console audit logging](https://docs.pingcap.com/tidbcloud/tidb-cloud-console-auditing/) | | Remediation | [Manage user access](https://docs.pingcap.com/tidbcloud/manage-user-access/) | | General | [TiDB Cloud console](https://tidbcloud.com) | | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |