Integrations Page Guide

The Integrations page is the single admin-only surface where every outbound connection to your IT, security, and collaboration tools is configured, tested, and monitored. It is not a list of credentials in a database - it is the operational control plane for how Moftgate talks to the rest of your stack.

It lives under General > Settings > Integrations and is reachable from the General navigation, the main Settings page card, and the global Spotlight search. Non-admin users cannot reach it.

It groups four distinct capabilities that share a common theme: how Moftgate communicates with systems outside itself.

The active tab is set via a query parameter, so it is bookmarkable, shareable, and survives a page reload.

Close image

The Integrations tab is where most operators spend their time. It renders every supported integration type as a card - not a table - because integrations are configured objects, not rows of telemetry. Each card shows the provider logo, capability badges, a plain-language description, and the benefit of using it, so an operator can pick without reading external documentation.

Moftgate ships with ten native integration types, each with its own credentials, delivery behaviour, and capability set. Each type is a first-class connector, not a generic webhook with a different label.

Every outbound call - whether an event delivery or an asset sync - is recorded with the event name, URL, HTTP status, outcome, duration, and a message. This is the integration layer’s audit trail. The per-integration Events modal paginates this log so operators can troubleshoot failed deliveries, and the card shows the most recent outcome without opening the modal.

Configuring an integration is not a single long form. It is a multi-step wizard that validates each step before advancing, shows progress at the top, and lets you jump back to completed steps.

1. 1
   Details

   Provider logo, description, benefit, and a display name for the integration.

2. 2
   Configuration

   Type-specific fields such as URL, API key, token, project key, or site.

3. 3
   Events

   Which Moftgate events the integration should receive.

4. 4
   Asset sync

   For asset-capable types: enable sync and map endpoint groups to provider companies and sites.

5. 5
   Review

   Summary, test connection, active toggle, and save.

Webhooks are the generic, provider-agnostic counterpart to native integrations. Where a native integration knows how to talk to Jira or Splunk, a webhook just POSTs a signed JSON payload to any URL you configure. Use webhooks when you want to deliver events to a system Moftgate does not have a native connector for.

When a webhook has a secret configured, every delivery is signed with HMAC-SHA256 over the JSON body, sent in the X-Moftgate-Signature header. The receiver verifies the signature to confirm the payload came from Moftgate and was not tampered with in transit.

Deliveries are queued and retried up to three times with backoff, so a slow or temporarily unavailable receiver never blocks request handling. You can also send a manual test payload from the webhook card to verify your endpoint.

API keys allow programmatic access to the Moftgate REST API. They are the credential you hand to a script, a CI pipeline, or a third-party tool that needs to read or write Moftgate data.

• Keys are stored as hashes - the plaintext token is never persisted.
• The token format is a prefix followed by 64 hex characters (32 random bytes), shown only once at creation time.
• Authentication uses a Bearer token header. The panel looks up the key by its prefix, then verifies the hash.
• Two abilities: read (read-only) and write (read and write).
• Revocation: delete the key or deactivate it. Both stop the token immediately.

Single sign-on provides OIDC-compatible identity provider login for panel users. This is fully functional login, not just configuration storage. Four provider types are supported: Microsoft Entra ID, Google Workspace, Okta, and Custom OIDC.

The SSO modal is a two-column layout: the form on the left, a persistent setup guide on the right with copyable callback and discovery URLs and step-by-step instructions. The guide stays visible while you fill the form so focus is never lost, and on narrow screens it stacks below the form. Every URL in the guide is a copy-on-click chip, so you never have to select text manually.

A client ID and client secret are required for every OIDC provider - they identify this panel as an OAuth2 client at the identity provider. The client secret is stored encrypted and is never exposed to the browser. When editing a provider without supplying a new secret, the existing value is preserved.

The login page lists every active SSO provider as a sign-in button. When a user signs in, the panel validates the identity token, matches the user by email, and either logs them in or auto-provisions a new account. Local 2FA is bypassed because MFA is handled by the identity provider. A test connection button in the modal validates the configuration before saving by loading the discovery document and signing keys.

SIEM log forwarding is managed separately from the Integrations page, from the main Settings page via the SIEM Log Forwarding card. It supports UDP, TCP, and HTTPS transports and CEF, LEEF, RFC 5424, and JSON formats, so you can stream logs to any SIEM that prefers a syslog-style input over an HTTP API.

This complements the native Splunk integration on the Integrations tab: use the Splunk integration for HTTP Event Collector forwarding, and use SIEM forwarding for streaming syslog to Splunk, QRadar, or any other collector.

• Outbound-only: every integration, webhook, and asset sync is outbound. The panel initiates all requests - no inbound firewall rule, no public callback URL, no exposed listener.
• Encrypted secrets: API keys, client secrets, HEC tokens, and private keys are stored encrypted or hashed at rest. The plaintext API token is shown once at creation and never exposed to the browser in edit forms.
• Per-integration credentials: each integration has its own credentials. A compromised Slack webhook URL does not expose your Jira API token - least privilege applied at the integration boundary.
• Audit logging: every admin action on the Integrations page is logged with named parameters, and the audit log is itself an event source for webhooks.
• Transactional writes: critical operations - creating an integration with group mappings, creating an API key, storing an SSO provider - are wrapped in database transactions so a partial failure never leaves the system inconsistent.