canonical: https://jentic.com/apis/port.io/port-api # Port API 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. ## For AI agents Manage internal developer portal software catalog including blueprints, entities, and service metadata for platform engineering. ## Scope 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. ## Capabilities - Create and manage blueprint definitions for services, environments, and infrastructure - Register entities in the software catalog with metadata and relationships - Query entities across blueprints with filtering and pagination - Update entity properties including ownership, tags, and custom attributes - Generate authentication tokens for API access - Link entities via relationships to model service dependencies and ownership - Bulk import entities from infrastructure and cloud provider APIs ## Use cases ### 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. Example prompt: 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. Example prompt: 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. Example prompt: 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. Example prompt: 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 | 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 | ## Key resources - **Blueprints** — Schema definitions for entity types in the catalog. - **Entities** — Instances of services, environments, and infrastructure. - **Authentication** — Access token generation for API requests. ## Why Jentic - **Setup:** Wiring Port by hand means learning its bearer auth, exchanging credentials for an access token, and choosing the right EU or US host yourself. Through Jentic you install once, import Port from the API Directory, store the credentials once, and your agent calls it. - **Permission scoping:** Port puts the blueprint and entity identifiers in the URL path (`/blueprints/{blueprint_identifier}/entities/{entity_identifier}`), so a rule can pin your agent to one blueprint: you choose the operations it may call, so writes like updating or overwriting entities are not included unless you add them. - **Credential handling:** Your Port credentials are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'register a microservice in the software catalog', and Jentic returns the matching Port operation with its blueprint and entity input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **GitHub v3 REST API** — GitHub's REST API for repos, issues, and actions — feed it into your Port developer portal to enrich service catalog data. - **PagerDuty API** — PagerDuty's incident and on-call API — pair it with Port to surface service health and escalation status in your developer portal. ## FAQ ### 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 securely stores API credentials, handles authentication, and allows agents to create entities, query the catalog, and update metadata with natural language instructions. ### Can I limit what my agent is allowed to do with the Port API? Yes. Jentic One is self-hosted by you, so your own rules decide which Port operations and credentials the agent may use. Because Port carries the blueprint and entity identifiers in the URL path, a rule can pin the agent to a single blueprint and to read-only work, letting it generate an access token and query entities while excluding writes such as creating, updating, or overwriting entities. You choose exactly which operations it calls, so anything you do not explicitly allow stays off limits.