Glossary
Port uses several proprietary terms that either carry specific meaning within Port or collide with common industry concepts. This page defines each term precisely to eliminate ambiguity.
Terms are listed alphabetically.
Access token
Port's own bearer token, used to authenticate requests to the Port API. Generate one with the "Generate API token" button in your profile credentials, or via POST /v1/auth/access_token. An access token is valid for 3 hours, after which you need to generate a new one. Not to be confused with a third-party access token - such as a GitHub, GitLab, or Jira API token - supplied when configuring an integration, or with the OAuth response_type=token implicit grant, which is an unrelated authorization flow.
AI agent
A Port-native AI agent that can query the software catalog, trigger self-service actions, and answer questions using Port as context. Distinct from generic AI agents - a Port AI agent has direct access to your catalog data model and organizational context.
Automation
An event-triggered workflow in Port that executes automatically when a catalog event occurs - for example, an entity was created, a property changed, or a timer expired. Distinct from a self-service action, which is triggered manually by a user.
Blueprint
Port's schema definition for a catalog type. A blueprint defines the structure (properties, relations) that all instances of that type share - for example, "Microservice", "Environment", or "Team". Not to be confused with an architecture blueprint or system design document. In Port, a blueprint is closer to a class definition in object-oriented programming.
Catalog auto-discovery
Port's ability to automatically detect and ingest resources from connected tools without requiring manual mapping configuration. When enabled, Port scans connected integrations and proposes or creates entities based on what it finds.
Connector
Two unrelated concepts share this word. An MCP connector is a routing configuration in Port's AI registry that exposes an external MCP server's tools to developers and AI agents through Port's governed MCP gateway. An SSO connector - such as the AD/LDAP connector - is unrelated: it's the bridge Auth0 uses to authenticate users against an external identity system like Active Directory. Not to be confused with an integration or a data source, which describe how catalog data is synced rather than how identity or tool access is routed.
Learn more about MCP connectors - learn more about the LDAP connector
Context Lake
Port's aggregation layer that collects catalog data, events, and metadata to provide AI agents and tools with rich organizational context. The Context Lake is what makes Port-connected AI agents aware of your specific infrastructure, services, and relationships.
Data source
The configuration object in Port that represents a connected integration and its sync settings. Each installed integration creates a data source entry in your portal, which controls how data is fetched and mapped into the catalog.
Entity
A catalog record - a concrete instance of a blueprint. If "Microservice" is a blueprint, then "payment-service" is an entity of that blueprint. Entities hold the actual data (property values, relation links) for each resource tracked in Port. Not to be confused with a generic ORM entity or domain entity in domain-driven design.
Environment
An ambiguous term with three meanings depending on context. It can be a property value or dedicated blueprint/entity type used to distinguish deployment stages (e.g., Production, Staging). It can also be a generic OS or CI/CD environment variable, unrelated to Port's data model. Finally, "your second Port environment" refers to an entirely separate Port organization/portal instance - for example, when migrating configuration between a staging and production Port account. Check the surrounding context to determine which meaning applies.
Execution agent
A self-hosted relay binary (port-agent) that lets self-service actions and workflow webhook nodes reach services inside a private network, without exposing a public endpoint. It has no AI capabilities and is unrelated to the AI agent feature - despite the shared word "agent," the execution agent only relays webhook calls over Kafka.
Integration
In Port, an integration is an Ocean-based connector that syncs data from a third-party tool (GitHub, Jira, AWS, Datadog, and others) into the software catalog. The term is specific to Port's integration layer and is not a generic synonym for any API connection.
Kind
The API object type that a mapping resource fetches from an integration - for example repository, pull-request, or issue. Defined as the kind field inside a resources block. Not to be confused with a Kubernetes manifest's own kind field (e.g., kind: Deployment), which frequently appears in the same guide when Port ingests Kubernetes resources.
Level
A tier within a scorecard (e.g., Basic, Bronze, Silver, Gold). An entity reaches a level when all rules defined for that level pass. Levels are ordered - an entity must satisfy lower levels before achieving higher ones.
Mapping
The JQ-based configuration within a data source that translates external tool data into Port entities. Mapping defines which data maps to which blueprint and what value each property receives.
MCP server
Port's implementation of the Model Context Protocol (MCP), which exposes catalog data and self-service actions to external AI tools such as Claude, Cursor, and GitHub Copilot. Connecting an AI tool to Port's MCP server gives it live access to your catalog and the ability to trigger actions on your behalf.
Meta-property
A reserved property such as $identifier, $title, $team, or $createdAt that exists on every entity by default, always prefixed with $. Meta-properties look like ordinary properties in mapping and rule syntax but are managed by Port rather than defined on the blueprint.
Ocean
Port's open-source integration framework used to build and run integrations that sync data from external tools into the software catalog. Ocean is Port-specific - it is not a general industry term. When Port documentation refers to "Ocean integrations", it means integrations built on this framework.
Ownership
The mechanism in Port for assigning a team as the responsible owner of an entity. Ownership is used to drive accountability, filter catalog views, and scope RBAC permissions - for example, restricting who can trigger actions on a given service.
Page
A customizable view within Port's portal. Pages can display catalog tables, dashboards, entity detail views, or embedded content. In Port, "page" refers specifically to a portal view, not a generic web page.
Plugin
Port's first-class object for a custom-built web UI - developed locally as a single HTML file and uploaded through the Port plugins CLI or Port MCP server - that powers custom widgets on dashboards and entity pages. Not to be confused with a third-party tool plugin referenced in integration guides, such as a Jenkins plugin or Backstage's TechDocs plugin, which has no relation to Port's plugin API.
Portal
Port's developer portal product - the web application at app.port.io where developers interact with the catalog, run self-service actions, and view scorecards. "Your portal" refers to your organization's Port instance.
Property
A field defined on a blueprint that holds data for each entity (e.g., language, repo_url, on_call_contact). Port supports many property types including strings, numbers, booleans, URLs, and various computed types.
Provider
An umbrella term with several unrelated meanings depending on the page. A Git provider (GitHub, GitLab, Bitbucket) is the source Port ingests repository and pull request data from. An LLM provider (OpenAI, Anthropic, AWS Bedrock) is the model backend configured for Port AI. A login/identity provider (Auth0) handles SSO authentication. The Terraform provider "port" {} block configures the Port Terraform provider itself. Check the surrounding context to determine which provider a page is referring to.
Learn more about LLM providers
RBAC
Role-based access control as implemented in Port. Port's RBAC model controls which users can view, create, edit, or delete entities and blueprints, and who can trigger self-service actions. Default roles include Admin and Member; teams can also be used to scope permissions.
Relation
A typed link between two blueprints that models dependencies or ownership in the catalog (e.g., a Microservice belongs to a Team, a Deployment references an Environment). Relations in Port are directional and defined at the blueprint level - not to be confused with a relational database foreign key.
Resource
Within a mapping configuration, a resource is a single block that specifies a kind to fetch and how to map it to a blueprint. Elsewhere in the docs, "resource" is also used generically to describe any infrastructure or cloud object (a Kubernetes cluster, an S3 bucket) tracked in the software catalog - this generic usage does not refer to the resources mapping key specifically.
Rule
A single condition within a scorecard level (e.g., "has_owner = true", "response_time < 200"). Rules evaluate entity property values and return pass or fail for each entity.
Run
A single execution of a workflow or self-service action, including its inputs, status, logs, and audit trail. Runs are stored in Port and can be inspected after the fact to understand what was triggered, by whom, and what the outcome was.
Scorecard
Port's mechanism for tracking compliance, quality, and maturity standards across catalog entities. A scorecard defines a set of levels and rules and evaluates each entity against them. Not a generic KPI dashboard - scorecards in Port are integrated directly with the catalog data model and update in real time as entity data changes.
Secret
Three distinct concepts share this word. A Port secret is an encrypted value stored in your organization's Secrets tab (under Credentials) and referenced by identifier in integrations and self-service actions. A Secret input is a self-service action input type that encrypts its value before sending it to your backend. A CI/CD secret - for example ${{ secrets.PORT_CLIENT_SECRET }} in a GitHub Actions workflow - is stored in your Git provider, unrelated to Port's own Secrets tab.
Self-service action
A user-triggered workflow in Port that lets developers perform predefined operations (provision resources, open tickets, deploy services) directly from the portal. Distinct from automations, which are triggered automatically by catalog events rather than by a user. Often shortened to "action" in Port documentation.
Skill
A reusable AI capability registered in Port that AI agents can invoke to perform specific tasks (e.g., deploy a service, open a pull request, query the catalog). Skills are defined once and can be called by any agent that has access to them.
Software catalog
The central registry in Port that contains all entities, organized by blueprints and linked by relations. The software catalog is the core of Port, giving teams a unified, queryable view of their infrastructure, services, and resources.
Team
A group of users in Port, used for ownership assignment and RBAC. Teams in Port are also first-class entities in the catalog (a built-in blueprint), meaning they can hold properties, participate in relations, and appear in catalog views.
Workflow
Port's orchestration feature (currently in Beta) for sequencing multiple steps - actions, conditions, loops - into a multi-step automated process. Not to be confused with CI/CD "workflows" such as GitHub Actions workflows - a Port Workflow is a higher-level orchestration construct within Port itself.