Feature ideas

Currently OCEAN__METRICS__ENABLED and OCEAN__METRICS__WEBHOOK_URL can't be set on port hosted ocean integrations. This makes this guide: https://docs.port.io/guides/all/monitor-integrations/ not possible on such integrations. There should be an easy way to set this up in the UI. (Really what I want is automatic creation of an entity on each sync, perhaps there could be a simpler way to achieve this)

The GitHub Ocean integration discovers and filters organizations using the /user/orgs endpoint, which only returns orgs the authenticating PAT is a direct member of. As a result, explicitly configured orgs are silently dropped whenever the token isn't a member, even though the same PAT can already read those orgs' repositories via /orgs/{org}/repos. This blocks a common enterprise setup: one technical token needs to ingest repositories shared across many GitHub organizations (for example, to run compliance and scorecard checks across all of them) without joining every org as a member. The only current workarounds are patching the integration or migrating the whole setup to GitHub App auth, neither of which scales. Honoring explicitly configured, PAT-accessible organizations regardless of membership would remove this limitation.

Currently, customers utilizing the official Port Slack application for notifications and automated workflows cannot automatically invite team members to Slack channels (for example, during incident response room orchestration). The underlying Slack API requires specific invite permissions primarily channels:write.invites, groups:write.invites, and mpim:write.invites which are not part of the official app’s default OAuth configuration. Because end-users cannot modify the permissions of the pre-built Port Slack integration on their own, customers are currently forced to build and manage a separate custom Slack bot app. This creates administrative overhead, adds token maintenance, and causes end-user confusion from having multiple Port-related apps in the workspace. To solve this, we request adding channels:write.invites, groups:write.invites, and mpim:write.invites to the official Port Slack application’s OAuth scopes . Expanding these default scopes will enable customers to seamlessly invite responders to incident channels directly via Port automations and workflows after re-authorizing the app, eliminating the need to set up a secondary custom app and keeping all Port Slack operations consolidated under a single integration.

My customer (Alphasense) has reported they were blind to sync issue failings on Ocean Integrations - specifically GitLab. Causing a loss in confidence in the platform. It does not appear to be possible to trigger an alert from a Port-Hosted Ocean integration failure. Add the ability to trigger a notification pipeline when the the Sync status of an Ocean Integration is in a failure state.

Ability to manage integrations through Terraform The issue right now is that the user needs to create integration manually using UI, then we can import to terraform code. We want to have also creation part in terraform. Terraform is by default tool which should support all crud(create/read/update/delete) actions. In this case create action is not supported. This is problematic when we will have multiple integrations and multiple environments as we will need to do this manually per each integration and environment. (ed

Terraform Cloud sync performance should also be reviewed, as syncing approximately 200 workspaces currently takes 20 to 30 minutes.

Review how Terraform state files are ingested and stored to reduce the risk of exposing sensitive values, including credentials that may be present in state data.

Improve the Terraform Cloud integration by addressing rate-limit handling, fixing errors in the default mapping, and strengthening relationships between users, teams, workspaces, projects, and organizations.

Currently, a field is flagged as "misconfigured" whenever its jq expression returns null during integration resyncs, and it's logged as a [Transformation Layer] Mapping error at error level in the event log. Often times though, jq expressions intentionally return null, and it's a documented pattern for optional fields (using // null). The sync does still proceed with that field empty on the ingested entity. Lowering the log level to debug for null/missing field results would eliminate false-positive noise for customers in the event log. Minimally, the log should make clear that null results may be intentional, surface the affected fields and row counts, and prompt users to verify their mapping only if population was expected.

Currently, if Sonarqube projects are manually related to GitLab projects within Sonarqube, this cannot be reflected in Port. Ideally, Port admins will be able to use the ALM bindings from the Sonarqube API to show the relation between Sonarqube and GitLab projects ( https://sonarqube.inria.fr/sonarqube/web_api/api/alm_settings/get_binding ).