tgcmp_…). It is separate from every other TigerGate key, and you choose exactly what it can read: which products, which resources in each product, and which kinds of finding.
TigerGate has no native Vanta, Drata, Secureframe or Sprinto connector yet. Each of these platforms can import data from a tool without one; Compliance platforms shows how to feed each one from this API.
Create a key
Only organization owners and admins can create or change Compliance API keys.Open the Compliance API tab
Go to Settings → Organization → API Keys and select Compliance API, then click Create key.
Details
Name the key after where it will be used, for example
Vanta – production. Pick the Integration it is for (Vanta, Drata, Secureframe, Sprinto, Thoropass, LowerPlane or Custom / other) and when it Expires after: 90 days, 180 days, 1 year (the default) or 2 years. Every Compliance API key expires.Products
Select the products the key may read. Only products your organization’s plan includes are listed.
Resources
For each product, choose All resources, including future (recommended) or Selected resources. With All, resources you connect later are included automatically. With Selected, pick up to 5,000 specific resources, such as individual repositories or cloud accounts.
Finding types
For each product, keep All, including new or pick specific types, for example SCA and Secrets but not SAST.
whoami confirms that the key works and lists everything it can read:
What a key can read
A key’s scope has three levels: product, then resources within the product, then finding types.| Product | product value | Resources you can select | Finding types |
|---|---|---|---|
| Code Security | code_security | Repositories | sca, sast, secret, iac |
| Container Security | container_security | Registries, image repositories | vulnerability, misconfiguration, secret, malware |
| Cloud Security | cloud_security | Cloud accounts | misconfiguration |
| Kubernetes Security | kspm | Clusters | identity, workload-security, network, secrets, supply-chain, ai-security, admission, governance, reliability, hygiene, custom, uncategorized |
| Data Security | dspm | Data accounts, data stores | control, malware |
| Pentest | pentest | Targets | web, network |
| Endpoint | endpoint | Devices | vulnerability, malicious_package, ioc, execution_trigger, integrity, drift, credential_hygiene, supply_chain, posture, persistence |
| Infra Vulnerabilities | infra | Hosts | vulnerability |
| Runtime | runtime | Clusters | incident |
| Issues | issues | All only | toxic_combination, misconfiguration, exposed_vulnerability, threat_detection, code_to_runtime |
- Out-of-scope data is left out, not refused. A key scoped to three repositories sees findings from those three and nothing else. A list request never fails because other data exists.
- A product the key isn’t granted returns
403. So does a product your plan no longer includes;whoamireports which one applies. - A finding outside the scope returns
404when requested by id, the same as a finding that doesn’t exist. - Issues need full grants. An issue is a correlation across products, and its title can name a repository, image or account. An issue is returned only when the key has every product the issue draws on with All resources and All finding types. Grant Issues only to keys that already have that breadth.
- Plan changes apply automatically. When your plan drops a product or finding type, the key stops returning it, and
whoamilists it underexcluded_finding_types. - Deleted resources drop out. A selected repository or account that is later deleted matches nothing.
whoamicounts it asstale, and editing the key offers to remove it.
User details
Separately from products, a key can be granted User details: the organization’s members, for user access reviews. It is off by default because it returns names and email addresses. A key can have User details alone, with no products. Without it,GET /users returns 403 users_not_granted.
What the API returns
| Endpoint | Returns |
|---|---|
GET /whoami | The key, its organization and region, and per product: what it can read, and whether it is ready |
GET /findings | Findings for one product, with status, severity, CVEs, first and last detection, resolution, and SLA due date |
GET /findings/{id} | One finding |
GET /assets | The in-scope assets of one product |
GET /scan-activity | Each in-scope asset’s latest scan and latest successful scan |
GET /sla-policy | The remediation SLA, in days per severity |
GET /frameworks | Framework pass and fail rollups for Cloud Security, Kubernetes Security and Data Security |
GET /controls | Per-control status for those three products |
GET /users | Organization members with role, teams, MFA status and last login. Needs User details |
control finding type.
The API reference documents every parameter and field.
Finding status
Every product reports the same three statuses:status | Meaning |
|---|---|
open | Detected and not resolved. Includes findings being worked on (status_detail: in_progress). |
suppressed | Triaged as accepted risk, false positive, won’t fix or muted in TigerGate. status_detail says which. |
resolved | No longer detected (fixed, not_detected, passing, resource_removed) or marked resolved (marked_resolved). |
SLA dates
Each finding carries ansla object. due_at is the finding’s first detection time plus your organization’s SLA days for its severity. If someone set a due date on the finding itself in TigerGate, that date is used instead, and sla.source is workflow. Informational findings have no SLA. sla.breached is true for an open finding past its due date, and remediated_within_sla records whether a resolved finding was closed in time.
Without an organization SLA policy, TigerGate’s defaults apply:
| Severity | Days to remediate |
|---|---|
| Critical | 15 |
| High | 30 |
| Medium | 90 |
| Low | 180 |
GET /sla-policy returns the days in effect for your organization, and whether they are your own (source: org) or the defaults.
Frameworks
Framework names differ between products, so the API returns a normalizedid alongside each product’s own name (source_key):
id | Framework |
|---|---|
soc2 | SOC 2 |
iso27001 | ISO/IEC 27001 |
pci-dss | PCI DSS |
hipaa | HIPAA |
gdpr | GDPR |
nist-800-53 | NIST SP 800-53 |
nist-csf | NIST CSF |
fedramp | FedRAMP |
cis | CIS Benchmarks |
cis-kubernetes | CIS Kubernetes Benchmark |
nsa-cisa-kubernetes | NSA/CISA Kubernetes Hardening |
iso27701, ccpa and dpdp. A framework without a normalized id is returned as other, with its name in source_key.
Cloud Security, Kubernetes Security and Data Security findings list the frameworks and controls they map to in compliance.frameworks. Filter on them with framework and control, for example GET /findings?product=cloud_security&framework=soc2&control=CC6.1. Either the normalized id or the product’s own key works.
Data handling
The API returns evidence about findings, not the sensitive material behind them:- No secrets and no source code. Secret findings name the file and line but never the value. No finding includes a code snippet.
- No pentest payloads. Requests, responses, proof-of-concept scripts and exploitation evidence are never returned. URLs have query strings, fragments and credentials removed.
- Endpoint hostnames only with opt-in. Devices and hosts are named by hostname only if your organization has turned on hostname collection for Endpoint. Otherwise they appear as
Devicefollowed by the first eight characters of the device id. - No raw scanner output. Every field is copied into the response by name; nothing is passed through from a database row or a scanner report.
- No credentials for users.
GET /usersnever returns passwords, MFA secrets or reset tokens, only whether MFA is turned on.
Security and lifecycle
- Read-only. A Compliance API key cannot change anything in TigerGate, and it is rejected by every other TigerGate API.
- Stored as a hash. Only a SHA-256 hash and a short prefix are kept. The full key is shown once, at creation or rotation.
- Header only. Send the key as
Authorization: Bearer tgcmp_…orX-API-Key: tgcmp_…. A request that puts a key in the URL is refused with400. - Region-scoped. Like every TigerGate key, it works only against the region that created it.
whoamireturns the base URL to use. - Expiring. Requests fail with
401 expired_api_keyafter the expiry date. Create a replacement before then; the key list marks keys that expire within 14 days as Expiring soon.
| Action | Effect |
|---|---|
| Edit scope | Changes products, resources and finding types. Takes effect on the next request. A client that is mid-way through paging gets 409 cursor_stale and restarts. |
| Duplicate | Creates a new key with the same scope. |
| Rotate secret | Issues a new secret for the same key. The old secret stops working immediately. |
| Revoke | Disables the key permanently, effective on the next request. |
Connection status
The Compliance API tab shows whether each platform is actually pulling data. Cards at the top summarize every key that can still connect: the platform, its status, when it last collected data, and what to do if something is wrong. The key list shows the same status in its Connection column; expand a key’s row for per-product detail. The page refreshes every minute.| Status | Meaning |
|---|---|
| Connected | The platform made a successful request in the last 48 hours. |
| No recent sync | It worked before, but nothing has succeeded in the last 48 hours. Check the integration in the platform. |
| Failing | The platform’s most recent request failed. The reason is shown, for example a product the key isn’t scoped to, or rate limiting. |
| Not connected yet | The key hasn’t been used. Paste it into the platform and run its connection test. |
| Waiting for new secret | The secret was rotated, and the platform hasn’t used the new one yet. |
| Revoked, Expired | The key no longer works. |
GET /whoami alone keeps a key Connected but doesn’t count as collecting data.
For each product, the expanded row shows:
- when data was last collected;
- the last completed sync, meaning the last page of a findings pull, with whether it was a full sync or changes only, and how many findings it returned;
- whether the product’s latest request failed, and why.
Audit
These events are recorded in Settings → Organization → Audit Logs:| Event | When |
|---|---|
compliance_key.create, compliance_key.update, compliance_key.rotate, compliance_key.revoke | A key is created, edited, rotated or revoked. Edits record what changed. |
compliance_api.first_use | A key, or a newly rotated secret, is used for the first time, with the IP address and endpoint. |
compliance_api.access | A key is used. Recorded once per hour for each key and IP address, with the endpoint called. |
compliance_api.rejected, compliance_api.denied | A request with a known key is refused with 401 or 403. Recorded at most once every 15 minutes per key and reason. |
Not included
These are not available through the Compliance API:- Runtime threat events. Runtime incidents are included.
- Sensitive-data classifications as findings. They appear as attributes of Data Security
data_storeassets (sensitive_data_families,sensitivity_tier). - Code quality, SBOM, CBOM and AI-BOM data. These are inventories, not security findings.
- CIEM, attack surface, AI security posture and license findings.
- Writing data back, such as triage or comments.