Cloud and self-hosted integrations

Before saving a provider target

Use this page before a customer connects Jira, GitHub, GitLab, Bitbucket, Trello, Linear, Azure DevOps, YouTrack, Asana, ClickUp or a webhook endpoint. Cloud and self-hosted targets need different URL, auth and network checks before WebRiskOps can store credentials or send ticket export data. Start from `/settings`, then review Integration status and the provider-specific setup page that matches the target. Do not collect credentials until the deployment mode and safe network path are clear.

Choose cloud or self-hosted setup

Follow the path `Settings → Integration status → Deployment mode → Auth and network check → Provider-specific setup → Ticket export target`.

1. Open /settings and review Integration status before adding or reconnecting a provider. Result: the customer can see which provider family needs cloud, self-hosted or webhook setup.
2. Choose the deployment mode before collecting credentials. Result: WebRiskOps knows whether to expect a public cloud OAuth flow, API token, personal access token or self-hosted base URL.
3. For cloud providers, confirm the customer-owned tenant, organization, workspace or site URL. Result: auth_method and token_type are limited to the provider account that will receive tickets or automation.
4. For self-hosted providers, enter base_url only after the customer confirms ownership and scan or export authorization. Result: private-network, redirect, DNS rebinding and reserved-IP checks can run before credentials are accepted.
5. Check allowlist_status when the target is behind a firewall, VPN or customer tunnel. Result: WebRiskOps knows whether provider API calls can be retried, blocked or routed through an approved network path.
6. If PROVIDER_AUTH_REQUIRED appears, reconnect with the provider-specific guide instead of saving a blank target. Result: the customer sees the exact OAuth, app, API token or PAT action required.
7. If PROVIDER_BASE_URL_BLOCKED appears, stop and use portable fallback or a cloud provider target until the URL policy is fixed. Result: private or unsafe hosts do not receive credentials or evidence.
8. After the target is saved, continue to the provider-specific setup page and then the ticket export provider overview. Result: export, duplicate handling and revoke access use the same provider record.

Configure access and network checks

The saved target should describe how WebRiskOps may authenticate and reach the provider without exposing secrets in documentation, screenshots or support messages.

• `base_url` is required for self-hosted, server, data center and webhook-only targets.
• `auth_method` should identify OAuth, app installation, API token, personal access token or webhook signing before any secret is entered.
• `token_type` should match the provider-specific guide so customers know whether they are granting issue-only, repository, work item or webhook delivery access.
• `allowlist_status` should show whether the provider can be reached directly, through a customer-approved tunnel, through an allowlist or not at all.
• Revoke access from the provider first, then disconnect the target in WebRiskOps so historical reports keep their provider references without keeping live credentials.

Ready integration states

Continue only when the target is understandable and safe for the selected deployment mode.

• Cloud target ready means the provider account, tenant, organization, workspace or site URL belongs to the customer and the auth method matches the provider guide.
• Self-hosted target ready means `base_url` passed redirect, DNS rebinding, reserved-IP and private-network checks.
• Allowlist ready means firewall, VPN, tunnel or customer network policy is recorded before WebRiskOps retries provider API calls.
• Credential boundary ready means the customer knows which OAuth grant, app install, API token, PAT or webhook secret can be revoked later.
• Fallback ready means portable export is available when provider auth or network policy cannot be made safe.

Blocked or unsafe states

Do not work around blocked provider setup by collecting broader credentials.

• `PROVIDER_AUTH_REQUIRED` means the target cannot run until the provider-specific OAuth, app, API token or personal access token step is completed.
• `PROVIDER_BASE_URL_BLOCKED` means the URL failed private-network, reserved-IP, redirect, DNS or ownership checks.
• Missing `allowlist_status` means WebRiskOps does not know whether a self-hosted target is reachable through an approved network path.
• Unclear tenant, workspace, organization or repository ownership means the customer must confirm the provider account before saving credentials.
• A provider limitation means the customer should use a supported cloud target, another provider page or portable fallback instead of requesting manual handling.

Continue to provider setup

Continue to the provider-specific page that matches the customer target: Jira Cloud and Jira Data Center setup, GitHub.com and GitHub Enterprise Server setup, GitLab.com and self-managed GitLab setup, Bitbucket Cloud and Data Center setup or Generic webhook automation setup. After the target is safe, use Ticket export provider overview to choose the export path.