Overview
Ingestion is how data reaches your Context Lake. You can ingest data using native integrations, MCP connectors, APIs, webhooks, and custom integrations.
This page helps you choose the right ingestion method. For a conceptual explanation of the Context Lake, see Context Lake overview.
How to choose an ingestion method
Use these guidelines as a starting point:
- Choose a native integration when the source system is a clear source of truth (for example, GitHub repositories, PagerDuty services, Kubernetes workloads), and you want continuous sync.
- Choose an MCP connector when you want Port AI and agents to query external tools at runtime (for example, Notion, Linear, Slack), without ingesting all data into the catalog.
- Choose ingestion via API when you already have a system that can push structured data to Port, or when you need precise control over updates.
- Choose ingestion via webhooks when you want event-driven updates from your systems, or when your source can emit events but does not have a suitable integration.
- Choose a custom integration when you need a reusable ingestion component for a tool that Port does not support with a native integration yet.
Entities
An entity is an instance of a blueprint. It represents a real resource in your organization - a service, a deployment, a team, or any other concept you model in Port.
Regardless of how you ingest data - through a native integration, webhook, API, or custom integration - the result is always entities in your catalog. Each ingestion method maps source data to entities according to the blueprints you define and the mapping you configure.
For example, this catalog page in Port's live demo displays all AI agents that have been created in the demo organization, each represented as an entity.
Clicking on an entity in the table will take you to its entity page, where you can view its properties, relations, and more.
Entity structure
By default, each entity has the following meta-properties: identifier, title, team. See the table below for more details.
JSON structure
{
"identifier": "unique-ID",
"title": "Title",
"team": [],
"blueprint": "blueprintName",
"properties": {
"property1": "",
"property2": ""
},
"relations": {}
}
Structure table
| Field | Type | Description |
|---|---|---|
identifier | String | Unique identifier. (Maximum 1000 characters) Note that while the identifier is unique, it can be changed after creation. |
title | String | Entity name that will be shown in the UI. |
team | Array | Optional Field. An array of the associated teams. |
blueprint | String | The name of the blueprint that this entity is based on. |
properties | Object | An object containing key-value pairs, where each key is a property as defined in the blueprint definition, and each value matches the type of the property. |
relations | object | An object containing key-value pairs. Each key is the identifier of the relation that is defined on the blueprint. |