How DSALTA integrates with Datadog — data collected, setup guide, and automated compliance checks.
Overview
How to connect
Automated checks
Useful links
DSALTA connects to Datadog using read-only API access to collect compliance evidence automatically. Data feeds into your Data Library modules.
Read-only access. DSALTA never modifies, creates, or deletes resources in your Datadog environment.
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.
DSALTA reads the Datadog user roster — names, emails, roles and active status, which appears on your Access page; and incidents, which appear on your Incidents page.It calls these Datadog endpoints:
/v2/users
/v2/incidents
Permissions the checks require:incident_read, user_access_readEvery request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Datadog environment.
There is no Reconnect button. Open Integrations → Connected, click Manage on the Datadog card, and check the Status tab — it shows either Connected and working properly or Connection issues detected. To restore a broken connection you must Disconnect and connect again, which permanently deletes the data and tests collected from Datadog. Datadog API keys and application keys are long-lived and have no built-in expiration, so this usually means the key was deleted, or the user who created the Application key was disabled — Datadog revokes that user’s application keys.
Data is not syncing
Verify the connected account still holds the permissions this integration requires. Then open Integrations in the DSALTA sidebar, stay on the Connected tab, and click Sync from integrations at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
Before you begin
You need a Datadog user with permission to create application keys — without it, the New Key button under Organization Settings → Application Keys isn’t available.
1
Start in DSALTA
Open Integrations in the DSALTA sidebar, find Datadog, and click Connect to open the connect panel.
2
Choose your Datadog site
Your site is the host in your Datadog URL — e.g. app.datadoghq.com → datadoghq.com, app.datadoghq.eu → datadoghq.eu, plus us3.datadoghq.com / us5.datadoghq.com / ap1.datadoghq.com / ap2.datadoghq.com / ddog-gov.com / us2.ddog-gov.com. You’ll type it into the Site Parameter field in the next step — the host only, with no https:// and no app. prefix.
3
Create an API key and an Application key
In Datadog: Organization Settings → API Keys → New Key (copy the API key). Then Organization Settings → Application Keys → New Key (copy the Application key). The Application key inherits the creating user’s permissions — use a user (or scope the key) with User Access Read (to sync users) and Incidents Read (to sync incidents; requires Incident Management enabled). You’ll paste the site, API key, and Application key in the next step.
Copy the Application key the moment it’s created — on some Datadog sites the key secret can’t be retrieved afterwards and you’d have to create a new one.
If you use Edit scopes while creating the Application key, tick both user_access_read and incident_read — a scoped key gets only the scopes you select and nothing else, and those scopes stay fixed even if the creating user’s role changes later. Leave scopes blank and the key follows the creating user’s permissions instead.
API key names must be unique across your organization, and an organization can hold up to 50 API keys by default — if creation fails, check whether a key with that name already exists.
Do not create the Application key from a personal account you may offboard. Datadog revokes every application key a user created the moment that user is disabled, which silently breaks the DSALTA connection. Create it from a Datadog service account, or from an account that will outlive the person who set this up.
Incidents are optional. If Incident Management is off, or the Application key lacks incident_read, the user sync still succeeds and your Access page fills normally — but the “Reported incident should be closed” check will report Failed rather than passing. Turn on Incident Management, or expect that one check to stay red.
4
Finish in DSALTA
Return to the connect panel you opened in step 1, enter the credential you just created, and confirm to complete the connection.
Once connected, Datadog appears on the Connected tab and the checks below begin reporting after the first sync.
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.