Feature ideas

Add an Integration Health Dashboard to Port that provides real-time visibility into the status and uptime of connected integrations like GitHub, Jira, Datadog, and ServiceNow. The dashboard should surface outages, degraded performance, sync failures, API rate limit issues, and historical uptime metrics in a centralized view. This would improve operational clarity, reduce troubleshooting time, and help customers quickly identify whether issues originate from Port or external systems. Visibility and proactive alerting around integration health would significantly increase enterprise trust and platform transparency.

Add option to specifically resync a predefined list of resources & do a scheduled resync only for a selected list of resources

GitHub Ocean file and folder kinds should support repository search so customers can pre-filter which repositories are scanned at fetch time. Today, when repos is omitted, the integration lists every accessible repository, searches for matching files in each one. The repos field works today and does pre-filter at fetch time, but it requires an explicit list of exact repository names. That does not scale for orgs that maintain a dynamic list of repos to search, repos are added and removed frequently based on naming patterns, and manually keeping a static repos list in sync is impractical at scale. repoSearch already exists on repository, PR, and issue kinds but not on file or folder. Adding it to file/folder selectors would let customers dynamically scope file ingestion using GitHub Search queries without scanning the entire org or manually updating a repo list.

Today you can only manage the integration configuration using Terraform, but ideally we would want Terraform to also install the integration in Port hosted integrations on first Terraform apply.

Today you can manage permissions on a Page, Self service, and blueprint level. Since some IDPs can have multiple "Builder" teams in different business domains, it would be ideal to have the option to define for each data source who has permissions to view the mapping, and modify it.

As admins, we would like to see in port the metadata about blueprints so then we could create charts about the number of entities and more Maybe the easiest solution is to have a port integration to port --- As an admin, I will be able to: Access Metadata: View comprehensive metadata within Port for: Data Sources Blueprints (including total entity count per blueprint) Self-Service Actions Automations Scorecards Pages (Entity, Dashboard, Run-History, etc.) Explore Relationships: discover and navigate relationships between: Blueprints and their associated Scorecards Blueprints and their linked Data Sources Blueprints and their Self-Service Actions Blueprints and related Automations Pages and their content sources Use Advanced Filtering: Filter and search Port objects based on various criteria, such as: Blueprints and their properties (e.g., entity count, creation date, last modified) Associated components (e.g., specific Scorecards, Data Sources, or Automations) Usage metrics (e.g., most/least used Blueprints or Self-Service Actions) Create Custom Dashboards: Build and customize dashboards using widgets that display: Object counts and distributions over time Relationships Usage trends over time (for example, blueprints without score-cards) Set Up Alerts: Configure automations based on changes in metadata or specific thresholds, such as: Significant changes in entity counts for a Blueprint New or modified relationships between objects Usage spikes for specific Self-Service Actions Perform Analysis: Utilize built-in tools and widgets to: Identify underutilized or overutilized components Spot trends in Blueprint usage and growth Evaluate the impact of changes to Port configurations Expected Outcome: As an admin, I will have a comprehensive, data-driven view of our Port implementation directly within Port itself. This will enable me to make informed decisions about our configuration, identify areas for optimization, and quickly troubleshoot issues by leveraging the relationships and metrics available in the self-monitoring system. Implementation Note: The system will ingest all relevant data into Port, allowing for the filtering, association-based insights, and capabilities described above. The existing Port infrastructure will be used to store and process this meta-information, treating it as just another set of blueprints and entities within the system.

Add native support for private_key_jwt client authentication in Ocean custom integrations/custom auth framework

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.

Today in Ocean integrations hosted by port, the default behaviour is to replace the hostname in the outgoing HTTP request to the data source with the resolved IP for this hostname. This is causing issues with some data sources that block such requests. As a WA we are using a static list of domains which are not replaced by the IP when sending out the HTTP request. This means that we are getting tickets from customers to add domain to this list and need to publish a new version for each such change. We want to change this so that this will not happen and we will not replace the hostname with the resolved IP.

We need to export from API endpoint, but the API endpoint support mainly query_parameter instead of path_parameter. We need for example to do https://example.com/api/test?project={project} where {project} is fetch by a previous call We want to be able to read the {project} from another endpoint, the same that can be done with path_parameters.