Integrations / Connectors

Connectors link PRESHos Platform to external applications. The split to keep in mind: integration packages own auth, install, config, and scheduling, while the Connector SDK is the reusable inbound record import layer (discover objects, map fields, create and update mapped records, record outcomes).

Packages handle how a connector plugs in; the SDK handles how records flow in. That split explains where every piece below lives.

• A connector is connected only when it has been provisioned, credentialed, and enabled for your tenant environment, and shows up as available in session scope.
• Connector code existing is not the same as that connector being live and connected for a tenant. Never promise a stakeholder a system is integrated because the code exists.
• The environment tool list is the source of truth. If a system is not listed there, sessions cannot reach it no matter what the catalog suggests.

Requesting a connector

Connectors are provisioned deliberately, not switched on from a marketplace. When sessions need a system they cannot reach:

1. Confirm the gap in the environment tool list (not in the catalog, in the tenant scope).
2. Route the request through your admin to the PRESHai team with the tenant hostname, the org scope, and the systems and data in play.
3. Treat the connector as deferred until it is verified in-environment: listed, credentialed, and within session scope.

What next

• Connector binding: the org-scope last mile for one install (coordinates, destinations, authorized runner).
• Connector SDK: packages vs. the SDK, auth, lifecycle, build and extend guides.
• MCP registry: the agent-config building block for MCP capabilities, catalog vs. install.
• Core concepts: the code-is-not-connected rule in full.