Port API

Name: Port API API
Brand: Port API
Availability: InStock

✓ Official Vendor SpecDeveloper ToolsInternal Toolsbearer4 EndpointsREST

For Agents

Manage internal developer portal software catalog including blueprints, entities, and service metadata for platform engineering.

Connect the Port API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Port API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Install Jentic One Beta (Self-Hosted)

Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Port API API.

Create and manage blueprint definitions for services, environments, and infrastructure

Query entities across blueprints with filtering and pagination

Update entity properties including ownership, tags, and custom attributes

GET STARTED

Start building with Port API API

Explore with Jentic

View OpenAPI Document

Use for: Register a new microservice in the software catalog, Find all services owned by a specific team, Update deployment status for a service entity, Get all entities for a blueprint type

Not supported: Provides software catalog management and entity registration for internal developer portals. Does not perform service deployments, infrastructure provisioning, or incident management—use CI/CD and cloud provider APIs for those operations.

Port is an internal developer portal that creates a software catalog for managing microservices, infrastructure, and developer resources. The Port API enables programmatic management of blueprint definitions, entity creation, and integration with CI/CD pipelines and cloud providers. Platform engineering teams use it to build a single pane of glass showing all services, their owners, dependencies, deployment status, and compliance posture. The API supports creating entities representing services, environments, and infrastructure components, linking them via relationships, and enriching them with metadata from observability tools, incident management systems, and cloud APIs. Port enables self-service operations where developers query the catalog via API to find service owners, trigger deployments, or provision infrastructure. The platform acts as a service registry, organizational chart for software, and automation hub for platform engineering workflows.

Use Cases

Patterns agents use Port API API for, with concrete tasks.

★ Software Catalog Management and Service Discovery

Platform engineering teams use Port to maintain a comprehensive catalog of all microservices, APIs, databases, and infrastructure components across the organization. The API enables automated registration of services detected from Kubernetes clusters, AWS accounts, and GitHub repositories. Each service entity includes metadata like owner team, tech stack, deployment environments, and SLA tier. Developers query the catalog API to discover services, find responsible teams for incidents, and understand dependency graphs before making changes. This replaces wiki-based service registries with machine-readable, always-current catalog data.

Query Port API for all service entities, filter by team ownership, retrieve metadata including deployment status and dependencies, generate service inventory report, identify services without defined owners for governance review.

CI/CD Integration and Deployment Tracking

DevOps teams integrate Port with CI/CD pipelines to track deployment status, environment promotions, and release metadata. The API receives webhooks from GitHub Actions, Jenkins, and ArgoCD to update service entities with latest deployment information. When a service deploys to production, the pipeline updates Port entities with version numbers, deployment timestamps, and commit SHAs. Platform dashboards query the API to show real-time deployment status across all environments. This provides organizational visibility into release velocity, change failure rates, and deployment lead times.

On successful production deployment, call Port API to update service entity with new version, deployment timestamp, deployer identity, and commit SHA. Query API to retrieve deployment history for generating release notes and change logs.

Self-Service Infrastructure Provisioning

Platform teams build self-service workflows where developers provision infrastructure by creating entities in Port, triggering automation that calls cloud provider APIs. When a developer creates a new database entity with required specifications, Port webhooks trigger Terraform workflows that provision RDS instances, configure security groups, and inject connection credentials into parameter stores. The API updates the entity with provisioned resource identifiers and connection details. This enables infrastructure-as-a-service patterns where developers self-serve without manual ops tickets.

Developer creates database entity via Port UI or API with specifications, Port webhook triggers Terraform automation, cloud resources are provisioned, Port API updates entity with RDS endpoint and credentials reference, developer receives notification with access details.

Compliance and Governance Reporting

Security and compliance teams use Port to track software catalog entities against governance policies. The API enables querying all services to identify those missing required metadata (owner, security contact, data classification), services deployed without required security configurations, or infrastructure non-compliant with tagging policies. Automated scanners periodically query Port entities, compare against policy rules, and generate compliance reports highlighting gaps. This provides audit evidence showing organizational coverage of security controls and policy enforcement.

Query Port API for all service entities, check each for required metadata fields (owner, security contact, SLA tier), identify services missing compliance attributes, check for required security integrations (APM, logging), generate compliance report with non-compliant services, assign remediation tasks to owners.

Key Endpoints

4 endpoints — port is an internal developer portal that creates a software catalog for managing microservices, infrastructure, and developer resources.

METHOD

PATH

DESCRIPTION

POST

/auth/access_token

Generate an access token for API authentication

POST

/blueprints/{blueprint_id}/entities

Create a new entity in the catalog

GET

/blueprints/{blueprint_id}/all-entities

Retrieve all entities for a blueprint type

PUT

/blueprints/{blueprint_identifier}/entities/{entity_identifier}

Update an existing entity

POST

/auth/access_token

Generate an access token for API authentication

POST

/blueprints/{blueprint_id}/entities

Create a new entity in the catalog

GET

/blueprints/{blueprint_id}/all-entities

Retrieve all entities for a blueprint type

PUT

/blueprints/{blueprint_identifier}/entities/{entity_identifier}

Update an existing entity

Why though Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

Port API credentials are encrypted in Jentic's vault with organization-level access. Agents execute catalog operations without accessing tokens, and all API calls are logged for audit trails.

Intent-based discovery

Agents search by intent like 'register a microservice in software catalog' and Jentic returns Port's entity creation operation with blueprint schema, avoiding documentation of property definitions and relationships.

Time to first call

Direct Port integration: 2-3 days to understand blueprint schemas, entity structures, and relationship modeling. Through Jentic: 1 hour—search for operations, create entities with natural language parameters, query catalog.

Related APIs

Alternatives and complements available in the Jentic catalogue.

Alternative

Backstage API

Backstage is Spotify's open-source developer portal with software catalog and plugin ecosystem.

Choose Backstage for self-hosted open-source developer portals with extensive plugin customization, or when Spotify's patterns match your organization structure.

Alternative

Cortex API

Cortex provides service catalog with scorecards, deployment tracking, and on-call integration.

Choose Cortex when you need service maturity scorecards, on-call management integration, or SLA tracking alongside your service catalog.

Alternative

OpsLevel API

OpsLevel offers service catalog with service ownership and maturity tracking for platform teams.

Choose OpsLevel for service ownership tracking, maturity rubrics, and integrations with incident management and on-call systems.

FAQs

Specific to using Port API API through Jentic.

What authentication does the Port API use?

The Port API uses Bearer token authentication. You generate access tokens using the /auth/access_token endpoint with your client credentials, then include the token in the Authorization header for subsequent requests.

What are blueprints in Port?

Blueprints are schema definitions that define entity types in your software catalog. For example, a 'Service' blueprint might have properties like owner, language, and repository URL. Entities are instances of blueprints representing actual services.

Can I automatically populate Port from cloud providers and Kubernetes?

Yes, Port provides integrations and the API enables bulk entity imports. You can query AWS APIs or Kubernetes clusters, transform the data into Port entity format, and use the API to register entities automatically, keeping the catalog synchronized.

How does Port handle entity relationships and dependencies?

Port entities support relationship properties that link to other entities. For example, a service entity can have a 'depends_on' relationship pointing to other services or databases. The API allows creating and querying these relationships to model dependency graphs.

How do AI agents use the Port API through Jentic?

Agents search Jentic for tasks like 'register a service in Port' and receive Port operation schemas. Jentic vaults API credentials, handles authentication, and allows agents to create entities, query the catalog, and update metadata with natural language instructions.