Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.coverbase.com/llms.txt

Use this file to discover all available pages before exploring further.

This page describes how Coverbase integrates with the systems your organization already runs and how those integrations behave end to end. It’s intended for security, integration, and procurement teams evaluating Coverbase as part of a broader third-party risk and vendor lifecycle stack. The integration model is built around three layers: inbound API calls that bring data and commands into Coverbase, a workflow engine that orchestrates the work, and outbound webhooks that notify your downstream systems as work progresses.

​
Architecture

Inbound

External systems push data and commands into Coverbase. Procurement platforms create vendors, intake forms submit questionnaires, CMDBs sync service catalogs, and GRC tools start assessments. Each is a standard authenticated API call.

Orchestration

Once data lands, the workflow engine takes over. Triggers fire on object events, schedules, or external invocation. Conditions branch the flow. Actions execute the work: send a questionnaire, request evidence, run Copilot, wait for human review.

Outbound

As workflows progress, Coverbase fires webhooks to endpoints you control. Webhooks carry the event type and the affected object, so ServiceNow, Jira, Slack, Ariba, Icertis, or your data warehouse can react in real time.
External Systems          Coverbase              External Systems
─────────────────         ─────────────          ─────────────────
Ariba             ──▶     Inbound API     ──▶    ServiceNow
Jira                      Workflow Engine        Jira
CMDB                      Object Store           Slack
GRC tooling                                      Icertis
                                                 Data warehouse
The orchestration layer is configured once during onboarding. After that, both the configuration and every running workflow instance are reachable through the API. You can interrupt, modify, or replace any step at any time, through either the dashboard or the API.

​
Primary objects

All workflow logic operates on a small set of primary objects. Each supports full CRUD via the API.
ObjectDescription
vendorA third party your organization engages with.
serviceA specific product or service a vendor provides. One vendor can have many services.
engagementA specific use of a service by a business unit, with its own risk profile.
assessmentAn analysis of a vendor or service against one or more control sets.
evaluationThe result of analysis against a single control inside an assessment.
documentEvidence files such as SOC 2, ISO 27001, pen tests, policies, and contracts.
contractA legal agreement with a vendor, including MSAs, DPAs, SOWs, and BAAs.
entityA counterparty or end party referenced in a contract or relationship.
controlAn atomic requirement used to evaluate a vendor.
control_setA versioned collection of controls representing an evaluation standard.
When a workflow trigger fires, the payload references these objects by Coverbase ID. When a webhook fires, it references the same IDs, so your downstream systems can correlate events back to records they care about.

​
Where to go next

Workflow engine

Triggers, conditions, and actions. How orchestration logic is composed.

Triggering workflows from external systems

Three patterns for starting work in Coverbase from outside the UI.

Webhooks

Register endpoints, subscribe to event types, verify signatures, handle retries.

End-to-end workflows

Full lifecycle walkthroughs for onboarding, monitoring, and offboarding.