Feature ideas

Port announcement banners currently stay visible until someone manually removes them, with no way to set how long they are shown. Platform banners should be able to expire automatically, for example after two weeks, without requiring manual cleanup. An optional end date or duration setting would let banners retire on their own and keep the interface current.

Port’s BYO LLM support does not currently include Alibaba Qwen models. Adding Qwen would give users more choice among model providers and support teams that use Alibaba Cloud. A native Qwen integration would let the catalog track Qwen usage, licensing, and adoption alongside other providers. Broader provider support also helps users keep pace as model capabilities continue to expand.

The public audit log endpoints only cover write operations such as create, update and delete. They do not show READ operation, for example who viewed or fetched an entity, blueprint, page or other resource. Please include READ operations, such as GET and query requests in the audit logs.

Port’s incremental syncs currently run no more often than every 15 minutes, so changes in source systems can take up to a quarter hour to appear in the catalog. Teams that rely on Port as a near-real-time source of truth, especially during incidents and deployments, need fresher data. Live events are not an option for us, and an organizational constraint currently prevents us from using webhooks, so polling at shorter intervals is the practical path for now. We propose allowing sub-15-minute intervals (for example, 5 minutes) per integration

Currently after clicking execute on a self service action the page stays where you were. I find myself nearly always clicking on the link to take me to the run page. I personally would like to always be taken to the run page after clicking execute

Some data models include blueprints such as CI/CD jobs or deployments. These blueprints usually get filled with high number of entities, but the entities in these blueprints become stale and lose relevancy very quickly. With this feature, users will be able to configure custom retention for specific blueprints, giving them the option to automatically delete old entities once the number of entities for the blueprint passes X entities, or if an entity was updated more than 1 week/month/year ago

Request to move the Port Slack app to Slack’s newer agent messaging layout, where app conversations show up in the regular Messages tab. The app currently uses the older assistant layout, which has separate Chat and History tabs. Every DM the app starts goes to History, including approver requests for WFs. As a result, approvers miss approval requests by default, and Slack plans to phase out the older layout anyway.

Add a central list or view of all aggregation and calculation property errors, either for a single blueprint or across the whole data model, so users can find and fix them proactively instead of checking each property individually. Keep the request simple and general, with no customer, user, or organization names and no links.

Users can generate personal API credentials (a client ID and secret) from the Credentials section. The access tokens they produce last about 3 hours, but the client secret has no documented expiry. A leaked or forgotten secret can keep minting new tokens indefinitely, and it keeps working after a session ends, outside the controls on UI sign-in (session limit, inactivity timeout, MFA). Request: Let users set an expiry date when creating personal credentials, with sensible presets (for example 7, 30, 90 days) and a maximum. Expired credentials stop working automatically. Show the creation date, expiry date and last-used date to the owner. Notify the owner (email or webhook) before expiry. Allow renewal without losing the credential's identity or history. Why it matters: most enterprise security policies require credentials to have a bounded lifetime. Today the only way to bound a personal secret is manual rotation, which depends on each user remembering.

Customers want to build server-side apps that call Port MCP ( https://mcp.port.io/v1 ) on behalf of individual users, with each call running under that user's own Port identity and permissions. Today the only way to do this is the authorization_code flow, which means every user has to link their Port account separately. These customers already sign in to their apps and to Port with an external IdP (e.g. Microsoft Entra ID SSO), so they want a single sign-in to cover both their app and Port. Request: Add the urn:ietf:params:oauth:grant-type:token-exchange grant (RFC 8693) to https://mcp.port.io/v1/token (and the US equivalent, mcp.us.port.io ). The client would send an access token issued by a trusted external IdP (e.g. Entra ID) as the subject_token and get back a Port access token for the matching Port user. Admins would need a way to configure which issuers they trust, the expected audience or scope, and which client registrations are allowed to exchange tokens. Current behavior: The token endpoint metadata (/.well-known/oauth-authorization-server) lists only authorization_code, refresh_token and client_credentials. client_credentials doesn't fit this use case, because it is a machine identity with no per-user permissions. Related: There is an existing roadmap idea for token exchange on the Port API: https://roadmap.getport.io/admin/board/ideas/p/token-exchange-mechanism-for-api-authentication This request is specifically about the MCP server. Customer: Abu Dhabi Investment Authority (ADIA), org_jRQbsFhFMow9ywPM, EU Zendesk: https://getport.zendesk.com/agent/tickets/12235