Data endpoints and installations
Understand the difference between plugin installations and data endpoints, how reads and writes execute, and why connecting a source does not schedule ingestion.
What an endpoint does
An endpoint selects a specific external target and exposes it under a name in the workspace. The plugin installation provides the connection and implementation used to access that target.
Plugin used
The target determines the plugin: a database table uses a database connector, an object path uses storage, and an ontology store uses a fact-store capability. Plugin setup guides provide additional installation details; endpoint examples also include those steps inline.
What you need
Use an installation in the endpoint's workspace and select its matching read, write or store capability. Know which target it should access and verify external permissions. Keep credentials on the installation and target selectors on the endpoint.
A plugin installation configures a plugin and its capabilities. A data endpoint names the concrete target that a workflow or query uses. One connection can support many endpoints; one plugin can bundle multiple capabilities. Both installations and endpoints are workspace-scoped; projects reference them when executing pipelines or binding ontology data.
The Plugins section includes plugin management and a separate MCP Servers page. Plugins can provide reads, writes, fact stores, transforms, secret providers, and skills. MCP servers provide external tools; connecting an assistant to Semogram's own MCP server is a separate inbound connection
Installation and connection checks do not start ingestion. Reads occur through workflows and queries. Recurring ingestion needs a pipeline schedule. Full and incremental reads depend on connector support; run telemetry and checkpoints show what actually happened
Keep credentials in plugin installation configuration or supported secret references Plans should use references instead of copied credentials. Treat configuration, exports, and shared screenshots as sensitive and verify redaction rather than assuming a manifest flag guarantees secrecy everywhere
Writes depend on connector capabilities, approved policies, actor permissions, and any separately required action approval. A connection check is not a test write or a rollback guarantee
See Connect data and Data endpoints
Example: one connection, two endpoints
A database connection can expose both an orders table and a supplier table The installation holds the connection configuration; each endpoint names one usable target. A pipeline reading orders references the orders endpoint, not an unqualified promise to read everything in the database
If the supplier table changes, check its endpoint and consumers. Reinstalling the connection is a different action from changing a table selector or rerunning an ingestion pipeline