Skip to main content
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.
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.
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.