Feature ideas

We are using search-based in github ocean integration and when there are more than 100 results we get Error: Audit: CREATE on githubTeam/{id} - Too many entities found for query of relation members We want to increase the number of returned entities to at least 500 so we could use this. Why search-based: We need resilience to non-existent member entities (createMissingRelatedEntities = false). Direct array mapping fails the entire team entity if any member's githubUser entity doesn't exist.

Overview Enable native support for SBOM ingestion through the Wiz integration/exporter, leveraging Wiz Graph API resources: https://app.wiz.io/graph-documentation Goal Allow customers to ingest SBOM-related data from Wiz into Port in a structured and scalable way, enabling visibility into packages, dependencies, vulnerabilities, and their relationships to services and repositories. Requested Resources (from Wiz Graph API): Package & Branch Package Code Repository & Repository Branch Resource Declaration Code Technology & Hosted Technology Vulnerability These resources should allow us to model: Package inventories per image/repository Dependency relationships Vulnerability exposure Technology stack attribution Code-to-resource mapping

Currently, Port lacks a command-line interface (CLI) tool for creating blueprints, entities, scorecards, and other functionalities. Introducing such a tool could provide valuable assistance to users.

Introduce a way to trigger alerts when a data source sync fails, allowing teams to integrate Port with their monitoring/observability stack. This could be achieved via automation trigger (add a trigger for “sync failed” events scoped per exporter and/or per kind). Or, via a built-in alert configuration (add an alert configuration section within the Sync Status page, and allow users to define notification rules for failed syncs).

Enable users to validate integration setup before full installation by testing connectivity, access, and basic permissions. Reduce setup errors and improve user confidence in integration correctness during onboarding.

I'd like to be able to pipe file contents from a property mapping like readme: file://README.md to a JQ expression. For example, since scorecards can't currently evaluate markdown fields, I'd like to add a has_readme boolean to my git repository blueprint, mapped like: has_readme: (file://README.md // null) != null For this case, with a GitHub integration, my workaround is to use kind: file mapping rules to do this, since they can read file .content . However, I need a separate mapping rule for _each file_ I need to evaluate in the repo, meaning the sync has to scan every repo in my organization once for each file I need to read. In my case, each file mapping rule takes 10+ minutes to resync, and I need 4 of them so far, adding 40-50 minutes to a full repository resync. Reading files probably isn't free, but maybe it would take less time to do it while traversing the whole list of repositories list once, instead? And it would clean up my mapping. NOTE: This is a duplicate of "File ingestion - JQ manipulation", with the motivation of cleaning up mappings and reducing resync time. https://roadmap.getport.io/ideas/p/file-ingestion-jq-manipulation

At present integrations do not support body parameter based, when using the custom Ocean integration calling APIs such as the GitLab graphql API is not currently possible as the cursor value cannot be passed back into the next request body as is standard within the "Relay Cursor Connections Specification" The ask is to allow extracted body values to be passed into the next request to enable cursors to work when located within the request body. Thanks

Today, out of the box Ocean integrations come with a fixed set of predefined kinds. When users want to ingest data from API endpoints that are not covered by those kinds, they either need to wait for Port to add a new kind or create a separate custom Ocean integration, including authentication and connection setup, even though they already have an existing integration configured. This creates unnecessary friction and duplication. We should allow users to define custom kinds directly within out of the box Ocean integrations, reusing the existing authentication and connection that Port already manages, so they can fetch additional data from supported APIs without creating a new integration or waiting for Port to add more kinds

Current scenario: Integrations are calculating the payload based on the mapping YAML, and they send all properties that are being mapped. Suggestion: Add the ability to drop the key in the mapping configuration. This way, the integration will not override existing keys in Port, while still having the ability to map data dynamically. Example: protected: if (.branch.protected != null) then .branch.protected else {DROP_KEY} end If the object contains the branch data, then map it to the entity, and if it does not a custom operation will drop the key from the payload, not overriding the current data.

Add an option of mapping integrations using a UI interface instead of a Yaml. The new UI should reduce friction points such as: Understanding the page layout and how to use different components Search for information in Port docs, to understand mapping and extraction capabilities. Search for information in 3rd party docs. Understanding Port’s Yaml structure Moving between tabs copying and pasting. (data model discoverability) Typos and syntax errors