> ## Documentation Index > Fetch the complete documentation index at: https://support.configview.com/llms.txt > Use this file to discover all available pages before exploring further. # Drata setup ConfigView reads your Drata account through the Drata Public API, using an **API key** that a Drata admin creates in Settings. The key is read-only, so ConfigView can look at your personnel, devices, vendors and the accounts Drata has found, and can never change anything in Drata. You will end up with **1 required secret** (`DRATA_API_KEY`) and **1 optional secret** (`DRATA_API_BASE`) in ConfigView when setup is complete. > **Scope of this integration today.** ConfigView reads Drata's personnel list and where each person's compliance checks stand, who can sign in to Drata and with which role, groups, monitored devices and their security settings, the asset inventory, the vendor inventory with risk and review status, the AWS, Azure, GCP and GitLab connections, monitoring tests, the cloud and source-control accounts Drata has linked to people, and Drata's event log. It never reads policy text, evidence files, audit requests, risks, controls' evidence, vendor questionnaires or documents. ConfigView only reads. It never creates, changes or deletes anything in Drata. *** ## What you need * A Drata **admin** account, to create the API key * A Drata admin must have accepted Drata's **API terms and conditions** once. Until then Drata answers every request with "412", and ConfigView's health check says so * Some areas are only filled in if your Drata plan and the key's permissions include them: vendor management, the connections lists and the event log. If an area is not available, that collector skips itself and its table stays empty. That does not count as a failure *** ## Step 1: Open the Drata page in ConfigView Open ConfigView in a second browser tab and leave it open: `https://{companyname}.configview.com/admin/integrations/drata` Drata shows the API key only once, when you create it, so paste it straight into ConfigView instead of keeping it in a notes file. *** ## Step 2: Create a read-only API key 1. Sign in to Drata as an admin 2. Open **Settings → API Keys** 3. Click **Create API Key** and name it `ConfigView` 4. Choose the scope **All read**. A custom scope can leave out personnel, and ConfigView needs it 5. Choose an expiry. Drata's default is 12 months 6. Create the key and copy it 7. Switch to the ConfigView tab, paste it into `DRATA_API_KEY` under **Credentials**, then click the save icon ### Keys expire A Drata API key stops working on its expiry date and **cannot be reactivated**. Put a reminder in your calendar a few weeks before, create a new key the same way, and paste it over the old one. When a key has expired, every ConfigView collector for Drata fails with "401" and the health check tells you the key was rejected or has expired. ### EU and APAC accounts Drata runs separate regions. If your Drata is in the US, leave `DRATA_API_BASE` empty. EU accounts paste `https://public-api.eu.drata.com`. APAC accounts paste the APAC host listed in Drata's API documentation. A key sent to the wrong region is answered with 401. *** ## Step 3: Connect and verify 1. Back on `https://{companyname}.configview.com/admin/integrations/drata`, confirm the credentials show as saved 2. Click **Connect**. ConfigView creates its tables and schedules every collector at your default run time. Stop any you don't want under **Collectors**: | Script | Notes | | - | - | | **Personnel** | Everyone Drata tracks as personnel: employment status, start and separation dates, and which compliance checks are failing. | | **Drata Users** | People who can sign in to Drata itself, their roles, and the linked accounts that lack MFA. | | **Roles** | The roles a Drata login can hold, with their permissions. | | **Groups** | Personnel groups, created by hand or synced from your identity provider. | | **Devices** | Monitored computers: owner, serial number, model, OS version, last check-in, and whether encryption, antivirus, firewall, auto-update and password manager pass. Runs after Personnel, to find each owner. | | **Assets** | The asset inventory: hardware, cloud resources, software, code and containers. | | **Vendors** | The vendor inventory: category, status, risk, MFA, PII, renewal, cost, owner and the latest security review. | | **Connections** | The AWS, Azure, GCP and GitLab connections Drata reads from. | | **Monitoring Tests** | Drata's automated tests per workspace: result, since when failing, and the controls each covers. | | **Infrastructure Identities** | Accounts Drata found in cloud and infrastructure systems, with MFA, admin and database access. | | **Source Control Identities** | Accounts Drata found in GitHub, GitLab and similar, with MFA, write and push-to-production access. | | **Event Log** | Drata's event log. ConfigView keeps every event it collects. | 3. Click **Verify now**. The health check reads the key, then makes one small request to every area. A 401 means the key is wrong or expired, a 412 means the API terms have not been accepted, and an area that shows as skipped is not available to your key or plan. If a check fails: * **401.** The key is wrong, was revoked, has expired, or belongs to another region. Create a new key, or set `DRATA_API_BASE` * **412.** A Drata admin needs to accept the API terms in the Drata app * **403 on Personnel.** The key was created with a custom scope. Create a new one with **All read** * **An area shows as skipped.** Drata answered "forbidden" or "not found". Usually the key's permissions or your plan. Nothing to fix unless you want that data * **429.** Drata's rate limit was hit. Wait a minute and verify again *** ## Data Tables Once the scripts run, these tables are created in your database. Each table has a `run_at` column and a `raw_json` column, which holds the record as Drata returned it, minus anything listed under *What isn't collected*. The snapshot tables keep only the newest run. `drata_events` keeps every event ever collected. | Table | Source | Key Columns | | - | - | - | | `drata_personnel` | `GET /public/v2/personnel` | personnel\_id, user\_id, email, display\_name, employment\_status, started\_at, separated\_at, check\_count, failing\_check\_count, failing\_checks | | `drata_users` | `GET /public/v2/users` | user\_id, email, display\_name, job\_title, roles, terms\_agreed\_at, identity\_count, identities\_without\_mfa | | `drata_roles` | `GET /public/v2/roles` | role\_id, role\_name, permission\_count, permissions | | `drata_groups` | `GET /public/v2/groups` | group\_id, name, group\_source, connection\_id | | `drata_devices` | `GET /public/v2/devices` | device\_id, personnel\_id, owner\_email, serial\_number, model, os\_version, source\_type, last\_checked\_at, is\_compliant, encryption\_enabled, antivirus\_enabled, firewall\_enabled, auto\_update\_enabled, password\_manager\_enabled | | `drata_assets` | `GET /public/v2/assets` | asset\_id, name, asset\_type, asset\_class\_types, is\_hardware, asset\_provider, owner\_email, serial\_number, removed\_at | | `drata_vendors` | `GET /public/v2/vendors` | vendor\_id, name, category, vendor\_status, risk, impact\_level, password\_policy, password\_mfa\_enabled, has\_pii, renewal\_date, owner\_email, integrations, latest\_review\_status | | `drata_connections` | `GET /public/v2/{aws,azure,gcp,gitlab}-connections` | provider, connection\_id, client\_alias, connection\_state, account\_ref, token\_expires\_at | | `drata_tests` | `GET /public/v2/workspaces/{id}/monitoring-tests` | workspace\_id, test\_id, name, check\_result\_status, check\_status, failed\_since, control\_codes | | `drata_infrastructure_identities` | `GET /public/v2/workspaces/{id}/infrastructure-user-identities` | workspace\_id, username, email, linked\_user\_email, client\_type, is\_service\_account, has\_mfa, admin\_access, db\_access | | `drata_version_control_identities` | `GET /public/v2/workspaces/{id}/version-control-user-identities` | workspace\_id, username, email, linked\_user\_email, client\_type, is\_service\_account, has\_mfa, write\_access, push\_production\_code\_access | | `drata_events` | `GET /public/v2/events` | event\_id, event\_at, event\_type, category, source, description, user\_email | *** ## Things worth knowing **Statuses are Drata's.** "Failed", "compliant" and the employment statuses are Drata's own verdicts. ConfigView stores them as they are, so its answers match the Drata dashboard. **Count devices from `drata_devices`, not from assets.** Drata's asset list also holds a row for every person and every policy document, and marks all of them as `PHYSICAL`. Filtering on that flag overstates a fleet roughly three times. `drata_assets.asset_class_types` is the real split, and `is_hardware` is 1 only for hardware. **Device owners come from personnel.** Drata returns a device's owner as an id. ConfigView looks it up in the newest `drata_personnel` run, which is why Devices runs after Personnel. **Per-workspace tables.** Monitoring tests and the two identity tables are read once for each Drata workspace and carry `workspace_id`. Most companies have one workspace. **The event log has descriptions, not request bodies.** The first run collects the last 90 days. After that, each run picks up from the newest event already stored. **Rate limit.** Drata's public API is reported to allow 500 requests a minute per source IP. Each ConfigView collector paces itself at 40 a minute and reads 500 records a page, so a full run needs only a handful of requests. ## What isn't collected * Vendor-side contact names and emails, vendor notes, vendor documents, SOC review detail and questionnaires * User background-check results and documents, avatars, and asset or device notes and documents * The AWS external id on cloud connections * Request and response bodies in event metadata * The API key never goes into the database This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.