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

​
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