Feature ideas

We often want to be able to display fields that contain large blocks of text that aren't necessarily markdown (Summaries, descriptions, code blocks, etc). We'd like to be able to select these fields as the source for the markdown widget without having to change the data type of the field to prevent rendering oddities for plain text content. This would change the markdown widget to more of a textbox widget that supports markdown rendering as an option

Currently, port do not support dynamically re-reading secrets attached to Ocean custom integration. This is already supported in Other Ocean integrations in the following way: Ocean has a built-in mechanism: when this parameter is set, any 401 received from the third-party API triggers Ocean to re-read the token from that file and retry the request - assuming the token has already been refreshed and rewritten there. This allows us to assign external secret and the Ocean integration will use it correctly when rotated outside of the integration. Port should extend this to Ocean Custom integration to work the same way to allow for short lived tokens needed in some APIs.

Similar to the request for Gradle files, it would be valuable to parse go.mod files for dependencies and making scorecards for that.

Allow MCP to differentiate and choose between multiple organizations that share the same endpoint, without forcing users to log out each time.

The Applications API provides a critical capability within Checkmarx by enabling the logical grouping of multiple Checkmarx projects under a unified application construct. This functionality is fully documented in the official reference guide: https://checkmarx.stoplight.io/docs/checkmarx-one-api-reference-guide/branches/main/szojm2v0j748d-applications-service-rest-api Integrating the Applications API into our Checkmarx consumption model is essential for establishing coherent and maintainable context across repositories, workloads, and services. By leveraging this API, we can accurately correlate security findings to the broader application ecosystem, eliminate fragmentation across project-level scans, and ensure that governance, reporting, and compliance activities are performed against a single, authoritative application boundary. Adopting this improves traceability and operational clarity, as well as also strengthens Port's ability to manage risk holistically across the software development lifecycle.

On the homepage, provide the ability to create a list of favorite entities for convenient navigation.

Port’s current Jira integration supports syncing Projects, Issues, Users, and Teams, but does not support additional Jira Agile entities such as Sprints, Boards, Epics, Worklogs, Backlog items, Versions, or other objects available through the Jira Cloud Agile REST API. These objects are essential for richer engineering insights, cross-team reporting, and end-to-end service catalog modeling. Adding support for these Jira resource types would unlock significantly more powerful catalog and automation use cases for Port customers. Primary targets: Sprint Board Epic (as its own blueprint) Worklog Version / Release Nice to have: Backlog containers Components Iterations for Jira Advanced Roadmaps Technical expectations Read support through the Jira Cloud Agile REST API Ability to map fields using Port’s mapping layer (JQ) Relations: Sprint → Issues Board → Sprints Epic → Issues Version → Deployments / Releases / Services Additionally: live events for sprint changes (start/end), board updates, and linked issues.

Letting you add any icon you want into the organization's private icons library

In order to improve adoption, key point is around branding, being able to use port ( even saas ) via a custom domain like port.mydomain.com , or dev-portal.mydomain.com can help tremendously on internal adoption

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"]