In ActLoom, Settings > Integrations/API is the operational page for external connectivity. It combines provider connections, machine credentials, outbound webhooks, and an activity feed so your team can automate compliance work without losing control over who can change what.
What this page does in the product
Connect external systems
The Integrations tab is where Jira, ServiceNow, Confluence, and SharePoint are connected and configured when available for the workspace.
Issue machine credentials
The API & Webhooks tab lets owners and admins create scoped API keys for backend jobs, pipelines, and controlled machine-to-machine access.
Push events outward
Webhooks let ActLoom notify your downstream tooling when incidents, assessments, reports, AI systems, or subscription state change.
Operational aspect
What to know in ActLoom
Prerequisites
A workspace must exist and an owner/admin must perform the setup. Some providers also require external OAuth or service credentials before ActLoom can connect.
Main inputs
Provider credentials, OAuth consent, API key names and scopes, webhook URLs, selected events, and optional expiry or routing settings.
Main outputs
Connected provider state, API credentials, webhook deliveries, synced tickets/pages, and settings activity history.
Who typically uses it
Owners, admins, platform engineers, compliance operations, and teams automating downstream workflows.
Plan access
Integrations, API keys, and webhooks are broadly available; enterprise SSO remains Pro-only and some rollout patterns are mainly relevant to larger teams.
Relevant surfaces
Settings endpoints under /api/settings/* and operational machine endpoints under /api/v1/* plus integration-specific routes for Jira, Confluence, SharePoint, and ServiceNow.
Settings
Integrations / API
Owner / Admin managed
Integrations
API & Webhooks
Provider connections
Jira
Configure
Connected
ServiceNow
Open panel
Set up
Confluence
Knowledge source
Connected
SharePoint
Conflicts with Confluence
Blocked
API key issuance
Name
Production reporting key
Expiry
365 days
read:reportswrite:reportsread:billing
Webhook endpoints
https://ops.example.com/actloom
active
secret preview: whsec_...9kf2
HTTP 200
https://archive.example.com/reports
disabled
secret preview: whsec_...9kf2
No recent delivery
Activity feed
API key created · hicham@company.com
Webhook test succeeded · HTTP 200
Jira connected · OAuth completed
Confluence kept active · SharePoint blocked
Fig 25. Integrations/API workspace — provider connections, scoped API keys, webhook controls, and activity history in one settings area.
Permission model on this page
The page is visible to workspace users, but management actions are restricted. In the current application, only owner and admin can create API keys, manage webhook endpoints, or connect and disconnect integrations. Executive and member access is effectively read-only here.
Area
Where in the UI
What actually happens
Integrations
Tab: Integrations
Providers are grouped into workflow and knowledge sections, with provider-specific connect or configure flows.
API keys
Tab: API & Webhooks
A create form issues a scoped key, shows the plaintext only once, and then stores only prefix/hash metadata.
Webhooks
Tab: API & Webhooks
A webhook form stores endpoint URL, description, subscribed events, status, and last delivery diagnostics.
Activity
Collapsible activity feed
Recent integration, API key, and webhook events are pulled from the settings activity audit stream.
API Keys
API keys are created in the API & Webhooks tab. The real form in the app asks for a key name, one or more scopes, and an optional expiry window in days. The backend accepts expiry values from 1 to 3650 days and returns the plaintext credential only at creation or rotation time.
Field
Required
What the app does with it
name
Yes
Used as the operator-facing label in the key list and audit trail.
scopes
Yes
Validated against the supported scope catalog before the key is issued.
expiresInDays
Optional
Converted into an absolute expiry date; if omitted, the key remains non-expiring until revoked.
Synchronise assessment status, FRIA content, bulk requirement updates, and approval-related metadata with internal tooling.
read:audit
Read the audit trail and verify hash-chain integrity from external tooling or evidence pipelines.
read/write:dossiers
Create conformity dossiers, inspect lifecycle state, and progress them through approval or issuance steps.
read/write:remediation
Read remediation plans, create manual tasks, and update remediation completion state from external systems.
read/write:reports
Generate, fetch, or process compliance reports from machine workflows.
read/write:incidents
Feed serious incident operations into downstream ticketing or response systems.
read/write:systems
Create or update AI system inventory records from internal registries or engineering platforms.
read:billing
Expose usage or billing data to internal dashboards without granting payment control.
Two authentication models exist here
Settings management endpoints such as /api/settings/api-keys use the authenticated dashboard session and are intended for human administrators. Machine access uses Authorization: Bearer actloom_... against the versioned API surface under /api/v1/*.
Versioning and pagination in v1
The public v1 API now returns an API-Version header and standard pagination metadata with total, page, pageSize, and hasMore on list endpoints.
What operators should know before issuing a key
Only owners and admins can create, rotate, or revoke keys.
The settings UI keeps only metadata after creation: name, prefix, scopes, created date, last use, expiry, and revoked state.
Rotation returns a new plaintext secret once and updates the stored hash and prefix.
Revocation marks the key with `revokedAt` and prevents further use.
Operation
Method
Endpoint
Notes
List keys
GET
/api/settings/api-keys?companyId={companyId}
Returns existing keys, supported scopes, and `permissions.canManage`.
Create key
POST
/api/settings/api-keys
Returns plaintext key once in `plaintextKey`.
Rotate key
POST
/api/settings/api-keys/{apiKeyId}/rotate
Issues a new secret and returns the new plaintext once.
Revoke key
DELETE
/api/settings/api-keys/{apiKeyId}
Marks the key revoked without deleting its historical record.
Example: create a scoped key from an authenticated admin session.
These endpoints back the actual settings page. They are useful when your internal admin tooling needs to bootstrap API keys, manage webhook endpoints, or orchestrate provider connections through a signed-in operator session.
Surface
Auth model
Primary use
Settings endpoints
Dashboard session cookie
Human-admin lifecycle actions such as connect, create, rotate, revoke, test, or delete.
Machine API
Bearer API key
Automated reads and writes against versioned operational endpoints under `/api/v1/*`, including batch onboarding, audit verification, FRIA, and bulk assessments.
Area
Method
Endpoint
Purpose
Machine API
GET
/api/v1/ai-systems?page=1&pageSize=25
Paginated AI system inventory listing with API version headers.
Machine API
POST
/api/v1/ai-systems/batch
Bulk-create up to 50 AI systems in one request for onboarding or registry sync.
Machine API
GET / POST / PATCH
/api/v1/assessments and /api/v1/assessments/bulk
List, upsert, and bulk-update compliance assessments via scoped API keys.
Machine API
GET
/api/v1/score-history
Read historical compliance score snapshots for an AI system or the whole workspace.
Machine API
GET
/api/v1/audit and /api/v1/audit/verify-integrity
Read audit events and verify the hash-chain integrity externally.
Machine API
GET
/api/v1/*/export?format=json|csv
Export AI systems, assessments, incidents, or audit events in machine-friendly JSON or downloadable CSV.
Machine API
POST
/api/v1/ai-systems/import and /api/v1/assessments/import
Import JSON or CSV payloads using the same batch validation rules as the public API.
Machine API
GET / PUT / POST
/api/v1/ai-systems/{id}/fria, /generate, and /approve
Read, generate from system context, update, and approve FRIA records programmatically for high-risk deployer systems.
Machine API
GET / POST / PATCH
/api/v1/dossiers and /api/v1/dossiers/{id}/status
Create conformity dossiers and move them through draft, approved, and issued states.
Read remediation plans, create manual remediation tasks, and update task lifecycle state via API keys.
Machine API
GET
/api/v1/release-gates and /api/v1/release-gates/dry-run
Evaluate the Smart Release Gate for an AI system. Returns the 4-tier decision (allow_production, allow_staging, allow_preview, block), readiness %, top-3 gaps, and override state. `dry-run` never records audit events.
Machine API
POST
/api/v1/release-gates/override
Grant a time-boxed override (max 48h) on a blocking gate. Requires `write:systems` scope, a written reason (min 10 chars), and is logged to the audit trail.
Integrations
GET
/api/settings/integrations?companyId={companyId}
List visible providers for the workspace and whether management is allowed.
Integrations
PUT
/api/settings/integrations
Connect or disconnect a provider.
API keys
GET
/api/settings/api-keys?companyId={companyId}
List keys, supported scopes, and permissions.
API keys
POST
/api/settings/api-keys
Create a scoped API key.
API keys
POST
/api/settings/api-keys/{id}/rotate
Rotate key material.
API keys
DELETE
/api/settings/api-keys/{id}
Revoke a key.
Webhooks
GET
/api/settings/webhooks?companyId={companyId}
List endpoints, supported event types, status, and delivery diagnostics.
Webhooks
POST
/api/settings/webhooks
Create endpoint and return signing secret once.
Webhooks
PATCH
/api/settings/webhooks/{id}
Update URL, description, event subscriptions, or active/disabled state.
Webhooks
DELETE
/api/settings/webhooks/{id}
Delete endpoint.
Webhooks
POST
/api/settings/webhooks/{id}/test
Send a test delivery and persist the resulting status.
How the integrations tab behaves in the app
Provider family
Current behavior in Settings
Jira / Confluence / SharePoint
Use real provider authorization flows rather than a simple local toggle.
ServiceNow
Uses a dedicated configuration panel and setup flow instead of direct OAuth toggle behavior.
Knowledge integrations
Confluence and SharePoint are mutually exclusive in the UI: the page blocks connecting one while the other is active.
Activity log
Shows recent connection, key, and webhook actions so operators can verify who changed what and when.
Build the publishable package with npm run sdk:pack. It generates typed OpenAPI bindings into @actloom/sdk and ships the actloom CLI for CI pipelines.
Example: actloom systems list --base-url https://app.actloom.com --api-key $ACTLOOM_API_KEY
Build the Python package with npm run python-sdk:build. It generates the actloom client package and outputs a wheel plus sdist under packages/python-sdk/dist.
Webhooks
Webhooks are configured in the same API & Webhooks tab. The real form captures endpoint URL, description, and a set of subscribed events. Each saved endpoint then exposes controls to test delivery, switch between active and disabled, and delete the endpoint entirely.
What the webhook list tells an operator
Secret preview only
The page stores and displays only a short secret preview after creation. The full signing secret is returned once and must be stored externally.
Delivery diagnostics
Each row can show the last response code, last failure time, and last error so you can debug receiver issues without leaving the app.
Safe lifecycle controls
You can disable an endpoint temporarily, test it, or remove it entirely from the same table.
Track higher-level remediation workstreams from initial generation through closure.
audit.integrity_failed
Escalate immediately when audit-chain verification detects corruption or tampering.
billing.subscription.updated
Notify finance or internal ops when workspace subscription state changes.
release_gate.allowed / release_gate.blocked
Notify pipelines, Slack channels, or release managers when a Smart Release Gate flips between allow and block.
release_gate.overridden
Alert reviewers and on-call engineers when an operator temporarily bypasses a blocking gate, including the 48h expiry and written justification.
Endpoint URL restrictions
On creation, the backend rejects blocked webhook URLs. In practice, ActLoom expects a public HTTPS receiver and explicitly disallows private, loopback, and reserved IP destinations.
Test deliveries update endpoint status
The built-in test route performs a real outbound POST with a 10-second timeout. The result is written back to the endpoint record as response code and last error information, so operators can immediately see whether the receiver worked.
Example: create a webhook endpoint from an authenticated admin session.
The Test action in the webhook table, or POST /api/settings/webhooks/{id}/test, sends a real request to the configured endpoint and records the result. This is the fastest way to validate receiver reachability, timeout behavior, and basic request parsing before you depend on live events.
Your receiver is publicly reachable from the ActLoom backend.
Your handler returns a 2xx response within the timeout window.
Your logs capture the event type and delivery id headers for troubleshooting.
Your operational team can diagnose failures using the stored `lastResponseCode` and `lastError` values in the webhook row.
Release Gates
The Smart Release Gate API lets CI/CD pipelines ask ActLoom a single question before shipping: “is this AI system cleared to deploy to preview, staging, or production?” Instead of a binary allow/block, the gate returns a tiered decision so teams can ship to lower environments while still closing gaps for production.
Backward compatible
The existing allow boolean and status: "allow" | "block" fields are still returned. New integrations should read the richer smartGate object; legacy CI scripts keep working without changes.
How the 4-tier decision is computed
allow_production (≥ 95%)
Cleared for any environment. Readiness blends compliance score (70%) and coverage (30%). No open blockers, no serious incidents, no overdue remediation.
allow_staging (80–94%)
Cleared for staging and preview. Production is gated until top gaps are closed. Typical state for systems missing one or two evidence items.
allow_preview (60–79%)
Cleared for preview only. Critical gaps still open — production and staging are blocked.
block (< 60% or hard blocker)
No environment allowed. Hard blockers (prohibited system, open serious incident, overdue remediation, blocked verdict) force block regardless of score.
Drive branching logic in the pipeline — e.g. deploy to prod only when tier is allow_production.
smartGate.maxAllowedEnvironment
preview | staging | production | null
The highest environment currently cleared. `null` means blocked.
smartGate.allowRequested
boolean
True if the environment the pipeline asked for is ≤ max allowed. Usually the only field a simple pipeline needs.
smartGate.readinessPct
0–100
Composite readiness used for tier selection. Useful for dashboards and Slack posts.
smartGate.topGaps
array of up to 3 gaps
The top 3 gaps to close next, ranked by priority÷effort. Each has `requirementName`, `articleReference`, `priority`, `effortDays`, and an `impact` label (`unblocks_production`, `unblocks_staging`, `reduces_risk`).
smartGate.estimatedDaysToProduction
number
Sum of effort across all open blockers — a rough ETA to reach allow_production.
smartGate.canOverride
boolean
Whether an operator may grant a 48h override. Always false for prohibited systems and open serious incidents.
smartGate.explanation
string
Human-readable one-liner for Slack notifications, PR comments, or CI logs.
Use GET /api/v1/release-gates/dry-run from pre-merge checks and PR comments — it computes the same decision but does not write to the audit trail. Keep GET /api/v1/release-gates for the final deployment gate, so every shipped release leaves a hash-chained audit entry.
Time-boxed overrides
When a system is blocked but the team needs to ship a hotfix, authorized operators can grant a 48-hour maximum override. Every override is persisted in Vercel KV with auto-expiry, logged to the audit trail, and emits a release_gate.overridden webhook so reviewers and on-call engineers are notified.
Override rules enforced by the backend
Reason is required and must be at least 10 characters — regulators will ask.
Window is capped at 48 hours even if the caller asks for more.
Prohibited systems and open serious incidents can never be overridden — those require resolution, not a bypass.
The override is scoped to one (company, system, environment) triple; granting prod does not leak to staging.
The next gate evaluation after the window sees the override as expired and falls back to normal logic automatically.
Granting an override requires an API key with the write:systems scope. The endpoint is intentionally narrow — it re-evaluates the gate before granting to make sure the override is not being used to bypass a hard blocker that just appeared.
GitHub Actions example
A minimal pre-deploy job that fails the pipeline when the smart gate does not clear the requested environment, and posts the explanation to the Actions summary:
Call `dry-run` on every PR and post `smartGate.topGaps` as a PR comment so reviewers see the gaps before merge.
Call the live gate only on the deploy job, so every production release leaves a hash-chained audit entry.
Subscribe a webhook endpoint to `release_gate.allowed`, `release_gate.blocked`, and `release_gate.overridden` to keep Slack and on-call informed without pipeline coupling.
Treat `canOverride: false` as non-negotiable — do not add a bypass path in the pipeline; prohibited and serious-incident blocks exist for a reason.
Ready to get started?
Join hundreds of companies using ActLoom to simplify AI Act compliance. Start your free assessment today — no credit card required.