Enterprise webhooks let external systems POST into a governed receiver so the platform can refresh knowledge or run a named capability without polling alone. Inbound deliveries are authenticated; they do not bypass Operational Trust.
There are two outcomes after the same signed door:
- Change signal — the vendor says something changed; the platform loads current data from the system of record. That source remains authoritative.
- Named capability — the event name is a capability on that Business Entity; the platform runs that governed operation instead of treating the body as a refresh hint.
Why it matters
Batch sync keeps AI context fresh on a schedule. Webhooks reduce lag when vendors support inbound HTTP: a CRM stage change can refresh Enterprise Knowledge, and a messaging Request URL can run the same governed capability path Role Assistants already use.
Architects use webhooks to design event-aware Enterprise Knowledge and inbound capabilities — not to bypass Operational Trust.
How it works
External system event
↓
Signed webhook delivery (vendor → platform)
↓
Validation + trust boundary
↓
Refresh via the system of record — or — run the named capability
↓
Updated Business Entity context for Role Assistants
Webhooks complement — they do not replace — certification, dimensions, and capability boundaries. Governance still decides who may act. Do not mix vendor change names and capability names on one Business Entity.
After knowledge is updated, Role Assistants can also notice watched business fields and wake governed work — that story is When business reality changes, not the same as the inbound webhook itself.
Business scenarios
| Scenario | Business benefit |
|---|---|
| CRM stage change | Pipeline assistants use current deal state (refresh from the system of record) |
| Document published | Legal or proposal assistants see new version |
| Ticket resolved | Customer success risk views refresh |
| Messaging or bot Request URL | Inbound command or activity runs a named governed capability |
| Repository push (provider-specific) | DevOps golden paths trigger review workflows |
Relationship to sync
See Data sync and freshness for scheduled and bulk sync. Webhooks are the push lane when the Connected System vendor exposes them. Cross-system propagation after a change signal still reads the system of record and uses Enterprise Synchronization Fabrix — that is separate from capability-named inbound events.
Limits
Webhook coverage depends on the Connected System vendor and deployment generation. Not every integration supports inbound notifications on day one. Confirm supported events — and whether capability-named dispatch is live — with your platform operator before designing webhook-dependent journeys.
Build how-tos: Configure webhook change signals (manifest webhook + webhookInbound auth). Connected System slots: Configure authentication. For enterprise cross-datasource propagation after a signal, see Configure sync bridge and Enterprise Synchronization Fabrix. Scheduled ingest remains on Configure sync. Depth: Enterprise sync bridge — technical guide.