Connector data sources

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

The outbound call to the third-party API is made by the CYPEX backend, under the outbound allowlist and the stored credential. The browser only asks CYPEX to run the operation — it never contacts the third party and never receives the credential.

The Table element’s data-source picker groups its options:

Pick a connector operation and CYPEX generates the table’s columns from the operation’s response shape, the same way it generates them from a view.

If the operation takes input, an Operation parameters section appears. Each parameter accepts either a literal or a custom expression resolved against page and user state on every load. Required parameters are marked (required).

Leave a parameter blank to omit it — but a blank required parameter will error at load time rather than silently returning nothing.

The Form element has a Source type toggle: View or Connector.

Switching to Connector exposes two operations, because a form both reads and writes:

Each has its own parameter block — Read parameters and Write parameters.

Two shortcuts save you building the form by hand:

• Generate fields from payload — builds the form’s fields from the write operation’s payload shape.
• Regenerating from the read operation builds fields from what the read returns.

Both replace the current fields, and CYPEX asks before doing it. If a write operation has more than one shaped payload parameter, fields are generated from the first one and the editor says so.

Map payload from form fields sets the write mapping to the form’s own data, so a submit sends the fields you just built. Use it after generating fields — it is the step that connects what the user types to what gets sent.

Field values on save resolve from literals or custom expressions, so a form can send values the user never sees.

The Autocomplete input’s Options Source section offers three modes:

In Connector mode, pick the Connector and Operation, then map Value field and Label field onto the operation’s response — the connector equivalent of choosing a value column and a label column from a view. The operation must return multiple rows.

If the operation takes input, the same Operation parameters block appears and behaves as it does on a Table.

Warning

When a connector source is selected, the Table editor hides the controls below. They compile to PostgREST query parameters, which the connector runtime does not accept in this release — so rather than offer a control that would be silently ignored, the editor removes it.

Still available: row selection, columns, default rows per page, refresh interval, and actions.

The List element has no connector source at all in v2.0.0 — it remains view-backed.

A connector-backed table therefore displays and pages its data but cannot be sorted, searched, or filtered from the designer. Filter support, List connectors, and further element types are scheduled for v2.0.1.

Tip

Plan around the boundary rather than into it: build read-and-display and form-driven flows on connectors today, and keep anything that needs designer-side filtering on a view until the follow-up release. Where you control the upstream API, an operation parameter can do the filtering server-side instead.

• Connectors — the governance model and the v2.0.0 scope boundary.
• Connectors setup guide — building and publishing a connector.
• Application Designer — the editor.
• Expressions — the expression language used for parameter mapping.
• List · Filter builder — other v2.0.0 designer features.