Feature ideas

Right now there is a 300 character count limit for the URL input when configuring an Organization Announcement. Many links are longer than 300 characters, and there should be no limit - or a far higher one.

This feature will make it possible to make a request to the access_token endpoint with a special flag, when a request with the flag is received, a new token will be generated (with a new TTL of 3 hours) even if an existing token is still valid

When an SSO connection secret expires, show a more informative and user-friendly error message instead of a generic “Something went wrong, please contact Port support.” The message should clearly explain that the issue is related to an expired SSO secret and guide the user to renew or reconfigure it. This will help users resolve authentication issues faster and reduce dependency on support for simple maintenance tasks.

Currently, users cannot be added to an existing SSO-managed teams in Port until they log in, even if they already belong to the team in the SSO provider. This creates a gap where team assignments aren’t visible in Port until the first login, preventing admins from ensuring that team data is complete before users start using Port.

Currently, the webhook secret and organization url dropdowns in the settings tab of data exporters are sorted nondeterministically. We request the secrets/URLs be ordered alphabetically to improve user experience when searching the dropdowns.

Currently service accounts must use the email domain serviceaccounts.getport.io . We would like the ability to create service accounts with our own email domain.

As we are implementing Port, we want to embed URLs with videos that are secured through AWS/S3 via Okta. Currently it is very complex to get the video authentication set up and would like an easier way to set up the authentication directly with AWS.

As we are implementing Port, we want to embed URLs with videos that are secured through AWS/S3 via Okta. When we click on the video it opens up in another tab and the authentication mechanism does not work. When seen within the entity it authenticates and the video works. We would like embedded links to either authenticate when opening in another tab or redirect to the entity tab where the embedded link is for ease of use.

Port's API is critical for us and is used in the CI pipelines. We would want to have a dedicated API token for these flows that does not interact with the general rate limits from Port and has it's own rate limits even if they are reduced. More details about the question: would be great to isolate the critical system features (e.g. CI) using the API from influence of other components, which are not under our control - like other users and integrations. That probably would mean having separate limit buckets. E.g.: We could use a dedicated service account for the CI calls - maybe it could have a separate bucket and not sharing with the integrations? Probably the biggest question - non-admin users. I'd really like to limit how non-admin users can influence the rest of the system (in general too ofc, but in terms of API consumption for this context). So it'd be totally OK if personal tokens had much tighter limits, but not influence the common bucket.

Add the ability to hide the password field value in the Kafka tab of the UI. Currently, the password displays in plain text, and users would like it to be masked for security reasons, similar to how client secret is handled after using the REMOVE_SECRETS feature flag