Exporting Compliance Data
The compliance endpoints of the REST API give read access to your CRA compliance data. They need an API key with the read scope. next-task and next-deadline work on the Reporting plan or higher. The other endpoints need the Enterprise plan. See API Overview.
| Endpoint | Returns |
|---|---|
GET /api/v1/compliance/status | The verification status of your company account. See Account status |
GET /api/v1/compliance/gaps | The open compliance gaps |
GET /api/v1/compliance/next-task | The next recommended task |
GET /api/v1/compliance/next-deadline | The next regulatory deadline |
GET /api/v1/compliance/mappings | The CRA requirement mappings |
GET /api/v1/compliance/assessments | Product assessments |
GET /api/v1/compliance/assessments/oscal | Assessment results in OSCAL format |
GET /api/v1/compliance/release-gate?productId={id} | Six release checks for one product. See Release gate |
POST /api/v1/compliance/release-gate/runs | The same checks, with the verdict stored as a record. See Stored gate runs |
GET /api/v1/vulnerabilities/{id}/article14 | The Article 14 status of one report. See Article 14 Status API. |
GET /api/v1/vulnerabilities/export | Up to 100 reports as JSON |
All responses are JSON, except where the table says otherwise.
Account status
GET /api/v1/compliance/status reads two account flags, the CRA verification flag and the verified company identity. It covers no product. For a product, read readyForDocAssembly from GET /api/v1/compliance/gaps.
| Field | Value |
|---|---|
scope | Always company_account |
status | ACCOUNT_VERIFIED when both flags are set, else ACCOUNT_NOT_VERIFIED |
note | A sentence that states the scope |
checks | craVerified and identityVerified. iso29147Alignment and secureEncryption are platform properties and are always true |
recommendations | The steps that set the open flags |
Until 3 November 2026, status was COMPLIANT or NON_COMPLIANT. Update a client that compares against the old values. The MCP tool get_compliance_status returns the same values.
Is the technical file ready?
GET /api/v1/compliance/gaps returns readyForDocAssembly. It is true only when gaps is empty and the technical file of each product is complete as recorded. With no matching product it is false.
| Field | Value |
|---|---|
fileStatus | One entry per product, with productId, productName, status (incomplete or complete_as_recorded), statement, openGaps, byArea and every open gap in gaps. It is the status that the technical file prints at its top. |
fileStatusOpenGapsCount | The open gaps summed over fileStatus |
totalGapsCount | The number of items in gaps |
An incomplete file also adds one item to gaps with ref technical_file_status. So an empty gaps list always means a complete file.
Who can close a gap
Each item from GET /api/v1/compliance/gaps has a help field. It names the kind of service that can close the gap.
| Field | Value |
|---|---|
help.service | platform, pentest, sbom_analysis, security_design_review, risk_assessment, data_protection_review, notified_body, eucc_lab or compliance_consulting |
help.label | A short name for the service |
help.guideUrl | A public guide to hiring that kind of expert, or null |
help.alternatives | Other services that also give evidence for the same gap, with the same fields. A Class II product lists an EUCC lab next to a notified body. A gap on Annex I Part I (2)(b), (2)(e) or (2)(f) lists a penetration test next to the design review. |
help is null for a sign-off gap, because only the manufacturer can sign. It is also null for a company-level obligation gap, because the product gaps already carry that work, and for the technical_file_status item, because each gap in fileStatus names its own action. The hiring guides are at cvdportal.com/hire-cra-experts.
Release gate
GET /api/v1/compliance/release-gate?productId={id} tells a CI/CD pipeline whether a product release may ship. It needs the Compliance plan or higher and the read scope. It stores nothing. Add strict=true to get status 422 when the gate blocks. Without it the status is 200 and the pipeline reads status.
| Check | Passes when |
|---|---|
sbomScanned | The current SBOM has components and a complete OSV.dev scan. When only some components have an identifier that OSV.dev can check, detail says how many were not checked |
noOpenCriticalHighVulnerabilities | The scan has no open critical or high finding without a VEX statement |
noUnmitigatedComponentSupportGaps | The product has a support period, no component loses supplier support before it ends, and no component is recorded as end of life without a date. Components with no supplier date are counted in detail |
technicalFileApproval | Export approval is off, or the latest approval is current for the product content |
noOpenCriticalHighPipelineFindings | No pipeline finding from SARIF or FOSSA is open at critical or high severity, for the product or for the whole account |
noKnownExploitedVulnerabilities | No open finding without a VEX statement is on the list of known exploited vulnerabilities, at any severity. The check also fails when the list cannot be used, for example after a failed update, and detail gives the reason. Findings whose CVE ID no scan has recorded are counted in detail and do not block |
The last two checks are new on 12 November 2026, with policyVersion 2. A client that expects four checks must read checks by id.
| Field | Value |
|---|---|
status | PASS or BLOCK |
checks | One entry per check with id, label, passed, detail and enforced |
blockingReasons | The detail of each failed check that is enforced |
disabledChecks | The id of each check that the workspace switched off. Such a check is still evaluated and reported, and it does not block |
policyVersion | The version of the check set, now 2 |
contentHash | The hash of the product content that an approval signs |
signature | meaning, meaningLabel, verifiedMethod (totp, backup_code, password or null), decidedByEmail and decidedAt of the latest approval, or null |
curl -fsS -H "Authorization: Bearer $CVD_API_KEY" \
"https://cvdportal.com/api/v1/compliance/release-gate?productId=$PRODUCT_ID&strict=true"
A PASS means that these checks passed. It is not a statement that the product conforms to the CRA.
Stored gate runs
POST /api/v1/compliance/release-gate/runs runs the same checks and stores the verdict. Use it in a release pipeline, so that the workspace has a record of each release that asked for a verdict. It needs the Compliance plan or higher and the gate:write scope. An administrator creates the key under Settings, then API Keys.
| Body field | Value |
|---|---|
productId | Required. The product to check |
releaseVersion | Optional. The release label, at most 100 characters |
source | Optional. github-actions, gitlab-ci, jenkins, azure-devops or other |
mode | Optional. block (default) or warn. A warn run is stored and never answers 422 |
commitSha | Optional. 7 to 64 hexadecimal characters |
pipelineUrl | Optional. An https URL of the pipeline run. It is stored as text |
strict | Optional. true gives status 422 when the gate blocks in block mode |
The response has status 201 and the fields of the release gate, plus runId, createdAt, releaseVersion and mode. The stored run keeps policyVersion and disabledChecks, so the record shows which checks applied. The run is stored also when the status is 422.
The checks read the current SBOM of the product at the time of the run. Push the SBOM of the release first, then ask for the verdict. releaseVersion is the label that the pipeline gave. It does not select the archived SBOM of an older release.
Each stored run writes the audit event RELEASE_GATE_EVALUATED. The limit is 30 runs per minute for each key.
jq -n --arg productId "$CVD_PRODUCT_ID" --arg releaseVersion "$RELEASE_VERSION" \
--arg commitSha "$GITHUB_SHA" \
'{productId: $productId, releaseVersion: $releaseVersion, commitSha: $commitSha, source: "github-actions", strict: true}' |
curl -fsS -X POST https://cvdportal.com/api/v1/compliance/release-gate/runs \
-H "Authorization: Bearer $CVD_API_KEY" -H "Content-Type: application/json" -d @-
Limits
The API has no endpoint for SLA performance metrics or for the audit log alone. The full data export includes the audit log. See Data Export & Retention.