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.

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

When using the Execution Agent, I would like to just set "enabled: false" in the 'control_the_payload_config.json' file and make it completely transparent. I mean for it to just forward whatever payload it receives: headers, body, etc. Thank you.

Currently, when multiple port.yaml files update the same entity, the relations array gets overwritten by the latest update, and any existing relations are lost. It would be helpful if relations from all port.yaml files can be aggregated to maintain a comprehensive list of relationships across projects.