Data endpoints
Configure targets and read workspace data through installed capabilities
A data endpoint selects a target through a plugin capability installed in the key's workspace. Installation configuration holds connection details; the endpoint holds its name, role and target. Read and write endpoints use the matching capability class. The public API does not install that plugin for you.
Available actions
| Action | Scope and behavior |
|---|---|
| List/detail | endpoints:read; collection supports name, namespace, role and paging |
| Create/update/delete | endpoints:write; target contract is validated against the installed capability |
| Check/validate | Check configured access or validate endpoint configuration; inspect the returned validation result |
| Schema | endpoints:read and accountable actor; discover target fields through the installed capability |
| Records | data:read; bounded source read with filters and optional snapshot selector |
| Source write | Governed operation with data:write, grants, policy and supported transactional capability |
Restricted keys must also have workspace resource access. Endpoint deletion needs an accountable member and can be blocked by references. Creating an endpoint does not start ingestion or grant database permissions.
Read a bounded page
After installing a read plugin and creating a read endpoint, set the key and actual endpoint UUID:
curl --fail-with-body --get \
-H "Authorization: Bearer $SEMOGRAM_API_KEY" \
--data-urlencode 'limit=10' \
"https://platform.semogram.com/api/v1/data-endpoints/$SEMOGRAM_ENDPOINT_ID/records"The default record limit is 100; the handler enforces its record cap independently of list pagination. select accepts repeated or comma-separated fields. where and orderBy are URL-encoded JSON arrays matching the read contract. snapshotId or asOf select supported historical reads; connector support is required. Follow returned cursors with the same caller and read parameters.
The response contains data and read metadata, including row count and continuation/snapshot information when applicable. A schema or connection check cannot prove every record is readable.
Configure through the right interface
Use the Data Endpoints guides for complete plugin-specific installation, UI fields, assistant and MCP examples. For HTTP, use the collection/detail paths in the catalog; the target JSON must match the actual installed capability contract, not a generic database connection object. Governed writes covers the separate source-write operation flow.
Creation fields
POST the endpoint collection with the following fields and a matching installed capability. The server supplies workspaceId from the key.
| Field | Meaning |
|---|---|
| name, namespace | Required endpoint identity labels; letters, numbers, dots, underscores, hyphens and colons |
| role | Source, destination or ontology store role supported by the capability |
| pluginCapabilityInstallationId | UUID of the installed workspace capability |
| contractKind | Contract matching that capability and endpoint role |
| target | Nonempty selector object validated against the plugin's target schema |
| schemaHints | Optional primaryKey and columns arrays |
| freshness, ownerTeam | Optional descriptive labels |
| trustRank, description | Optional trust classification and explanation |
| accepts, emits | Input/output format declarations compatible with the capability |
For example, a Postgres table target is a selector for a schema/table, while an S3 target selects an object location. These must come from the installed plugin's contract; the target is not its host/password configuration. Endpoint detail PATCH accepts changed endpoint fields and revalidates the target. Creation returns {dataEndpoint} with its UUID and persisted configuration.