Feature ideas

Currently, the GitHub Ocean integration doesn't consume or act on custom_property webhook events, so these properties can only be updated by scheduled resyncs. We request support be added to the GitHub Ocean integration for custom_properties live events.

To properly populate our catalogue we need to ingest users from the Identities API instead of the usernetitlements API

We have 100+ datadog organizations, we need a way to ingest from datadog in less integrations

Background When an Ocean integration starts up, it reads its mapping from .port/resources/port-app-config.yml and applies it to the integration config stored in Port. However, this only happens in two narrow cases: when the integration is being created for the first time, or when it exists but has never been initialized (empty config). In both cases, patch_integration() is called with the port_app_config payload. Once the integration is fully initialized, Port sets arePortResourcesInitialized = true on the integration record. From that point on, every subsequent restart hits an early-return guard in BaseSetup.setup() and skips the entire setup phase. Only metadata fields ( changelogDestination , version , actionsProcessingEnabled , processingMode ) are ever updated via _verify_integration_configuration() - the mapping is never touched. This is intentional: it protects mappings that users may have edited manually in the Port UI from being overwritten on redeploy. Problem The protection has no opt-out, which creates a real friction point for integration developers who manage their mapping in code and expect port-app-config.yml to be the source of truth. In practice this means: Updating the mapping in port-app-config.yml and redeploying silently has no effect - the old mapping keeps running. Running a new version of an integration alongside an outdated mapping is not immediately obvious and can produce confusing behavior. Developers are forced to manually clear or reset the mapping in the Port UI to pick up changes, breaking the "ship code + mapping together" workflow. Proposed Solution Introduce an opt-in configuration flag (e.g. overwrite_config_on_restart , analogous to the k8s-exporter's overwrite-configuration-on-restart ) in IntegrationConfiguration. When enabled: The arePortResourcesInitialized guard in BaseSetup.setup() should not short-circuit. _verify_integration_configuration() (or the setup flow) should call patch_integration(port_app_config=...) with the mapping loaded from port-app-config.yml . The flag should default to false so existing behavior is fully preserved for production deployments where users manage their mappings in the UI. Notes This mirrors a pattern already established in the k8s-exporter ( overwrite-configuration-on-restart ), so there's prior art in the product for this kind of escape hatch. The fix is low-risk when scoped correctly, the default-off behavior means no existing integration is affected unless the flag is explicitly set. A follow-up consideration: whether to expose this flag via an env var, a Helm value, or both, to cover different deployment models.

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.

Today when a request is to made to Port's API using a standard API call (meaning, not with an integration), the Port user info in Port just shows Rest API. As customer usage of Port increases, they are likely to have more than a single backend that makes requests to Port API to send information, and it would be helpful to tag the source of each of those requests so that they appear in the audit log in a clear manner. An alternative could be multiple Client ID and Secret pairs, which each can be tagged as a specific "app" with it's own label in the Port user info column

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

Admins should be able to leave comments in the data source mapping.

Currently, when you want to deploy a new self-hosted integration, the organization's client ID and client secret are used by default. So, if the client ID and client secret are leaked or need to be changed, you must change the client ID and client secret for all integrations that you host yourself A better way would be to generate a new service account for a new integration, so you have only one key to manage per integration This is in line with the principle of least privilege and allows for easy, secure management of dedicated service accounts

Currently, the GitHub integration can't be set up with multiple instances, which means that only one instance is owning all entities. This becomes problematic when you want to have two kinds populate the same entities. The reason for that, is the query field can result in an entity being deleted from the "enriching kind" rather than the "owning kind". Suggestion: Add to entities created by the GitHub app a new type of ownership, based on the mapping kind. This will allow only specific kinds to delete entities from the catalog, while allowing other kinds to safely "enrich" the entities.