Skip to main content

​
2026-10-14: Document uploads and risk scores on the Intake API

​
New features

  • Attach files to an intake created by API. Upload each file with POST /v1/intake/api/documents, then name the returned IDs in document_ids when you create the intake session. Coverbase reads the files when it answers the questionnaire, the same way it reads files uploaded on the intake portal, and moves them onto the vendor record when the intake is submitted.

​
Updates

  • Documents on intake sessions. GET /v1/intake/api/sessions/{session_id} and its external_id variant now return documents, with each file’s vendor_document_id once the intake is submitted.
  • Inherent risk score on intake sessions. GET /v1/intake/api/sessions/{session_id} and its external_id variant now return raw_irq_score and inherent_risk_level once the session is complete. The score is calculated the same way approval scores the vendor, and the level comes from your organization’s default risk scale.

​
2026-10-14: Assessment Settings in sections

​
Updates

  • Assessment Settings is organized into sections. A section list down the left of Configuration > Assessment Settings opens one part of the page at a time: Plans, Workflow, Analysis, Reports, Document Collection, Reassessments (with Monitoring beneath it when monitoring records are on) and SLA Targets. Every setting is unchanged and keeps working as before. Word report templates and the report file name are under Reports; reviewer, creation and approval settings are under Workflow.

​
2026-10-14: Confirm inherent risk before a reassessment

​
New features

  • Inherent risk check before a reassessment. An assessment plan can send your IRQ to the vendor’s relationship owners before each reassessment starts, prefilled with last cycle’s approved answers. Nothing goes to the vendor until the check is confirmed or skipped, and the plan then picks questionnaires and control sets from the refreshed inherent risk. Unchanged answers start the assessment on their own. See Confirm inherent risk before a reassessment.

​
Updates

  • Assessment plans API. Assessment plans accept and return irq_review_questionnaire_id and irq_review_due_days, and POST /v1/assessment/from_plan accepts confirm_inherent_risk_first.

​
2026-10-08: Vendor ID on intake sessions

​
Updates

​
2026-10-08: The third-party lifecycle

Your Coverbase representative turns on the third-party lifecycle features for your organization.

​
New features

  • Intake Agent. Zero-form intake: requesters ask for a new vendor in Slack, Microsoft Teams, email or their AI assistant, and the agent asks only for what is missing before opening the intake. See Intake Agent.
  • Front Door. Triage each intake request before due diligence: identifier matching on tax ID, D-U-N-S and LEI, engagement reuse by risk domain inside a reuse window, a disposition signed off by the TPRM Office and Supply Chain, IRQ scoping rules that send the questionnaire once, a Do Not Use list that needs an override rationale to approve, Approve triage from the request header, and Decline, which sends the disposition back to the TPRM Office with your reason. See Front Door.
  • Risk methodology. One page for domain weights, three aggregation methods including a domain floor, a reviewer matrix by requesting group, business unit, tier and domain, SLA escalation rules, versioned inherent risk questionnaires with a changelog, review cadence and side-by-side version compare, an escalation log, inherent and residual what-if scoring, and score overrides that need a rationale and can expire, with a countdown. See Risk methodology.
  • Due diligence. Assessment methods with remote and onsite review sessions, question delegation in the supplier portal, answers carried forward from the last submission, reviewer edits the supplier approves, service-level questionnaires for vendors whose due diligence is current, and findings raised on a question. See Due diligence.
  • Claim check. Each questionnaire answer tested against the vendor’s SOC reports, certifications, trust center documents, outside-in scan, licensed ratings and contract terms, with cited passages, then findings raised or the vendor asked in bulk. See Claim check.
  • Issue acceptance chain. Route accepting a finding’s risk through the owner, a recommending Risk Group, the deciding TPRM Office and an extended approver, enforced on every way a finding can reach risk accepted, with decisions in bulk. See The issue acceptance chain.
  • Engagement record and Risk Summary. A shared tracker from request to exit, including an Exit stage after Active, with an expected decision date, Risk Group status, linked and reused diligence, and a Risk Summary with a recommendation, conditions, a PDF, the Transaction Owner’s decision and opt-in email open tracking. See Engagement record.
  • Clause packs and non-standard contracts. The clauses an engagement’s risk results and open issues require, whether the draft carries each, obligations monitored after signature, and a portfolio report of non-standard clauses. See Clause packs.
  • Monitoring plans and scorecards. A plan per engagement from a tier by activity cadence matrix, signal re-timing with undo under an agent policy, an IRQ refresh with an answer diff, a comparison of any submission with the earlier one, owner attestation, performance scorecards, contract obligations, and the Monitoring workbench for rescheduling and sending scorecards in bulk. See Monitoring plans.
  • Offboarding and continuity. The executed contract handoff, continuity plans for critical engagements, and offboarding with an exit plan that closes only on approved evidence, including a vendor-signed data destruction certificate, with evidence and approvals in bulk. See Offboarding and continuity.
  • Integration Hub. Coupa, SAP Ariba, Ironclad, Icertis, Archer, ServiceNow IRM, an ERM risk register and Microsoft Teams, with field mappings, a sync log, a steward queue with bulk linking, signed inbound webhooks, and approvals from Teams cards through your own bot. A sign-off made in Coverbase updates the Teams card too. See Integration Hub.
  • Certificate Vault and prequalification. Every certificate in one place, renewals requested in bulk, ISNetworld, Avetta and EcoVadis networks, prequalification rule sets that can block purchase orders, and Bitsight, SecurityScorecard, RapidRatings and Moody’s ratings in Radar. See Certificate Vault.
  • Warehouse data share. Push 18 program tables to Snowflake, Amazon S3 or BigQuery hourly or daily, with a guided S3 trust policy step and plain-language errors. See Warehouse data share.
  • Program Insights. Program Overview under Dashboards: five KPIs, residual risk by business unit and risk domain, the pre-contract pipeline, three levels, six slicers with geography regions such as EU and North America, an ordering for business units, drill-downs that filter the matching lists exactly, Excel and CSV export, the board pack and the Distribution card. See Program Insights.
  • Integration platforms. Starting points for Workato (a custom connector), MuleSoft (a Mule 4 template) and Boomi (a process recipe) on the public API. See Integration platforms.
  • Agent Ledger and AI governance. A record of every agent action and the human decision on it, decided one at a time or in bulk, agent policies enforced where agents act, a filtered audit export, redaction of personal data before model calls, and learning from your own reviewers. See Agent Ledger.
  • Public API. OAuth 2.0 client credentials (POST /v1/oauth/token), contract records and engagement records. See the OAuth API.

​
Documentation

  • Fourteen product pages in a new Third-party lifecycle group, fifteen user guides, twenty integration guides, three API reference pages, and a new Integration credentials and signing security page. AI governance gains redaction, the Agent Ledger and learning.
  • The integration directory now links every name with a connector or a documented feature behind it, and says plainly that an unlinked name has no built-in connector.

​
2026-10-07: A calmer Financial health page

The Financial tab now answers first and puts the evidence one click away. Nothing was removed from the page.

​
Changes

  • Your rating leads. When your organization has a credit policy, the page opens with the vendor’s financial stability rating. The Financial Health Score, the peer benchmark and the runway sit in one row under it.
  • The score’s own scale. The scale under the score uses the score’s risk bands, from Very high to Very low, so the band named beside the number matches where the marker sits.
  • Evidence in rows. Everything behind the verdict sits in collapsed rows, each with a one-line summary. On this page opens the row you pick.
  • One Export menu. The PDF report, the Excel workbook and the analytics workbook are under Export.

​
Documentation

​
2026-10-01: Security ratings compared with industry peers

The Security tab now compares a vendor with the companies that sell what it sells, not only with your own portfolio.

​
New features

  • Industry Comparison. Coverbase chooses three to seven peers for the product your organization buys from the vendor, scans each one with the same outside-in scan, and shows the vendor’s factor scores against the industry average as a radar chart, then every company’s rating with its band. See Compared with industry peers.
  • Industry peers beside the rating. The top right of the rating card gives the industry average, the vendor’s rank, and every rated company on a strip of the rating scale.
  • Shared peer research. Peers and their ratings are stored once and shared by every organization that buys the same product from the same company. Peers are chosen again every 90 days, a peer’s rating is refreshed once it is more than 30 days old, and Choose peers again re-chooses them sooner.
  • In the PDF export. The Security PDF carries the radar chart with its figures and a tile for every company.

​
Documentation

  • The security intelligence guide gains a section on reading the comparison, how peers are chosen and how they stay current, with three troubleshooting rows. The product page explains where peers come from.

​
2026-09-27: One base URL

Every example, and the base URL table in API conventions, now uses https://api.coverbase.app, the only host that serves the public API. The second host these pages listed never served it and has been removed.

​
2026-09-24: Security Intelligence tells you what to do next

The Security tab now opens with what to do and what changed, ranks a vendor among your other rated vendors, and carries both into reports and MCP.

​
New features

  • Next steps. Every security profile carries a ranked list of actions, most urgent first, each resting on a named observation: an actively exploited CVE, a database or remote-desktop port open to the internet, a failing certificate, DMARC that does not enforce, a mail-capable lookalike domain, staff credentials in a breach within the last year. Ask the vendor copies a question that quotes the observed value, and Go to jumps to the evidence. The rules run when the profile is read, so every vendor scanned before today has a list now. See the security intelligence guide.
  • Since last scan. Each refresh records what it found that the previous one did not: the score and factor movement, findings that appeared or were resolved, vulnerabilities that appeared or are no longer observed, assets that arrived or left. Each count opens to the names behind it, and the factor rows carry the same movement as a badge. A finding counts as resolved only when its factor was measured in both scans. See since last scan.
  • Standing among your vendors. With at least five rated vendors, the rating shows where this one sits among them, such as Top 30%, computed from the ratings as they stand when you open the page. See standing among your vendors.
  • Jump links and a security timeline. A row under the rating links to each section this scan produced, and the drawer at the bottom of the page lists every dated fact on the profile as one chronology: ratings, when each finding was first seen, breaches, assets arriving and leaving, and disclosed incidents.
  • In reports and exports. The PDF export opens with the next steps and the change log. Report templates gain {{intelligence::security next steps}} and {{intelligence::security change since last scan}}, and the security posture section an agent or MCP client reads now carries both blocks.

​
Documentation

  • The security intelligence guide gains sections on next steps, since last scan, standing among your vendors and the security timeline, with four troubleshooting rows. The product page explains how the rules are chosen and evaluated, and the template placeholders reference lists the two new placeholders.

​
2026-09-10: Ask your documents a question

Ask a question in chat and Coverbase reads the vendor’s documents to answer it, returning the passage the answer rests on.

​
New features

  • Document evidence pulls. Ask something like “does Acme’s SOC 2 cover encryption at rest?” through a connected assistant. Coverbase filters the vendor’s documents on metadata, lets a model pick the one or two most likely to hold the answer, reads them, and returns a direct answer with a verbatim quote, its page number, a confidence, and a cropped image of the page with the passage highlighted. See Asking your documents a question.
  • Links that open the document highlighted. Every answer carries a link that opens the document preview on the right page with the passage marked. The highlight travels as the quote itself rather than as page coordinates, so it still resolves after a re-render that would move a stored bounding box.
  • Repeat questions reuse what was already quoted. Passages earlier work cited from the same documents are offered to the selection step, so a question already answered can come back without opening anything. A passage whose underlying insight has since been re-extracted is never reused.
  • Scanned documents are readable. A pull reads the searchable rendition produced at ingestion, so an OCR’d scan answers and highlights like a native PDF. Excel workbooks are read as workbooks and cite a sheet name instead of a page.
  • pull_document_evidence prompt. A scripted version of the whole flow, in the prompt menu of any connected client. See Canned prompts.
  • Sharper document filters over MCP. Listing a vendor’s documents now narrows on free text, document type, status, service, and upload date range.

​
Documentation

​
2026-09-09: Reputational risk on a Zero Touch run

A Zero Touch run now reports what it found against the vendor’s name as its own section, in the app and in both exports.

​
New features

  • Reputational risk section. Adverse media on the vendor’s leadership, open watchlist matches where your organization screens, and the run’s own reputation controls now arrive as one section rather than three places to go looking. Findings are filed under five dimensions: media and customer sentiment, litigation exposure, regulatory and enforcement, executive conduct and stability, and sanctions and association. See the Zero Touch guide.
  • Not screened is never reported as clear. Each dimension reports its own standing, and a dimension nothing searched reads Not screened rather than Clear. The section names every unscreened dimension, so a short findings list is not mistaken for a clean vendor.
  • Material findings first. A matter the subject was cleared of, or one a reviewer has dispositioned, is still listed because it is part of the record of what the run read. It is not counted as material and it does not deduct from the score.
  • Second in both exports. The section prints straight after the vendor identity in the PDF, with the overall standing on the first page. The spreadsheet carries the read on the summary sheet under the score and a Reputational risk tab beside it, one row per finding with its publisher, date and link. The portfolio export gains reputational standing and material finding count columns.

​
API

  • GET /v1/zero_touch_assessment/{id} returns result.reputation, carrying the overall standing, the five dimensions and the findings behind them. It is null on a run scored before this shipped, which means the run never assembled one rather than that the vendor is clear. See the API reference.

​
Documentation

  • The Zero Touch guide gains a section on reading the reputational read, an updated export walkthrough, and a troubleshooting row on the difference between Not screened and Clear.

​
2026-09-05: Review a vendor’s attributed estate

Security Intelligence now shows every domain and address it attributes to a vendor as a list you can correct, and every finding carries the step that resolves it.

​
New features

  • Attributed estate. The Security tab lists every asset the scan attributes to the vendor, with when each was first and last seen. Filter to what still needs a decision, and Confirm or Dispute each one from its row. A disputed asset leaves the next scan and the rating; withdrawing the dispute puts it back. See the security intelligence guide.
  • Add the assets the scan cannot find. Discovery reads certificate transparency, so a host with no public certificate never appears. Add asset puts them in the estate, one per line or comma-separated, and the next scan probes and scores them like any other. One submission costs one rescan however many hosts it carries, and assets you add survive a scan that cannot see them.
  • Remediation on every finding. Opening a finding shows what was observed, whether it cost the rating points and how many, how long it has been open, and the step that fixes it. Forwarding one to a provider now hands them the change to make rather than the problem to research.
  • Generate findings in bulk. Generate findings raises a tracked finding for every scored issue at once, ticked by default and ordered by severity, for the sweep that turns up the same problem on a dozen hosts.
  • Transport checks per host. TLS is measured on each attributed host rather than only the vendor’s main domain, so one neglected server does not hide behind a well-configured front door.

​
Fixes

  • DNSSEC, TLS reporting and email authentication no longer read as failures for domains that have not adopted them. Non-adoption is now recorded as an observation rather than scored like a misconfiguration, and DNSSEC is read from the signed zone rather than from the resolver’s answer.

​
Documentation

  • The security intelligence guide gains sections on opening a finding, raising findings from a scan, and reviewing the attributed estate, with new screenshots and three troubleshooting rows.

​
2026-09-01: Radar signals

Radar now works as one signal per event instead of the old per-detector alerts feed, with titles and summaries written for your organization.

​
New features

  • Signals. Every event your organization is exposed to appears once on the new Signals tab, as a signal carrying a status (Tracked, Open, In alert, Triaged, Dismissed), the highest severity any detector assigned, and the vendors and detectors involved. Each detector’s verdict stays visible on the signal’s Detectors tab. See the Supplier Radar key concepts.
  • Tracked exposure. A signal appears as soon as a vendor you depend on is linked to an event, before any detector fires, so fourth-party exposure is visible before anything has fired.
  • Generated titles and summaries. Each signal’s title and summary are written for your portfolio and regenerated when the detectors that fired change. Edit them by hand, click Regenerate summary, or set Custom AI instructions that apply to every summary in your organization.
  • Configuration moved. Detectors and sources now live under Configuration → Radar, reached from the Configurations button on the Radar page.

​
Documentation

​
2026-08-27: Internal Controls Library for Inspect

The control set library is now two libraries. The existing frameworks stay where they were, under a renamed Vendor Controls Library, and a new Internal Controls Library holds control sets Inspect evaluates against your own applications.

​
New features

  • Internal Controls Library. A new library of 21 templates spanning 362 controls, written for Coverbase Inspect to evaluate against the applications you run rather than against a vendor. Covers identity and privileged access, application scope and feature drift, integrations and OAuth, data handling, PII, PHI/HIPAA, GDPR, AI features and AI agents, operational resilience, SLA conformance, audit logging, licensing, and the CRM, HRIS and financial-services application classes. See the Control Set library.
  • Vendor Controls Library. The existing 47 framework templates are unchanged and now open from the Vendor Controls tab. Together the two libraries hold 68 templates spanning 4,337 curated controls.
  • Controls written for a browser agent. Each internal control states an expectation carrying its own threshold, names the admin surface to read plus the alternate labels other vendors use for it, and defines what counts as incomplete. Incomplete is a real outcome rather than a failure, so an application that does not sell a capability is not marked down for lacking it.

​
2026-08-11: Web evidence credibility grading and evidence dates

Web evidence used in assessments is now graded for publisher accountability and filtered against a minimum you configure, and accepted citations record how old the evidence was when it was used.

​
New features

  • Source credibility grading and filtering. Every candidate web page retrieved while evaluating a control is graded Unreliable, Reputable, or Authoritative, and pages below the configured minimum are discarded before the evaluating model sees them. Grades are shown on evidence cards with the reason on hover, and exported in a Source credibility column on the Evidence sheet. See Evidence quality and source credibility.
  • Minimum credibility on evidence sources. Web-search evidence sources carry a minimum_credibility field (unreliable, reputable, or authoritative, defaulting to reputable), settable on a control set or on an individual control. Control-level evidence sources replace the set’s entirely, including this setting.
  • Evidence dates and age. Accepted web citations record the publication or last-modified date the page declares, and the evidence’s age at the moment it was cited. Evidence cards show Published / Last updated, Age when assessed, and an absolute Accessed date; the Excel export adds Evidence Date and Evidence Age When Assessed (Days) columns.

​
2026-07-20: AI control sets, expanded detector library, integration directory

New out-of-the-box AI-governance control sets, a larger Supplier Radar detector library with a dedicated AI segment, and a documented directory of external integrations.

​
New features

  • AI-governance control sets. The Control Set library adds five built-in frameworks (AIUC-1, ISO/IEC 42001:2023, the EU AI Act, the OWASP Top 10 for LLM Applications (2025), and MITRE ATLAS), bringing the library to 47 templates spanning 3,975 curated controls.
  • Detector library page. A new Detector library reference documents all 75 Supplier Radar detector templates across 7 segments, including a new AI & Model Risk segment (prompt injection, model safety incidents, training-data/IP disputes, AI regulatory enforcement, and more).
  • Integration directory. A new Integration directory lists the external systems Coverbase connects with by category, including a new AI Governance & Safety category, a Compliance Automation & Trust Management category, and additions such as Aravo across GRC, procurement, and cybersecurity.

​
2026-06-17: List vendors, discover questionnaires, filter supplier exports

New read endpoints for discovering IDs without leaving the API, plus a name filter on supplier exports.

​
New features

  • List vendors. GET /v1/vendors lists the org’s vendors (newest first), with a case-insensitive name substring filter, an exact external_id lookup, and limit/offset pagination, so you can enumerate vendors or map your own identifier to a Coverbase vendor ID. See the Vendors API reference.
  • List questionnaires. GET /v1/intake/api/questionnaires returns the org’s questionnaires (id, name, type), with an optional type filter. Use it to discover the questionnaire_ids that POST /v1/intake/api/sessions requires. See the Intake API reference.

​
Updates

  • Supplier export filter. GET /v1/export/{report_name} now accepts a supplier_name query parameter that filters vendor-based reports (for example, the all-suppliers report) by name.
  • Import API troubleshooting. Clarified the most common 404/422 causes in the Import API reference: the path is singular (/v1/import/...), the body must be wrapped under data, and a service-account key is required.

​
2026-06-08: Documents API

Upload vendor evidence documents over the REST API and through the MCP server, link them to vendors, services, and assessments, and download them.

​
New features

  • Documents API. POST /v1/documents uploads a file (multipart/form-data) and attaches it to a vendor, optionally linking it to services (service_ids) and assessments (assessment_ids) in the same call. List with filters (GET /v1/documents?vendor_id=&service_id=&assessment_id=), fetch metadata (GET /v1/documents/{document_id}), get a short-lived presigned download URL (GET /v1/documents/{document_id}/download), re-link or rename (PATCH /v1/documents/{document_id}), and archive (DELETE /v1/documents/{document_id}). Smart limits apply: 100 MiB per file, an allowed file-type list, and 1-200 page sizes. See the Documents API reference.
  • MCP document tools. The MCP server adds mutate(document, create|update|archive) (upload from a URL, re-link, archive) and query_vendors(document_download) (presigned download URL), alongside the existing query_vendors(documents|document_summary) reads.

​
Updates

  • Assessment supporting documents. supporting_document_ids on POST /v1/assessments now links documents uploaded via the Documents API.

​
2026-06-04: Vendor fact sheet API

Read and regenerate a vendor’s AI-generated fact sheet (company intelligence) over the REST API.

​
New features

  • Vendor fact sheet API. GET /v1/vendors/{vendor_id}/fact-sheet returns the vendor’s fact sheet (company profile, products, public perception, financials, people, compliance/legal, and security posture) along with a generation status. POST /v1/vendors/{vendor_id}/fact-sheet/refresh queues a (re)generation and returns 202 Accepted; poll the read endpoint until status is "completed". See the Vendors API reference.

​
2026-06-04: List and resolve users by email

The Users API can now look up a user by email and returns the existing user on a duplicate create, so external systems (for example, ServiceNow) can build an email → user ID mapping for relationship-owner / watcher / risk-analyst assignments.

​
New features

  • List users / look up by email. GET /v1/users lists the org’s users (paginated via limit/offset, optional include_archived), or resolves a single user with ?email= (case-insensitive exact match; returns the user even if archived). See the Users API reference.

​
Updates

  • POST /v1/users is now create-or-get. When a user with the supplied email already exists in the org, the endpoint returns 200 OK with that user (so you can resolve its cbuser_... ID) instead of 409 user_exists. A 409 is now only returned when the email belongs to a user in a different org (emails are globally unique).
  • Assigning people by email. The vendor & service relationship_owner_ids, watcher_ids, and risk_analyst_ids fields still take user IDs. The Users API is the supported path to resolve those IDs from emails.

​
2026-06-02: Bill of Materials

Upload, version, and search machine-readable bills of materials (SBOM, AIBOM, HBOM, SaaSBOM) for vendors and services, over the REST API and through the MCP server.

​
New features

  • Bill of Materials API. Upload a BOM as a document linked to a vendor or its services (POST /v1/bill_of_materials), and Coverbase parses CycloneDX and SPDX JSON in the background into a searchable list of components. Read the current applied BOM for a vendor or service (GET /v1/bill_of_materials/latest), page the full upload history (GET /v1/bill_of_materials), retrieve one BOM with its components, search components within a BOM or across all of a vendor’s BOMs, and archive a BOM. Only the latest non-archived BOM is “applied”; older ones stay viewable as history. See the Bill of Materials API reference.

​
Updates

  • MCP & AI assistants. The query_vendors tool gained two read-only kinds: bill_of_materials (the latest applied BOM and its components) and bill_of_materials_history (every uploaded BOM for a vendor, newest first). See the example prompts.
  • Conventions. The ID-prefix table now lists cbbom_ (bill of materials) and cbbomc_ (component). See IDs.
The feature is gated by the org-level bill-of-materials entitlement. While it is off, the /v1/bill_of_materials routes return 404. Ask your administrator to enable it.

​
2026-05-29: Radar & reassessments come to the API

Programmatic access to continuous monitoring: create radar events, triage alerts, and drive reassessments end-to-end, plus webhooks for all three.

​
New features

  • Radar API. Create radar events (POST /v1/radar/events), list and retrieve events, and list, retrieve, dismiss, and undismiss radar alerts. Dismissing with suppress_similar teaches the detector to suppress similar alerts going forward. See the Radar API reference.
  • Reassessments API. Create a reassessment from a radar event with its vendors, curate the vendor set (add vendors, opt vendors in/out), set the assessment plan, then confirm, dismiss, or run it. Running creates one assessment per included vendor from the linked plan, and never opens a case. See the Reassessments API reference.
  • Radar & reassessment webhooks. Subscribe to RadarEvent.*, RadarDetectorResult.* (radar alerts), and Reassessment.* events. *.Updated events carry per-field field_diffs; soft-archives surface as *.Deleted. See the event catalog.

​
Updates

  • MCP & AI assistants. The Coverbase MCP server can now read reassessments (query_radar kind reassessments) and create radar events, dismiss alerts, and create/update reassessments (mutate). The in-product Interrogate assistant can propose the same radar/reassessment actions on a vendor.

​
2026-05-22: This week at Coverbase

A big week for the public API: self-serve key management, deeper workflow visibility, automatic webhook delivery, and tighter network controls.

​
New features

  • Self-serve API key management. Admins can now list, create, rotate, and revoke their org’s ak_* keys without filing a support ticket. Rotation is atomic, so you’ll never have two valid keys live at the same time. See the API Keys reference.
  • Scoped admin API keys. Admins can mint long-lived ak_* keys carrying the keys:manage and/or audit:read scopes, so key management and audit-log reads can run headlessly, without a short-lived dashboard JWT. The admin-JWT path is unchanged and still works. Granting scopes stays an admin-only action (a scoped key cannot grant scopes to itself or any other key), and a key missing the required scope gets 403 insufficient_scope. See API key scopes.
  • List workflow runs. Page through workflow run history with filters for workflow name, status, and time range. No need to know a run ID up front. See List workflow runs.
  • Archive an assessment via API. DELETE /v1/assessments/{id} mirrors the in-product Archive action: it soft-deletes the assessment along with its evals and findings, closes the portal if open, and cancels any in-flight workflow runs. See Cancel (archive) an assessment.
  • Public API audit log. Every authenticated /v1/* call is now recorded and visible to admins under Settings → Audit log (Integrations group), or via GET /v1/system_audit_log. Request and response bodies are never persisted. See Public API audit log.
  • Org-level API IP allowlist. Restrict all public API traffic to a set of CIDRs. Requests from outside the allowlist are rejected with 403 ip_not_allowed. See API IP allowlist.
  • Workflow send_webhook action. Workflow automations can now deliver their triggering event to subscribed webhooks, with optional event-type override and an optional subset of recipient webhooks. See Workflow engine → Actions.

​
Updates

  • Per-stage workflow outcomes. GET /v1/workflows/runs/{id} now returns the outcome of every executed step: status (success, failed, skipped), an optional message, the artifacts consumed and produced, and a per-step timestamp. Existing fields are unchanged. completed_at also now populates on canceled runs.
  • Automatic webhook delivery is live. Subscribed webhooks now receive a fan-out delivery whenever a matching domain event occurs. Previously only the manual test endpoint dispatched a delivery. All webhooks for a single source event share an event_id so receivers can dedupe. See Webhooks.
  • Webhook delivery history. Inspect every delivery attempt (event fan-out, manual test, or workflow-triggered) via the new GET /v1/webhooks/{id}/deliveries endpoint, and review aggregate stats (last_delivery_status, delivery_success_rate, delivery_count) on the webhook itself. See Webhook delivery history.

​
Breaking changes

  • Webhook event types are now strictly validated. Creating or updating a webhook with an event type outside the event catalog now returns 422 invalid_event_types. Casing matters: use Vendor.Created, not vendor.created. Review your registered subscriptions before your next deploy.
  • Webhook URLs are SSRF-restricted. Webhook url must be a public HTTPS endpoint. Non-HTTPS URLs, URLs with credentials or non-standard ports, and URLs resolving to private, loopback, link-local, or metadata addresses are rejected with 400 invalid_url. The same check runs at delivery time (DNS-rebinding safe).

​
Fixes

  • API keys revoke is idempotent. Re-revoking an already-revoked key returns success without writing a duplicate audit row. Audit entries are only written on actual state transitions.

​
2026-05-21: Self-serve API keys, workflow run listing, assessment archive, audit log

Additive features answering common customer questions on day-2 operations of the public API.

​
Additive

  • Self-serve ak_* API key management. New API Keys API lets an org admin list, create, rotate, and revoke their organization’s public-API keys without contacting Coverbase support. Rotation is atomic: a new key is minted, then the old one is revoked; if the revoke fails the new key is rolled back so there’s never a window with two simultaneously-valid keys. At launch these endpoints were JWT-only (ak_* keys could not manage other keys); they now also accept an ak_* key carrying the keys:manage scope. See the scoped admin API keys entry above.
  • GET /v1/workflows/runs: list workflow runs. Page through workflow run history without already knowing the run ID. Filterable by workflow_name, status (repeatable), and a created-at time range. Returns a step_count per run for at-a-glance progress. See Workflows API → List workflow runs.
  • Per-stage workflow outcomes. GET /v1/workflows/runs/{id} now surfaces the action outcome of every executed step: status (success / failed / skipped), an optional message (carries the failure reason on failure), the consumed and produced artifacts (with role of trigger or result), and the step’s created_at. The previous response (component id, name, action_type, updated_at) is unchanged so this is additive. completed_at now also populates on canceled.
  • DELETE /v1/assessments/{id}: cancel / archive an assessment. Mirrors the in-product Archive action: soft-deletes the assessment plus its evals and findings, closes the portal if open, and best-effort cancels any in-flight workflow runs targeting the assessment. Idempotent at the row level. See Assessments API → Cancel (archive) an assessment.
  • Public-API audit log. Every authenticated /v1/* request now writes a CbActivity row (type=external_api_call, target_type=external_api_request) with the method, path, route template, status code, duration, query parameter names, ak_* key id+name, client IP, and a request correlation ID. Visible to admins in Settings → Audit log under the Integrations group, and via GET /v1/system_audit_log. Request and response bodies are never persisted. See API conventions → Public API audit log.

​
2026-05-16: Webhook event-type validation, SSRF restrictions, delivery history, and API IP allowlist

Reconciled against the claude/webhook-ui-workflow source branch. Two breaking changes and two additive features.

​
Breaking

  • Webhook events is now strictly validated. POST /v1/webhooks and PATCH /v1/webhooks/{id} reject any event type outside the supported event catalog with 422 invalid_event_types. Previously the field was a free-form list of strings. Integrations that registered non-canonical values (for example, lowercase vendor.created) must switch to the exact catalog casing (for example, Vendor.Created) or their create/update calls will now fail.
  • Webhook URLs are SSRF-restricted. A webhook url must be a public HTTPS endpoint. URLs that are non-HTTPS, carry credentials, use a non-standard port, or resolve to a private / loopback / link-local / metadata address (for example, 169.254.169.254) are rejected at create/update with 400 invalid_url. The same check is re-applied with DNS resolution at delivery time (DNS-rebinding safe); a delivery blocked this way is recorded with status error.

​
Additive

  • Automatic event delivery is live. Subscribed webhooks now receive a fan-out delivery whenever a matching domain event occurs (previously only the manual test endpoint dispatched a delivery). All webhooks for one source event share a single event_id so receivers can dedupe the fan-out.
  • Webhook delivery history. New GET /v1/webhooks/{id}/deliveries endpoint (paginated, newest first) and a new Webhook delivery history page. Every attempt (event fan-out, manual test, or workflow-triggered) is recorded. The webhook object now also returns last_delivery_status, delivery_success_rate, and delivery_count.
  • Org-level API IP allowlist. An org can restrict all /v1/* public API requests to a set of CIDRs via api_ip_allowlist on the org object (POST /v1/org/{id}). Requests from outside the allowlist get 403 ip_not_allowed; the control fails closed. See API conventions → API IP allowlist.
  • Workflow send_webhook action. Workflow automations can deliver their triggering event to subscribed webhooks, with an optional event-type override and an optional webhook_ids subset. See Workflow engine → Actions.

​
2026-05-16: Reconciled against the deployed source branch

Corrected the reference against the deployed branch. Changes vs. the prior pass:
  • Vendor primary_contact. Create, update, and read now document the primary_contact object (email required + validated, plus name/title/phone_number). On read it is derived from stored contact personnel / security contact email.
  • Vendor services. The vendor object now includes a services array (nested service objects).
  • Service updates. Added PATCH /v1/vendors/{vendor_id}/services/{service_id} (name / description / tag_ids → service_not_found 404, invalid_service 400). Service create now accepts tag_ids; the service object includes a tags string array.
  • User email is validated. POST /v1/users rejects a non-email email with 422; 409 user_exists is also returned on a create race / global uniqueness conflict.
  • Findings: exactly one target. POST /v1/findings now requires exactly one of vendor_id/assessment_id: supplying neither or both fails with 422 (“Exactly one of vendor_id or assessment_id must be provided.”).

​
2026-05-16: Remaining endpoints documented

Added reference coverage for endpoints that were previously undocumented:
  • Users API: POST /v1/users (provision, idempotent), GET /v1/users/{id}, PATCH /v1/users/{id} (role change / deprovision via is_archived). Documented org role values, 409 user_exists, and the invited/active/inactive membership states.
  • Vendor & service creation: POST /v1/vendors (idempotent) and POST /v1/vendors/{id}/services (not idempotent). Added the vendor tier field and external_id create input.
  • Findings API: GET/POST /v1/findings, GET/PATCH /v1/findings/{id}. Documented the vendor/assessment filter, limit/offset pagination, the cbtask_ ID prefix, and the “one of vendor_id/assessment_id required” rule.
  • Obligations API: GET/POST /v1/obligations, GET/PATCH /v1/obligations/{id}. Documented the satisfied/not_satisfied status enum, CUEC type, and pagination.
  • Workflows: the get-run response now documents steps[]; added 409 workflow_disabled and 502 workflow_dispatch_failed; clarified that running a workflow genuinely dispatches the engine (Workflow.RunRequested).
  • Added a pagination section to API conventions; expanded the ID-prefix table (cbtask_, cboblg_, cbsvc_, cbvdoc_) and the idempotency support matrix.

​
2026-05-16: Documentation reconciled with the API

The API reference was rebuilt to exactly match the implemented public API. Highlights:
  • Resource surface corrected. Fixed schemas for the vendors, assessments, workflows, and webhooks endpoints. (The Users, vendor/service creation, Findings, and Obligations endpoints were documented in the following entry once the deployed surface was confirmed.)
  • Vendor schema fixed. status is a label string (not an object); tags is a string array (not objects). Added status_id. Removed fields that the API does not return (raw_irq_score, next_assessment_date, last_assessment_outcome).
  • Assessment schema fixed. Removed the non-existent risk_type, doc_collection_mode, and products request fields. control_set_ids is required. Status values corrected to the real enum. Idempotency replays return the original 201 body (no 409 idempotency_conflict).
  • Workflow schema fixed. Run status values are started/completed/canceled/failed. The get-run response returns only run metadata: no checkpoints_reached or output. Removed the non-existent 429 rate_limited / 400 invalid_input errors and the non-existent POST /v1/workflows/runs alternative.
  • Webhook signing documented from source. Signature header is Coverbase-Signature (lowercase hex HMAC-SHA256 of the raw body, keyed by the registered secret). Deliveries also send X-Coverbase-Event-Id and X-Coverbase-Event-Type. Envelope is exactly {event_id, event_type, occurred_at, data}. Retries are bounded at 5 attempts with a 10s per-attempt timeout (no documented multi-hour backoff window).
  • Event catalog corrected to the emission-backed SupportedEventType values with exact casing (for example, Vendor.Created, not vendor.created). Removed invented events (evaluation.flagged, evidence.requested, etc.).
  • Added a shared API conventions page (auth, IDs, timestamps, idempotency, error envelope).

​
Open questions

  • Automatic event delivery. No code path fans domain events out to subscribed webhook endpoints. Resolved 2026-05-16: automatic fan-out is now implemented. See the latest changelog entry above and the Webhooks guide.
  • supporting_document_ids ID prefix. The assessment create field accepts document IDs; the precise prefix is intentionally left unspecified pending confirmation.