Feature ideas

I want to get entity counts by $datasource, but currently this metadata property is not exposed. It would be ideal if the CSV you can download from the UI for entities would include a $datasource column to filter by, or if the API (/v1/blueprints/:blueprint_identifier/entities-count) would return this field to be filtered on as well.

Request to expose the live events ingest URLs used by Port-hosted integrations in the UI (exporter settings tab). Some tools are configured with restricted tokens, so the Port-hosted integration cannot register webhooks on their behalf. Or security teams want to configure webhooks endpoints themselves. When you need to create webhooks manually for a Port-hosted integration, you currently have to reach out to Port support for the ingest URL. It should just be visible in the UI.

Adding filters to event log so customers can find relevant logs based on: * specific sync * Kind * log level * ETL phase

Context We have fully migrated to the GitHub Ocean integration and are actively using it in production across our organization. :bug: Problem We Are Experiencing We are experiencing a critical and recurring failure during resync when repositories have a large number of open pull requests (~70–80+). We understand that the integration currently supports a maxResults parameter to cap the number of closed PRs fetched per repository: kind: pull-request selector: query: "true" states: ["closed"] maxResults: 50 # ✅ Works for closed PRs since: 60 However, no equivalent parameter exists for open pull requests — the integration fetches all open PRs unconditionally. When a repository accumulates ~70–80+ open PRs, this causes the integration to fail. We have confirmed that GitHub's own API also struggles under these conditions, but the lack of a configurable limit on the Port side amplifies the problem. :white_check_mark: What We Are Requesting We would like a maxResults (or equivalent) parameter for open pull requests, similar to what already exists for closed PRs, so we can cap the number of open PRs fetched per repository. Example of the configuration we need: kind: pull-request selector: query: "true" states: ["open"] maxResults: 50 # ✅ REQUESTED — limit open PRs per repo :briefcase: Business Impact We are currently manually closing pull requests in GitHub on affected repositories just to stay below the threshold where the integration stops failing. This is not a sustainable solution. The issue will recur, as those repositories naturally generate a high volume of open PRs. This is our highest priority limitation with the Ocean integration at this time. Thank you for considering this request!

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

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.

In some cases we have 2 exporters/intergation that are enriching the same entity. In some case, one of the exporter will set a value and then the second exporter will set the value as null. This is causing the value to flip between the value and null. I want to be able to add a flag in the mapping ignoreNulls: true/false When this is set to true, the exporter/integration will not update the field in the entity. This could be applied to Ocean based integration as it should upsert only the mappings with has a value.

Currently, the API data source card displays all blueprints that have ever been successfully ingested through them. Even if the entities ingested via API for those blueprints are removed, those blueprints continue to appear in the data source card. This can cause confusion and unnecessary clutter, as the card no longer reflects the active mappings.

Today, when updating new objects / arrays of entities the new value overrides the old one. With this feature it will be possible to append values to these properties. Example of Tags property with type of array: Current state: "Tags" : ["tag1"] Ingesting a new tag using the API: "tag2" New state: "Tags": ["tag1", "tag2"]

Request to add first-class support for the AWS::ECS::TaskDefinition resource type to the AWS v3 integration so ECS task definitions can be ingested as their own kind and mapped into Port blueprints, similar to the existing support for AWS::ECS::Cluster and AWS::ECS::Service. Today we can only access the task definition ARN via AWS::ECS::Service (.Properties.TaskDefinition), which is not enough to understand the actual container configuration or link services to internal components and images. The feature should expose key ECS task definition attributes so they can be mapped into a dedicated blueprint and used for catalog relationships and scorecards. Specifically, we’d like to ingest: TaskDefinitionArn Family Revision Status ContainerDefinitions (for image and container config) Cpu Memory NetworkMode RequiresCompatibilities Tags