Bitbucket Cloud and Data Center setup

Before connecting Bitbucket

Use this page when the customer wants WebRiskOps to send remediation work to Bitbucket Cloud issues or to decide that a Bitbucket Data Center team should use Jira or portable fallback instead. Bitbucket setup must confirm issue availability before WebRiskOps stores credentials or maps repositories. Start from `/settings` after Cloud and self-hosted integrations confirms the deployment mode. Do not save a Bitbucket target until the customer-owned workspace, repository boundary, auth method and network path are clear.

Connect a Bitbucket target

Follow the path `Cloud and self-hosted integrations → Bitbucket target → Issue availability check → Bitbucket Cloud export, Jira export or portable fallback`.

1. Open /settings and review Integration status, then choose Bitbucket Cloud or Bitbucket Data Center setup. Result: provider_key is recorded as bitbucket_cloud_issues or bitbucket_data_center_issues before repository fields are requested.
2. For Bitbucket Cloud, confirm the customer-owned workspace and repository, then choose OAuth or app password auth_method. Result: credentials are limited to the workspace repositories that can receive issues.
3. For Bitbucket Data Center, enter base_url only after the customer confirms ownership, reachable API root and scan or export authorization. Result: deployment_mode is self-hosted and private-network checks run before tokens are accepted.
4. Confirm whether the target can use native Bitbucket Cloud issues or must route through Jira or portable export. Result: unsupported Data Center issue workflows do not receive provider-native ticket attempts.
5. Select scopes for workspace, repository and issue access only when Bitbucket Cloud issue tracking is enabled. Result: WebRiskOps can validate workspace, repository_slug, component and priority later without asking for broader access.
6. Review allowlist_status for Bitbucket Data Center. Result: firewall, VPN or approved tunnel state is visible before WebRiskOps tries provider API calls.
7. Save only when provider auth and network checks are ready. Result: the Bitbucket target is available to the correct export path without exposing secrets in documentation or support messages.
8. If PROVIDER_AUTH_REQUIRED appears, reconnect OAuth or the app password before retrying. Result: the target stays blocked until valid credentials exist.
9. If PROVIDER_BASE_URL_BLOCKED or PROVIDER_SCOPE_UNAVAILABLE appears, fix the URL or scope, or use Jira or portable fallback. Result: unsafe Data Center hosts and unavailable Bitbucket permissions do not receive evidence.
10. Continue to Bitbucket export only for Bitbucket Cloud issue tracking. Result: Data Center customers use Jira export or portable fallback instead of an unsupported native issue path.

Configure Bitbucket authorization

Bitbucket setup should make the issue workflow explicit before credentials are saved.

• `bitbucket_cloud_issues` is for Bitbucket Cloud repositories with issue tracking enabled.
• `bitbucket_data_center_issues` records a self-hosted Bitbucket target, but native issue export may still be unavailable.
• `auth_method` should identify OAuth or app password setup before a credential is saved.
• `scopes` should allow workspace, repository and issue access only when Bitbucket Cloud issues are supported.
• Bitbucket Data Center teams that track issues in Jira should use Jira export instead of a native Bitbucket issue target.
• Revoke access in Bitbucket first, then disconnect the Bitbucket target in WebRiskOps so historical reports keep references without keeping live credentials.

Ready Bitbucket integration states

Continue only when the selected Bitbucket path can safely receive work.

• Bitbucket Cloud issue target ready means `provider_key` is `bitbucket_cloud_issues`, the workspace is customer-owned and repository issue tracking is enabled.
• Bitbucket Data Center boundary ready means `provider_key` is `bitbucket_data_center_issues`, `deployment_mode` is self-hosted and `base_url` passed URL safety checks.
• Issue workflow ready means Bitbucket Cloud can receive native issues, or the customer has chosen Jira export or portable fallback.
• Network ready means `allowlist_status` shows the Data Center target is reachable through a safe direct, allowlisted or customer-approved tunnel path.
• Fallback ready means unsupported Data Center issue workflows have an automated Jira or portable handoff path.

Blocked Bitbucket setup states

Blocked Bitbucket setup should stop before evidence or credentials reach an unsupported target.

• `PROVIDER_AUTH_REQUIRED` means reconnect OAuth or the app password before saving or retrying export.
• `PROVIDER_BASE_URL_BLOCKED` means the Bitbucket Data Center URL failed ownership, redirect, DNS, reserved-IP or private-network checks.
• `PROVIDER_SCOPE_UNAVAILABLE` means the saved auth method cannot read workspace or repository issue settings.
• Missing `allowlist_status` means the Data Center target cannot be trusted for automated provider calls yet.
• Missing repository issue tracking means use Jira export or Portable export fallbacks instead of a native Bitbucket issue export.

Continue after Bitbucket setup

Continue to Bitbucket export only when Bitbucket Cloud issue tracking is enabled. Use Jira export when the customer uses Bitbucket Data Center or Server with Jira for issues, Portable export fallbacks when provider-native tickets are unavailable, Status sync and duplicate handling when a Bitbucket issue already exists, or Trello setup when the team tracks remediation in Trello.