> ## Documentation Index > Fetch the complete documentation index at: https://docs.usenexio.com/llms.txt > Use this file to discover all available pages before exploring further. # Connections and data > Understand what a connection is, which connection types exist, who operates each step, and how connected data reaches you. 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](/connections/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](/connections/served-data) | | Engine runs | Engines read connected data as their candidates or context | [Engines overview](/engines/overview) | | Delivered files | Versioned tables written to your storage on a schedule | [Transformation and delivery](/connections/delivery) | | Review outcomes | A verification label on each delivered row, and run review in the portal | [Review](/connections/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](/connections/served-data) for documents, and [Records](/data-services/overview) for a system of record in a warehouse. ## How it works 1. 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](/connections/connectors) lists exactly what each type needs. 2. Nexio creates the connection. It starts in `PENDING`. 3. 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. 4. 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. 5. 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. 6. 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](/data-services/overview), 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](/connections/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](/connections/indexing-and-extraction#indexing-profiles): 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](/data-services/writes). * 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](/connections/connectors#how-secrets-are-handled). What to hand over for each system. What happens to a document after it is read. Read extracted records and their citations through the API. Receive versioned tables in your storage.