> ## 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. # LimaCharlie > SecOps cloud platform — users, sensors, detections & access Connect LimaCharlie with an Organization API key to sync the organization's users with their permission-derived roles, enrolled sensors as devices, and detections as incidents, and run access reviews. Read-only. Data feeds into your Access accounts, Devices and Incidents 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 users of one LimaCharlie **organization** — the one whose Organization ID you enter at connect time. Users who hold access through a direct grant and users who reach the organization through a group are both listed, one row per email address. LimaCharlie's user list carries no name, so each row shows the user's **email address** in place of a name. LimaCharlie reports no role either: the role is derived from the permissions the user holds — **Owner** for a user with billing control, **Administrator** for a group admin or any user with a control permission, **Operator** for a user who can set, delete, task, run or isolate, **Viewer** for a user with read-only permissions, and **Basic** for a user with none. The user list has no status field, so every user is shown as **Active** and stamped with the date of the sync. API keys are not users and never appear, and neither do invitations: LimaCharlie adds a user only once they hold an account, and sends an invitation email otherwise. LimaCharlie 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 organization's user list with the permissions of each user — email, user ID and permission set, for direct and group-derived grants alike — which appears on your **Access** page; the organization's enrolled **sensors**, which appear on your **Devices** page; and the organization's **detections** from the last 30 days, which appear on your **Incidents** page. Each sensor arrives as a device named after its hostname (or its sensor ID when it has none), identified by its sensor ID, with the platform LimaCharlie reports (Windows, Linux, macOS, iOS, Android, ChromeOS, VPN, or an adapter type) and its architecture code in place of an operating-system version. A sensor carries no user, so every LimaCharlie device lands on the **Unmonitored** tab until you assign it to a person. A sensor also reports no disk-encryption, screen-lock, antivirus or password-manager signal, so those four columns show ✗ on every LimaCharlie device — treat them as unreported rather than failing, whatever the machine's real configuration. Each detection arrives as an incident titled with its category and the hostname it fired on, with the rule, namespace, sensor, event type and dashboard link in the description; it is typed **detection**, its severity follows the detection's priority (4 and above is **Critical**, 3 is **High**, 2 is **Medium**, anything else is **Low**), and its status is always **Open**, whatever its state in LimaCharlie. Incidents fills once a detection fires; at most 1,000 detections are read per sync. Devices and detections are replaced on every sync: a sensor removed in LimaCharlie disappears from Devices, and a detection older than 30 days disappears from Incidents. The Inventory page is not fed by this integration — the organization's API keys, installation keys and outputs are not read, and neither are the audit trail, cloud-security findings or the sensors' telemetry. It exchanges the key for a one-hour session token at `jwt.limacharlie.io`, then calls these LimaCharlie endpoints on `api.limacharlie.io/v1`: * `/orgs/{oid}` * `/orgs/{oid}/users/permissions` * `/sensors/{oid}` * `/insight/{oid}/detections` (with a 30-day window) Apart from that token exchange, every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your LimaCharlie environment. ## Troubleshooting The Organization ID is wrong — LimaCharlie answers **org not found** — or the key is not an **Organization API key** from **Access Management → REST API**: a User API key from the profile menu, or a mistyped key, is answered with **unknown api key**. Otherwise the key lacks the **user.ctrl** privilege, and the message says so by name; ticking every get and list box does not supply it. Regenerate the key with user.ctrl ticked, check the OID in the console address bar after `/orgs/`, and connect again. Sensors and detections are read best-effort after the user list: a failure on either call leaves that page empty without failing the sync, and a key without **sensor.list** or **insight.det.get** leaves the matching page empty with no error. Devices lists only enrolled sensors, Incidents fills once a detection has fired, and only detections from the last 30 days are read. Click **Sync from integrations** on the **Integrations** page to retry. LimaCharlie's user list reports permissions, not roles, so the role column is derived from the permission verbs each user holds. A user whose permissions were granted one by one, or through a group, can land on a different rung than the role they were added with. Review the user's permissions and groups under **Access Management → Users**. 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 LimaCharlie Organization API key with the user.ctrl privilege, plus the Organization ID. Read-only. **Before you begin** * A LimaCharlie organization **Owner** or **Administrator** — only they can generate an Organization API key with user.ctrl. You will need: | Field | Where to find it | Example | | - | - | - | | **Organization ID (OID)** | The address bar after `/orgs/`, or the organization settings | `12c1bb1c-251d-48ba-a79c-130372626625` | | **Organization API key** | The organization → **Access Management → REST API** | Copied when the key is generated | Open **Integrations** in the DSALTA sidebar, find **LimaCharlie**, and click **Connect** to open the connect panel. Sign in at [app.limacharlie.io](https://app.limacharlie.io) and open the organization to review. The Organization ID (OID) is the UUID in the address bar after `/orgs/`, and is also shown in the organization settings. Open **Access Management → REST API** and generate an Organization API key. Tick **user.ctrl** plus **org.get**, **sensor.list** and **insight.det.get**, then copy the secret. **Tick user.ctrl explicitly.** The user list is gated by it, and ticking every get and list box does not supply it — a key without user.ctrl is rejected at connect time. Use an Organization API key, not a User API key from the profile menu: a User key spans every organization its user can reach. Do not add a flair such as `[segment]` to the key's name — it limits the key to resources the key itself created — and leave the allowed IP range unset. Return to the connect panel, enter the Organization ID, paste the API key, and click **Connect**. DSALTA validates the credentials when you click **Connect**, by exchanging the key for a session token, checking that the token carries user.ctrl, reading the organization, and listing its users. 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.** A wrong Organization ID, an invalid key or a User API key instead of an Organization API key, a key without the user.ctrl privilege, or an organization whose user list comes back empty. 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/limacharlie/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with LimaCharlie access is an active employee on the People page. | | [Offboarded users should not have active access](/integrations/limacharlie/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active LimaCharlie access. | | Topic | Link | | - | - | | Setup | [LimaCharlie API keys](https://docs.limacharlie.io/7-administration/access/api-keys/) | | Remediation | [LimaCharlie user access](https://docs.limacharlie.io/7-administration/access/user-access/) | | General | [LimaCharlie console](https://app.limacharlie.io) | | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |