Install Jentic One Beta

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.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fport.io%2Fport-api" | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fport.io%2Fport-api" | 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.

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

Generate authentication tokens for API access

GET STARTED

Start building with Port API

Explore with Jentic One

View OpenAPI Document

Use Cases

Patterns agents use Port 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 Jentic?

What agents get from Jentic-routed access to this vendor.

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 isolation

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.

Intent-based discovery

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.

FAQs

Specific to using Port 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 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.

Port API

Name: Port API
Brand: Port API
Availability: InStock

Official vendor OpenAPI document · agent-readyDeveloper ToolsProject Managementbearer4 EndpointsREST

For Agents

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

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.

Jentic One on Github View OpenAPI Document

Connect the Port API to your agent

Capabilities

Start building with Port API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs

Port API