Skip to main content

​
What This Does

Provider installations let LoopIQ receive trusted signals from external systems and turn them into release evidence, agent signals, and governed follow-up actions. Use provider installations to connect systems such as:
  • GitHub
  • CI systems
  • Cloud Deploy
  • ServiceNow
  • PagerDuty
  • SonarQube
  • Datadog
  • Checkmarx
  • Vanta
Each installation can track approval status, credential health, last event, last successful sync, evidence freshness, and validation status.

​
How Provider Events Flow into LoopIQ

When an external system sends an event to LoopIQ, LoopIQ validates the installation, verifies the event, records a durable trigger job, updates canonical evidence where applicable, and lets agent packs evaluate the new signal. Typical flow:
  1. A provider sends an event, such as a GitHub pull request update or SonarQube quality gate change.
  2. LoopIQ validates the tenant, provider installation, signature, and event metadata.
  3. LoopIQ creates a durable trigger job.
  4. The job refreshes provider-specific evidence or records the source event.
  5. LoopIQ updates release-scoped evidence and agent_signals where applicable.
  6. Relevant agent packs can run against the refreshed evidence.
  7. Users see updated readiness, risks, actions, scorecards, or dashboards.
This avoids treating raw provider payloads as final release truth. Provider events start the refresh and evaluation process; LoopIQ still normalizes the evidence before using it in release governance.

​
Provider Installation Statuses

Provider installations may show statuses such as:
  • pending: The installation exists but is not fully validated or approved.
  • approved: The installation is approved for use in LoopIQ workflows.
  • validation_failed: LoopIQ could not validate the connection, signature, or required permissions.
  • revoked: The installation was disabled and should no longer send events.
  • rotation_required: Credentials should be rotated before continued use.

​
Register a Provider Installation

  1. Open Organization Settings.
  2. Go to Integrations or Provider Installations.
  3. Select the provider type.
  4. Enter the provider details requested by the form.
  5. Save the installation.
  6. Run validation if available.
  7. Review discovered metadata, permissions, or supported event types.
  8. Approve the installation when it matches your organization policy.
For external webhook providers, LoopIQ may generate a tenant-scoped event endpoint and signing secret or verification instructions. Store those values in the provider system, not in user-facing notes.

​
Rotate Credentials

Rotate credentials when:
  • an owner leaves the organization
  • a provider token expires
  • a secret may have been exposed
  • your security policy requires periodic rotation
  • the installation status shows rotation_required
To rotate:
  1. Open the provider installation.
  2. Select Rotate credentials.
  3. Copy the new signing secret or credential instructions.
  4. Update the provider system.
  5. Send or trigger a validation event.
  6. Confirm LoopIQ shows the new validation status and last successful event.
During rotation, keep the old credential active only as long as necessary to avoid event loss.

​
Revoke an Installation

Revoking an installation stops LoopIQ from accepting new events from that provider installation.
  1. Open the provider installation.
  2. Select Revoke.
  3. Confirm the provider and tenant.
  4. Remove or disable the matching webhook in the external provider.
Historical evidence and audit records remain available according to your retention policy.

​
Provider-Specific Notes

​
GitHub

Use GitHub events for pull requests, code review, repository activity, and security-related signals. GitHub events can trigger Code and Security packs and can also contribute to release readiness when linked to a release.

​
CI Systems

Use CI events for build, test, scan, and deployment pipeline outcomes. CI events are most useful when they include repository, branch, commit, environment, and release identifiers.

​
Cloud Deploy

Use Cloud Deploy events for deployment phase changes, rollout status, promotion activity, and release lifecycle signals. LoopIQ distinguishes legitimate phase events from duplicate delivery using event metadata and idempotency.

​
ServiceNow

Use ServiceNow events for incidents, changes, approvals, and operational workflow updates. These events can support Incident and Change packs, release approval context, and audit evidence.

​
PagerDuty

Use PagerDuty events for incident lifecycle changes, escalation activity, and responder context. These events can trigger Incident and Change packs or post-incident governance workflows.

​
SonarQube

Use SonarQube quality gate and analysis-completed events to refresh release-scoped code quality and security evidence. SonarQube events should lead to canonical evidence updates before release readiness is recalculated.

​
Datadog

Use Datadog events for monitors, incidents, SLOs, observability signals, and security findings. Datadog signals can contribute to release risk, operational readiness, and SLO governance.

​
Checkmarx

Use Checkmarx scan-completed and finding-change events to refresh application security evidence. Checkmarx evidence can support release blockers, remediation planning, and code security scorecards.

​
Vanta

Use Vanta control and test changes where supported. If Vanta does not provide the required event type, use scheduled incremental sync as the fallback. Vanta evidence can support compliance controls, certification readiness, and audit preparation.

​
Evidence Freshness

Evidence freshness tells users how recently LoopIQ confirmed the provider data. If evidence looks stale:
  • run provider validation
  • trigger a provider sync
  • check the last successful event
  • check whether the installation is approved
  • check whether the provider supports live events or requires scheduled sync

​
Troubleshooting

If events are not arriving:
  • confirm the provider webhook URL is correct
  • confirm the provider signing secret or verification method is configured
  • confirm the installation is approved
  • confirm the provider sends the event type LoopIQ expects
  • check the installation’s last event and validation status
If events arrive but release evidence does not change:
  • confirm the event includes release, repository, service, environment, or application identifiers
  • confirm the provider evidence mapping is configured
  • run a manual sync if available
  • check whether the evidence is scoped to a different release or team
If duplicate events appear:
  • check whether the provider retries webhooks
  • review event IDs and delivery IDs
  • confirm LoopIQ is applying idempotency for that provider
  • Approve only provider installations owned by your organization.
  • Keep provider credentials scoped to the minimum required access.
  • Use live events where providers support them.
  • Use scheduled incremental sync when live events are not available.
  • Review evidence freshness before relying on a certification decision.
  • Rotate credentials when ownership changes.
  • Revoke unused provider installations.