Feature ideas

Currently OCEAN__METRICS__ENABLED and OCEAN__METRICS__WEBHOOK_URL can't be set on port hosted ocean integrations. This makes this guide: https://docs.port.io/guides/all/monitor-integrations/ not possible on such integrations. There should be an easy way to set this up in the UI. (Really what I want is automatic creation of an entity on each sync, perhaps there could be a simpler way to achieve this)

Port's ingestion webhooks currently authenticate incoming requests only via a static shared secret validated through HMAC signature checks. This leaves no way to issue short-lived, revocable credentials for webhook senders, which is a blocker for organizations with strict IAM policies against long-lived static secrets. Add support for validating an OAuth 2.0 access token (e.g. client_credentials grant) on inbound webhook requests, used alongside the existing HMAC check rather than replacing it. Without this, security-conscious customers can't onboard ingestion webhooks at all under their compliance requirements.

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.

Our custom plugin widget renders format: "markdown" properties, including text and code, but not images. Images uploaded via Port's markdown editor are stored on asset.us.port.io behind CloudFront signed URLs. The only way to get a signature is GET /v1/asset/download-signature, but its CORS allowlist doesn't include our plugin iframe origin ( https://us.portwidgets.io ), so the browser blocks the request.

We would like to import into Port all the Network Interfaces (AWS::EC2::NetworkInterface). We are especially interested in the public IP address of the network interface. Note that unfortunately it is not return via the CloudControlAPI from AWS but it is return via the AWS API. This will allow our cyber security team to have an inventory of all publicly facing network interface, and also our devop team to quickly identity in which account a resource is when they only get an ip address in a ticket.

Port's llms.txt is useful, but it can provide far more context than an agent needs for a specific task, which means unnecessary token usage. I would like Port's documentation to expose a lightweight, hierarchical index that lets LLMs progressively discover the right documentation instead of loading a large representation of the docs upfront. For example, an agent trying to understand GitHub mappings should be able to follow a path like: Docs → Integrations → GitHub → Mapping → Relevant documentation page Each level would only need enough information to help the model decide which branch to follow. For example, a root index could conceptually contain: { "sections": [ { "name": "Software Catalog", "description": "Blueprints, entities, relations and catalog modelling", "index": "..." }, { "name": "Self-service", "description": "Actions, workflows and developer self-service", "index": "..." }, { "name": "Integrations", "description": "GitHub, Jira, Kubernetes, cloud providers and other integrations", "index": "..." } ] } The Integrations index would then expose its children, and so on until the agent reaches the relevant page. This does not have to be JSON. JSON is only one possible implementation. The important part is providing a stable, machine-readable, hierarchical way for agents to understand: What documentation sections exist What each section/page is about What child topics exist underneath it Where to go next for a particular topic Which actual documentation page contains the detailed information Individual pages could also expose short intent hints such as: Use this page for: - Creating GitHub resource mappings - Mapping repositories into Port entities - Configuring JQ mappings This would help an agent distinguish between similarly named sections without reading the full page. The goal is progressive context loading. Instead of: Agent → load llms.txt → receive a large amount of documentation context → search through it the agent could do: Agent → load small docs index → select Integrations → select GitHub → select Mapping → load only the relevant documentation This would reduce token usage, reduce irrelevant context, and make Port's documentation easier for coding agents and long-running AI workflows to navigate. I think this becomes especially useful for tasks like: > "Build this portal using Port." An agent working on that task may need to consult the documentation repeatedly. Giving it a small semantic tree to navigate would be much more efficient than repeatedly loading broad documentation context. llms.txt can still remain as the broad-context option. This would complement it with a more token-efficient discovery mechanism.

Problem Statement Currently, Port dashboards require users to manually configure filters with exact property names and values. This creates several challenges: - Users must understand the underlying data model to create effective filters - No support for filtering by common properties that exist across multiple blueprints - Technical workflow not accessible to non-technical stakeholders (managers, executives, product owners) - Each dashboard requires manual filter setup, reducing reusability Use Case As a dashboard consumer (engineering manager, product owner, executive), I want to easily filter dashboard views using simple drop-down selections, so that I can view relevant metrics without needing to understand property names, data models, or filter mechanics. Example Scenario: A DORA metrics dashboard displays data from multiple blueprint types (repositories, deployments, services, incidents). Users want to filter the entire dashboard by a common organizational dimension (product line, team, business unit) that appears across all these blueprints. Current Limitations - Manual filter addition required for each dashboard - Users must know exact property names (e.g., "product", "team", "owner") - Cannot create filters that work across multiple blueprint types - "Contains" property provides only partial workaround - Poor user experience for business stakeholders Desired Solution - Dashboard-level filters with pre-configured drop-down lists - Single-click filtering that applies across all widgets in the dashboard - Cross-blueprint filtering - filter by common properties across different entity types - No technical knowledge required - intuitive UI for filter selection - Reusable filter configurations that can be templated across multiple dashboards Expected Benefits 1. Improved UX - Business stakeholders can self-serve analytics without technical assistance 2. Faster insights - One-click filtering vs. manual configuration 3. Better adoption - Dashboards accessible to broader audience 4. Consistency - Standardized filtering experience across organization 5. Reduced support burden - Less hand-holding required for dashboard consumers Technical Considerations - Port currently cannot filter by common properties across different blueprints - This affects any dashboard showing data from multiple entity types, or a single entity type - Workarounds exist but compromise user experience - Feature would enhance Port's value proposition for executive reporting and cross-functional analytics

Currently, system icons cannot be customized. Allowing users to customize system icons would be a helpful.

What I'm trying to do Render the distribution of answers to a Likert-scale survey question as a bar chart — one bar per point on the scale, in scale order (for example "Never / Rarely / Sometimes / Often / Always"). The bars are produced by grouping entities on a relation, and the target blueprint carries an explicit display_order number property giving the intended position of each option. What happens instead bar-chart always orders its bars by value, largest first. There appears to be no way to override this: the widget schema exposes type , title , blueprint , property , dataset , emptyStateText , icon , description and segmentTableViewConfig , and the sortSettings available inside segmentTableViewConfig configures a table view rather than the chart axis. Why size-ordering is a problem for ordinal data For a categorical breakdown, sorting by size is a sensible default — it puts the biggest category first. For an ordinal scale it removes the only information the chart shape carries, because the result is a descending staircase regardless of the underlying data: | Underlying distribution | Counts in scale order | Rendered | | --- | --- | --- | | Polarised — people at both extremes | 5, 1, 0, 1, 5 | 5, 5, 1, 1, 0 | | Converged — people clustered in the middle | 1, 2, 6, 2, 1 | 6, 2, 2, 1, 1 | Both render identically in shape. Worse, the polarised case puts its two opposite extremes side by side as the two tallest bars, which reads as a consensus cluster — the opposite of what the data says. Telling these two cases apart is usually the entire reason for charting a distribution rather than reporting a mean. What I'd like Any one of these would solve it: an explicit sort option on the widget, e.g. sortBy accepting a property of the grouped-by entity (such as display_order ) with asc / desc an option to preserve the natural order of the grouped-by entities rather than sorting by value the ability to supply an explicit ordered list of group keys, with bars rendered in that order The first is the most useful, since the ordering property already exists on the blueprint. Workaround in use table-entities-explorer , grouped by the same relation and sorted on display_order ascending. It gives correct scale order and the group headers carry the counts, so the data is right — but it is a table where a chart belongs, on a dashboard that is otherwise all charts, and it loses the at-a-glance shape that made a chart worth having.

Now Ocean integrations can run with service accounts, but they still require Admin role. We need the ability to scope the permissions for the ocean integration service account to read/register/update/delete only certain blueprints.