Connections and data

A connection is a configured link from your organization to one of your own systems: a document library, a database, a warehouse, an HTTP API, or an MCP server. Nexio uses connections to read your documents and records, turn them into typed, cited data, and serve that data to your engines, your applications and your storage. Nexio does not sync data back to the systems you connect. One caution: an HTTP API connection’s validation probe sends the test request you configure, with the method you choose, so configure a request that changes nothing (a GET or HEAD). The only thing Nexio writes on your side is a managed delivery, to a separate storage location you provide.

Who does what

The system and its data stay yours: you supply credentials and scope, and Nexio operates the connection for you. Nexio configures the connection, validates it, runs indexing and extraction, reviews what needs a human eye, and monitors freshness. You see the results through four outputs:

Output	What you get	Where it is documented
Served records	Typed records extracted from your documents, each with citations back to the source page, read through the API	Served data
Engine runs	Engines read connected data as their candidates or context	Engines overview
Delivered files	Versioned tables written to your storage on a schedule	Transformation and delivery
Review outcomes	A verification label on each delivered row, and run review in the portal	Review

The connection pages in the portal are operated by Nexio. There is no public API for creating, configuring or indexing a connection. The public API reads what a connection produces: served data for documents, and Records for a system of record in a warehouse.

How it works

You hand Nexio the credentials and the scope for one system (for example a Microsoft Entra app registration and the SharePoint folders to read). Connector types lists exactly what each type needs.
Nexio creates the connection. It starts in PENDING.
Nexio runs a live validation probe against your system. For Snowflake, HTTP API and MCP connections, a passing probe also stores a short, non-secret summary of what it found.
A passing probe activates the connection. It moves to ACTIVE. A failing probe leaves it in, or returns it to, PENDING with the failure message.
The connection is used according to its binding shape (below). A document library is replicated, indexed and extracted; a database or warehouse is queried in place.
Results reach you through the outputs in the table above.

Binding shapes

A binding shape says how the platform uses a connection at run time.

Binding shape	What happens	Connection types
`materialize`	Nexio replicates the source, transcribes each document, extracts typed facts with evidence, and projects them into served records	`materialize` (SharePoint document library), `blob_corpus`
`pointer`	Nexio queries the live store in place	`postgres`, `snowflake`
`call`	Nexio calls the system per subject at run time	`api`, `mcp_server`, `http_enrichment`

Connection types

The set of connection types is fixed in code. It has seven values, and a new type is added only in a Nexio release. Five of them can be created as connections for your organization:

Type (`connection_type`)	Portal label	Binding shape	Status
`materialize`	SharePoint	`materialize`	Available today. Can feed an engine as its candidate data.
`postgres`	PostgreSQL	`pointer`	Available today. Can feed an engine as its candidate data.
`snowflake`	Snowflake	`pointer`	Available today for Records, which reads a system of record replicated into your warehouse. Built, not yet enabled as an engine’s candidate data.
`api`	Generic API	`call`	Built, not yet enabled: can be created and validated; no engine reads it at run time yet.
`mcp_server`	MCP Server	`call`	Built, not yet enabled: can be created and validated; no engine reads it at run time yet.

The other two values are not created for a customer. blob_corpus is a retired alias of materialize and is treated the same way. http_enrichment names the enrichment providers that Nexio calls itself during a run, with credentials Nexio holds; you configure nothing for them.

Connection status

Status	Meaning	What happens next
`PENDING`	Created and not yet validated, or its last validation failed, or it was replaced (below). A failed or replaced connection carries a status message.	Nexio fixes the credentials or scope and validates again.
`ACTIVE`	Validated and in use.	Document library connections are swept every hour. See Sync health.

An organization has one active PostgreSQL or SharePoint connection at a time: activating one moves the previously active one of those two types back to PENDING with the message “Superseded by newer active connection”. Deleting a connection is a soft delete. Its history is kept.

What a document connection produces

What a document library connection extracts is decided by its indexing profile: which document classes it recognizes, which extraction pass reads each class, and which record families those passes serve. Nexio ships one built-in profile. The pipeline, the served-record model, the review model and the delivery format described in this section are the same for any profile.

One-way by design

Data flows one way, from your systems to Nexio. Write-back is not built. The exception to watch is the HTTP API connection’s validation probe: it executes the test request as configured, and the method may be GET, HEAD, POST, PUT, PATCH or DELETE. Nexio does not stop a mutating test request, so configure one that changes nothing. Separately, edits to system-of-record fields that Records once held in Nexio for a later write-back are retired: those routes now answer 403 overlay_read_only. See Writes and the action ledger.
SharePoint access is read-only and enforced in code: the platform issues only GET requests to Microsoft Graph (the one POST is the OAuth token exchange with the Microsoft identity endpoint), the Entra app needs only read permissions, and a CI gate fails any change that sends a non-GET request to Microsoft Graph.
Secret fields are encrypted with AES-256-GCM before they are stored. A PostgreSQL connection URL is encrypted whole.
Every PostgreSQL, Snowflake, HTTP API and MCP address you supply passes a network guard that refuses private, loopback, link-local and cloud metadata addresses before Nexio connects. See Connector types.

Connector types

What to hand over for each system.

Indexing and extraction

What happens to a document after it is read.

Served data

Read extracted records and their citations through the API.

Transformation and delivery

Receive versioned tables in your storage.

Start here

Engines

Conversations