Integrations and webhooks

The Integration Hub manages Jira, inbound and outbound webhooks, MCP clients, and SIEM export. ServiceNow, Slack, and Microsoft Teams may appear as unavailable future integrations.

For AI assistants, see What MCP is and Administer MCP.

Jira

Configure the Jira host and service credentials, test the connection, and map RiskVault fields to Jira fields. Once configured, authorized users link individual risks from Files / Links / Tags > Jira.

Inbound webhooks

An inbound channel lets another system trigger a RiskVault workflow rule.

  1. Open Administration > Integrations > Inbound Webhook Channels.
  2. Create a channel with a name and environment.
  3. Set a rate limit and allowed sender IP addresses when appropriate.
  4. Keep request signatures required except for tightly controlled testing.
  5. Save and copy the channel address and signing secret immediately.
  6. Configure the sender to provide a unique event ID, optional event type, and a risk ID or RR number.
  7. Create an On External Event workflow rule with the required conditions and actions.
  8. Enable the channel and select Test on its row (see Test a channel or endpoint).
  9. Send a real event from the other system and confirm it in Webhook Monitor and the risk's history.

Image needed: Inbound webhook channel page showing URL, signature requirement, IP allowlist, rate limit, and secret-rotation action. Hide all real secrets.

If the channel permits risk creation, the payload must include at least title and description. A channel setting determines whether the new risk remains Draft or is submitted.

Inbound rules run as the person who created the channel. RiskVault rechecks that account and its risk access at execution time. If inbound automation stops working on a risk, check that the channel's creator still has an active account and can view the risk.

When an inbound rule updates a risk

If the rule copies values from the request onto the risk (field mappings), RiskVault treats them like any other edit:

  • a field that can't be edited at the risk's current step is left alone, so nothing changes on a closed risk;
  • formatting and markup are stripped from text;
  • a likelihood or impact score outside your risk matrix is ignored, and a valid score change updates the rating;
  • the risk's version history keeps a copy of how it looked before the update, one version per rule that changed something;
  • the audit log records each changed field with its old and new value, the rule, and the channel.

A connected system can't move an existing risk to another workflow step. See Rules that update fields for the fields a rule can set.

Outbound webhooks

  1. Open Administration > Integrations > Outbound Webhook Endpoints.
  2. Enter a name, HTTPS destination, and environment.
  3. Save and securely copy the generated secret.
  4. Configure signing and its header name.
  5. Create a workflow rule with Call Webhook and reference the endpoint key.
  6. Select Test on the endpoint's row to check the address, secret, and receiving system (see Test a channel or endpoint).
  7. Test the rule and monitor delivery.

Requests include an event ID and idempotency key so the receiver can ignore duplicates. Failed deliveries retry automatically and can be retried from Webhook Monitor.

Test a channel or endpoint

Each channel and endpoint row has a Test action.

Inbound channel test. The channel must be enabled first, because the test uses the same public address the other system uses, and that address accepts only enabled channels. Enabling is low-risk: nothing can reach the channel until you hand out its address. The test confirms that the token, signature, IP allowlist, and rate limit all accept a request. It appears in Webhook Monitor as completed but is never acted on: it doesn't touch or create a risk and doesn't run any rules. Each test counts toward the channel's rate limit.

Outbound endpoint test. This works even while the endpoint is disabled, so you can confirm the address, secret, and receiving system before any rule sends real events. RiskVault sends one signed sample request, marked with an X-RiskVault-Test: true header, directly to the address and shows you the response. The test doesn't run any rules, isn't retried, and doesn't appear as a delivery in Webhook Monitor.

Rotate a webhook secret

  1. Coordinate a change window with the connected system.
  2. Start rotation in RiskVault.
  3. Copy the new secret through an approved channel.
  4. Update the other system during the overlap window.
  5. Test with the new value before the old value expires.

SIEM export

RiskVault can send its audit log by S3 batch, JSON webhook, or RFC 5424 syslog.

  1. Open Administration > Integrations > SIEM Export.
  2. Choose exactly one delivery method.
  3. Enter and test the destination settings.
  4. Review whether to include free-text fields such as entity name, action details, and error message.
  5. Add redaction rules where necessary.
  6. Save and verify the last-run status and record counts.

Use TCP or TCP with TLS when verifiable syslog delivery matters. UDP cannot confirm receipt.

Shape an inbound event

A useful inbound request includes:

  • a unique event ID so a retry is not processed twice;
  • an optional event type used by workflow-rule conditions;
  • the target risk's internal ID or RR number;
  • the business values required by the rule;
  • a valid signature when the channel requires one.

If the channel allows risk creation, include at least a title and description. Keep payloads within the configured size and rate limits.

Verify signatures and sender identity

The channel URL contains a token and should be treated as sensitive. For stronger protection, keep signatures enabled and configure an IP allowlist when the sender has stable addresses. Rotate secrets on a schedule and immediately after suspected exposure.

The receiving system for an outbound webhook should independently calculate and compare the signature using the shared secret. It should also store processed idempotency keys long enough to reject repeated delivery safely.

Use Webhook Monitor

  1. Open Administration > Integrations > Webhook Monitor.
  2. Filter by inbound or outbound direction, status, environment, endpoint or channel, and time.
  3. Open an event to inspect safe request metadata and the error.
  4. Correct the channel, endpoint, rule, signature, network, or receiving system.
  5. Retry a failed outbound delivery or replay an eligible inbound event only after confirming duplicate handling.
  6. Confirm the new result and the target risk's history.

Image needed: Webhook Monitor showing direction, status, environment and time filters, plus Retry and Replay actions on fictional failed events.

Common webhook problems

Nothing appears in the monitor
Confirm the correct environment, URL, channel or endpoint status, and whether the workflow rule actually matched.
Inbound signature fails
Confirm both systems use the same current secret, signature header, payload bytes, and algorithm. Check whether rotation overlap ended.
Inbound event is accepted but no risk changes
Review the On External Event rule and its conditions, then confirm the channel creator is active and can view the target risk.
Outbound delivery retries repeatedly
Inspect receiver status, TLS, timeout, rate limits, and signature validation. Make the receiver idempotent before manual retries.
A delivery is silently skipped
A workflow rule can reference a missing, disabled, or wrong-environment endpoint key. Correct the rule or endpoint.