Feature ideas

The Azure DevOps Ocean integration's file kind does not support Project Wikis. It only works with Code Wikis (git-backed markdown files). Our organization uses Azure DevOps Project Wikis (pages stored in Azure's wiki system, accessed via Wiki API). The integration's file kind uses the Git Items API (/git/repositories/{repo}/items), which returns 0 files for Project Wikis. We want to add a dedicated wiki kind that uses Azure DevOps Wiki API (/wiki/wikis/{wikiIdentifier}/pages) to ingest Project Wiki pages as Port entities.

We need mapping support for parent/child resource blocks, where a child block can reference data derived from its parent block and run within the parent’s scope. Use case: GitLab skills stored in nested folders. Today, we can discover skill roots from SKILL.md , for example: .cursor/skills/coding-reviewing/topics/postgres-patterns/ SKILL.md From this, mapping can identify the skill as postgres-patterns. However, when syncing child files like: .cursor/skills/coding-reviewing/topics/postgres-patterns/references/ query-patterns.md the child file mapping only receives the file path. It cannot reliably infer which ancestor folder is the skill root, because nesting depth is non-deterministic. A parent/child mapping model would allow: Parent block discovers the skill root from SKILL.md Parent computes values like skillName, skillRootPath, skillVersionId Child block scans files under that parent root Child mappings can reference parent context when creating identifiers, properties, and relations This would allow correct modeling of nested resources without adding integration-specific logic to GitLab or any other data source.

Enable users to roll back an integration's mapping to its previous version in one click. When a mapping change causes issues, whether the new mapping is wrong or the resulting data in the portal no longer reflects what the user wants, they currently have to manually track down and reverse each change to get back to a working state. Instead, they can select roll back and the previous mapping is restored and reapplied using the existing apply mapping mechanism, re-syncing the data to the last known good state with no need to track or undo the changes manually.

Today we expose plugins built by Port — browse and install them from the Plugins Library. A marketplace would take this further: a place where teams can discover and install plugins built by the wider community.

Using the custom ocean integration, we want to get jfrog repositories that require a query parameter to be populated as a nested Endpoint. This want to query https://jfrog-platform.eu.aws.rccad.net/artifactory/api/repositories?project={project} We want to have the ability to get the project from another endpoint just like we are doing on the nested endpoint path parameters.

Today when a request is to made to Port's API using a standard API call (meaning, not with an integration), the Port user info in Port just shows Rest API. As customer usage of Port increases, they are likely to have more than a single backend that makes requests to Port API to send information, and it would be helpful to tag the source of each of those requests so that they appear in the audit log in a clear manner. An alternative could be multiple Client ID and Secret pairs, which each can be tagged as a specific "app" with it's own label in the Port user info column

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.

Description: We need a supported, scalable way to export the Port knowledge graph (blueprints, entities, runbooks, and use cases) as embeddings-ready data to load into our own vector database (e.g., Postgres + pgvector). While Port AI's live query-time context is useful, we want to run advanced, low-latency RAG grounded in an embedded representation of our entire catalog. We would welcome either: A documented API/export mechanism that supports incremental/delta syncs so we can chunk and embed the graph into our own DB. A managed contract where we can point Port to our own vector database endpoint, allowing Port to manage the graph sync while we manage the storage.

Currently, the GitHub Ocean integration doesn't consume or act on custom_property webhook events, so these properties can only be updated by scheduled resyncs. We request support be added to the GitHub Ocean integration for custom_properties live events.