Setup guides

What you are setting up

A data endpoint is a named configuration in a workspace that selects data through an installed plugin capability. It can select a table, collection, object path, HTTP response or ontology store. Projects in the workspace reference that endpoint; they do not own separate copies.

The plugin implements the operation. Its installation holds connection settings and protected credentials. The endpoint selects a concrete target through that installation. Saving an endpoint configures access; it does not read records, write output or schedule a run.

Choose the direction

Choose the operation first, then install the matching capability. A plugin can bundle several capabilities, but each endpoint selects one. A database source and a database destination are separate endpoints even when they use the same server.

Iceberg also supports governed mutations of its source table through a separate transactional operation path. That is different from selecting a generic Egress writer. Uploading a dataset supplies a managed source; it is not a generic destination.

What you need

• A Semogram account with access to the workspace and permission to manage plugins and endpoints
• An external service or file you can access, including the privileges required for the chosen operation
• The plugin capability's connection configuration and target contract
• A small known fixture and a dedicated output target for write tests
• A project in the same workspace when verifying a pipeline or ontology binding

Creating an endpoint does not provision the external database, bucket, API or account, or grant external permissions. Enter credentials in protected installation settings, not in endpoint names or assistant prompts.

Choose a guide

Start with First endpoint for a complete Postgres walkthrough: install read and write capabilities, create two endpoints and copy a two-row fixture into a separate test table. All configuration and verification steps are on that page.

The Postgres and MongoDB guides explain differences between catalog-advertised target modes and implemented writer modes. Use the operation supported by both the installed contract and runtime; a target field cannot enable missing behavior.

For a connector your team builds, the custom scenarios cover a private API source and a custom destination. Their directions, target fields and retry behavior depend on the actual implementation. Transforms and Environment Variables do not expose standalone endpoints; their setup stays in Plugins.

Setup and verification flow

1. Install the capability. Select read, write or fact materializer; enter connection settings and protected credentials. Check the installation where supported.
2. Prepare the target. Identify the existing input or provision a dedicated test output/store with the required external privileges.
3. Create the endpoint. Choose its workspace name, namespace, direction, installed capability, contract and target. Names and namespaces are Semogram labels; schema/table names and paths identify external data.
4. Verify the operation. For reads, compare a bounded result with the known source fixture. For writes, execute a small pipeline and inspect the receiving system. For materialization, store known facts and query them back through an ontology binding.
5. Inspect before repeating. Check output, errors and run evidence. Partial writes and append retries can leave duplicates; a connection check does not prove successful execution.
6. Use the verified endpoint. Reference it from workspace projects. Review consumers before changing targets, capabilities or credentials, and verify real output before scheduling recurring runs.

Each connector guide includes installation settings, prerequisites, target configuration, a fixture and the appropriate verification procedure. Links provide additional detail; they are not a substitute for the setup steps on the guide itself.