Skip to main content
For AI agents: a documentation index is available at https://docs.coverbase.com/llms.txt. This page is also available in markdown by appending .md to the URL.
Every Coverbase integration, including the shipped platform guides, composes the same four shapes. This page names them so your integration or platform team can map your systems onto them before the first architecture call.

​
1. Inbound push

Your system of record stays in charge and pushes into Coverbase: a procurement platform creates the vendor, a GRC platform starts the assessment, an intake form submits a questionnaire. Each push is a standard authenticated API call to an org-scoped endpoint. What makes inbound pushes production-safe:
  • External IDs are the contract. Every pushed record carries your system’s identifier. Coverbase stores it and keys all matching on it, so a replayed delivery updates the existing record instead of duplicating it.
  • Validation before writes. Required identifiers are checked before anything is persisted; a rejected payload leaves nothing behind. Rejections return 422 (malformed or missing fields) or 409 (the payload conflicts with existing records) with a message naming the offending field.
  • Replays are safe. Redelivering the same payload refreshes the record from the latest data and never dispatches duplicate work: no second assessment run, no duplicate intake session, no re-imported attachments.
Used by the ProcessUnity, Workday Strategic Sourcing, and Aravo integrations, and by the generic Import API.

​
2. Outbound sync

Coverbase pushes results back into the system your auditors and downstream teams already look at: assessment outcomes, scores, review decisions, findings, and documents land as native records in the external platform. What makes outbound syncs production-safe:
  • Native records, not exports. Results are written to the platform’s own object model (a ProcessUnity assessment record, a ServiceNow Vendor Risk assessment, a OneTrust risk), so downstream reporting works unchanged.
  • Idempotent upserts. Every outbound record is keyed on an external ID. Re-running a sync updates in place; it never duplicates.
  • Best-effort by design. An external platform outage never blocks your analysts: syncs are logged and retried, and a failed push never fails the assessment or the user’s action that triggered it.
  • Platform limits handled proactively. Field length caps, rate limits, and write-contention retries are handled inside the connector, not left to your team to discover.
Used by the ProcessUnity, ServiceNow, and OneTrust integrations.

​
3. Webhooks and workflows

For systems that want to react rather than hold a mirrored copy, Coverbase fires webhooks as objects change and the workflow engine orchestrates multi-step processes. External systems can also trigger workflows directly. This is the lightest-weight shape: no field mapping, no connector. An endpoint you control receives signed events and decides what to do.

​
4. File-based import

For platforms without a usable API, or for one-time migrations, Coverbase imports structured files (Excel, CSV) through per-format import specifications that parse your questionnaire or vendor export into Coverbase’s control and question model. The same external-ID matching applies, so a file import and a later API integration reconcile onto the same records. Used for bulk vendor loads, historical assessment migration, and questionnaire imports during onboarding. See the Import API.

​
Composing the shapes

Real deployments combine shapes. A typical GRC coexistence deployment uses inbound push (the GRC platform starts assessments), outbound sync (results land back on the GRC record), and webhooks (ticketing and chat notifications along the way). See end-to-end workflows for the full picture, and the platform guides for how each shipped integration composes them.