Feature ideas

To extend support for additional AWS resource types in the Port-hosted AWS integration, for DynamoDB Tables, Secrets Manager Secrets, Backup Vaults, Route53 Hosted Zones, VPCs, and Subnets. These resources are currently only available via the self-hosted AWS exporter. Adding support for them in AWS port hosted would be beneficial.

We want to add support for installing the skills from port CLI in VSCode It supports the same hooks as Cursor which you already support so I think this should not be a big effort.

Add support for ingesting billing and cost usage data, including consumption, credits, usage-based charges, and gross/net cost by user, org, account, and model. This would help customers monitor spend, understand consumption patterns, and measure cost efficiency.

Summary Track PR Rework as a key engineering metric - the number of review cycles or post-review commits before a PR is approved. Integrations Should support the following key SCMs: GitHub GitLab Azure DevOps

The native GitLab integration in Port does not currently expose the duration field for pipeline entities. We'd like this field to be supported natively. The current pipeline kind mapping fetches data from the GitLab list pipelines endpoint (/api/v4/projects/:id/pipelines), which returns fields such as status , created_at , updated_at , and web_url . However, the duration field is only available on the individual pipeline detail endpoint ( /api/v4/projects/:id/pipelines/:pipeline_id ). What we need: For each pipeline fetched during resync, we'd like Port to also retrieve the detailed pipeline record so that the duration field is available for mapping.

Currently the ADO kind for Test Runs containers both Code Coverage and Test Results. These should be separate kinds.

Add a native Port integration with Harness to sync cost and deployment data into the Port catalog. Key capabilities needed: > Pull cost data (ideally at resource/ARN level) into Port entities > Enable cost attribution by service and team ownership > Surface Harness cost visibility alongside other catalog data without requiring expert-level Harness dashboard access This would allow platform teams to tie cloud spend directly to service owners in Port, driving cost accountability without requiring developers to navigate Harness directly.

The Snyk Target portion of the port hosted Snyk integration is not returning empty targets (targets with no projects). The default behaviour of the Snyk api appends the exclude_empty=true query param to the next page link. I'd like there to be a way to tell the integration not to exclude_empty targets. We want a way to be able to see if a repo is in Snyk or not, but we have repos in snyk that don't have projects. Maybe it can be an additional selector?

Customers using the Aikido Ocean integration needs team ownership surfaced at the issue group level, not just on individual issues. Their teams use included_paths to define responsibility, and while individual Aikido issues map correctly to teams via affected_file, issue groups only expose repository-level data — so the same matching can't be applied. The natural workaround (relating issue groups → child issues → teams via mirror properties) is blocked by the 500-entity search relation cap, since groups can have hundreds of child issues. A simple SET aggregation also doesn't meet their needs — because individual issues can belong to multiple teams, they need a distinct list of teams per issue group, making this a true many-to-many relationship. Requested: Add a native team dimension to the Aikido integration by leveraging Aikido's own team→issue group mapping: GET /api/public/v1/teams GET /api/public/v1/open-issue-groups?filter_team_id={ team.id } This would expose a team_issue_groups resource (or equivalent relation on issue groups) with the distinct set of owning teams per group — modelled as many-to-many. Without this, the customer is forced to build and maintain an external scheduled aggregation job.

If you could support the gitlab graph api in the way you do for GitHub it would be great as a lot more information is exposed than the standard APIs. Thanks