> ## 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.
# Integration Hub
> Two-way sync with your procure-to-pay and contract lifecycle systems (Coupa, SAP Ariba, Ironclad, Icertis), findings and vendor risk pushed to GRC and ERM tools (Archer, ServiceNow IRM, a REST risk register), Microsoft Teams notifications and approvals, and the Intake Agent, with field mappings, a sync log and a steward queue for suppliers that do not match.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.
Your Coverbase representative turns on the third-party lifecycle features, including the Integration Hub, for your organization.
The Integration Hub connects Coverbase to the systems your purchases and contracts already move through. Requisitions in your procurement system open intake requests, supplier records link to your vendors, executed contracts in your contract lifecycle system mark the Coverbase contract executed, and Coverbase writes its risk tier, approval status and contract risk back to the provider. Every connection has **Field Mappings**, **Sync Log**, **Steward Queue** and **Authentication** tabs.
## Providers
| Provider | Category | Direction | What syncs |
| - | - | - | - |
| [Coupa](/integrations/guides/coupa) | Procure-to-pay | Two-way | Requisitions, suppliers, contracts and budget lines in; supplier risk tier and approval status, and contract risk rating, out |
| [SAP Ariba](/integrations/guides/sap-ariba) | Procure-to-pay | Inbound only | Supplier master data with qualification status, and sourcing events |
| [Ironclad](/integrations/guides/ironclad) | Contract lifecycle | Two-way | Records and their signed copies in; risk rating, required clause pack and blocking issues out |
| [Icertis](/integrations/guides/icertis) | Contract lifecycle | Two-way | Agreements and their executed copies in; risk rating, required clause pack and blocking issues out |
| [Archer](/integrations/guides/archer) | GRC and ERM | Two-way | Findings as issues and vendors as risks out; each record's status back |
| [ServiceNow IRM](/integrations/guides/servicenow-irm) | GRC and ERM | Two-way | Findings as GRC issues and vendors as risks out; each record's state back |
| [ERM risk register](/integrations/guides/erm-register) | GRC and ERM | Outbound | A risk per rated vendor, to a REST register you describe |
| [Microsoft Teams](/integrations/guides/microsoft-teams) | Messaging | Outbound, plus card actions | Notifications you choose, posted to a channel as Adaptive Cards; with your bot, approvals from the card and intake chats |
## How a sync works
Each connection syncs on its own interval (every 60 minutes unless you change it, and no more often than every 15 minutes), and on demand with **Sync now**. A provider that can call a webhook can also nudge a sync when a record changes. A webhook from a contract lifecycle system that names a contract syncs only that contract, including a contract whose record ID is `0`. Inbound passes run first, in a fixed order, so later passes can find suppliers through links the supplier pass made:
1. **Suppliers** link to a vendor and record its approved supplier list status.
2. **Requisitions and sourcing events** open a draft intake request carrying the value, category and requester, and pass the supplier's tax ID, D-U-N-S number and LEI to the Front Door.
3. **Contracts** create or update a Coverbase contract and, when executed in the provider, mark it executed through the same path DocuSign uses, so the executed notice and accounting packet fire the same way.
4. **Budget lines** (Coupa) record the amount and committed spend that Spend Controls and the intake budget step read.
Outbound runs last, and pushes a record only when its values changed since the last push. After the push, an Archer or ServiceNow IRM connection reads back the status of every issue and risk record it holds. Coverbase stores that status and does not change the finding's own status from it. Each record is written on its own, so one bad record fails alone, and the sync log says which record failed and why.
## Matching suppliers
A name alone never links a supplier. A tax ID, D-U-N-S number or LEI match links on one hit, and a domain links only when no stronger identifier points to a different vendor. Every match is among your organization's own vendors. Anything else goes to the **Steward Queue**, where someone links it to the right vendor or dismisses it. Once linked, a supplier is never re-matched. The queue filters by system, reason, age and name, and links or dismisses many records at once as a background job that reports, for example, "12 linked, 3 need a decision". A contract that arrives before its supplier is linked waits, and is filed against the vendor, with its executed copy, as soon as the steward links the supplier.
## Approvals in Teams
With a Coverbase bot registered in your Azure tenant, the Microsoft Teams connection posts three requests with **Approve** and **Decline** buttons: a Front Door disposition waiting on a sign-off group, a finding's acceptance chain waiting on a decision, and exit plan evidence waiting on its approver. People decide in Teams as themselves, with their own Coverbase permissions. A Front Door card is posted once for both sign-off groups and is replaced with the outcome whether the sign-off or decline happens on the card or in Coverbase. See [Microsoft Teams](/integrations/guides/microsoft-teams).
## The required clause pack
The clause pack written to a contract lifecycle system lists the high and critical severity clauses of your active clause sets, up to 25, by clause ID and name. It is the same list for every contract. Blocking issues are the titles of the vendor's open findings, up to 20.
This list is the same for every contract written to a contract lifecycle system. The clauses a particular engagement requires, from its own risk results and open issues, are its [clause pack](/products/clause-pack), shown on the engagement's **Contract** tab.
## Credentials and webhooks
Credentials go to a secrets manager when you save them and are never returned. The page only says which fields are set. A connection's webhook signing secret is shown once, when you create or rotate it. Inbound webhooks must be signed (see [Integration credentials and signing](/security/integration-credentials#inbound-integration-webhooks)), and a webhook body is never trusted as data: it only starts a sync that re-reads the record from the provider.
## Where to go next
Connect a provider, review its field mappings, read the sync log and work the steward queue.
Where a synced requisition shows up for the TPRM Office.
Everything Coverbase connects to, and which systems have a connector.
How credentials, signing secrets and webhooks are protected.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.