v2.0.0 is the release in which CYPEX becomes a multi-tenant PostgreSQL application platform. Tenancy is a first-class object (Organizations), isolation is enforced in the database (Row-Level Security), authorization is two-dimensional (Capabilities × Data Scope), schema exposure is explicit (Schema Access), identity can be federated (SSO Gateway), and outbound integrations are governed (allowlist, credentials, enablement, audit).

Warning

This is not a drop-in patch. v2.0.0 changes the permission and tenancy model. Read the Upgrade to v2.0.0 operator guide before planning a maintenance window, then the Upgrading to v2.0.0 technical reference for the database detail.

A CYPEX deployment can serve more than one tenant — an Organization — from the same PostgreSQL database. Isolation is enforced by Row-Level Security in the database, not by UI filtering.

This is the hands-on companion to Connectors (the architecture reference) and the individual GUI pages under Administration panel → Integrations. It walks through building one connector end to end, using real screenshots and a real (sanitised) request/response captured while writing this guide.

Two things must exist before you can even save a connector — the order below is enforced by the backend, not just a suggested reading order:

This page is the operational counterpart to the conceptual pages in the Administration panel section. It targets operators standing up a CYPEX deployment for the first time.

For the why behind the admin IA, see the Administration panel landing and the linked per-section pages. For org / Schema Access operations specifically, see the Organizations setup guide.

Before walking through the procedures, skim the relevant admin pages:

This page is the mandatory upgrade entry point for CYPEX v2.0.0. It is written for operators who run CYPEX in production and need a single walkthrough that covers every breaking change in this release.

Audience. Read this end-to-end before opening the maintenance window. It links out to detailed pages for each topic; follow every link in the order presented.

v2.0.0 introduces seven platform-level changes. Each one is breaking or behavior-changing for at least one class of deployment.

v2.0.0 lets three elements draw on a governed external API connector instead of a database query:

Same canvas, same elements — a different source of data.

A connector must exist and be published before it appears in the designer. Connectors are built and governed on the admin side — allowlist, credentials, definition, then execution enablement. If the picker says “No published connectors are available for this app”, the work is in the admin panel, not the designer. See Connectors and the Connectors setup guide.

Info

This is the conceptual / architecture reference. For the hands-on, step-by-step walkthrough with screenshots and a real sanitised request/response, see the Setup guide. For the admin-panel GUI reference (screenshots, field-by-field), see Connectors, Connector Secrets, Connector Allowlist, and Connector Enablement.

1. This page — the conceptual / architecture reference.
2. Setup guide — the hands-on E2E walkthrough: rollout, allowlist, credentials, the guided builder, publish, execute, and audit.

A Connector is a governed, server-side definition for calling a third-party REST API and mapping its response into a typed shape a CYPEX application can render — an authenticated CYPEX user’s page can show a table backed by a live external API call, next to tables backed by CYPEX’s own PostgreSQL data.

Under Integrations → Connector Execution, the page heading is Connector Execution Rollout. It is a two-step kill switch for connector execution. Everything is off by default — connectors only run in an organization when platform-wide execution is on and that organization is included in the rollout:

Info

Enterprise licence required. Integrations is gated on an active enterprise licence. Without one the section does not appear in the admin sidebar, regardless of the signed-in user’s role.

Under Integrations → Allowlist, the page heading is Connector Allowlist. It is the set of hosts outbound connectors are permitted to call. Connectors cannot reach any host that is not allowlisted — this is enforced at runtime, not just validated at save time:

Info

Enterprise licence required. Integrations is gated on an active enterprise licence. Without one the section does not appear in the admin sidebar, regardless of the signed-in user’s role.

Under Integrations → Credentials, the page heading is Connector Credentials. Credentials are encrypted at rest and referenced by connectors by name — never inline. They are write-only: the plaintext value is never shown again after saving:

Info

Enterprise licence required. Integrations is gated on an active enterprise licence. Without one the section does not appear in the admin sidebar, regardless of the signed-in user’s role.

Under Integrations → Connectors, you build and manage governed REST connectors. A connector is authored as a draft, optionally dry-run against the live provider, then published as an immutable version — editing a published connector creates a new draft, and the live version stays unchanged until you publish again:

Info

Enterprise licence required. Integrations is gated on an active enterprise licence. Without one the section does not appear in the admin sidebar, regardless of the signed-in user’s role.