Skip to main content
CYPEX Documentation
    Support
    v2.0.0 Latest stable release View changelog ->
    CYPEX — PostgreSQL Application Platform › CYPEX Documentation › Administration Panel › Connector Audit

    Connector Audit

    2 min read
    Tags administration connectors audit monitor integrations v2.0.0 Category administration

    Under Monitor & Audit → Connector Audit, this page is the execution history for outbound connectors — successes, failures, and policy blocks, newest first:

    Connector Audit

    Live executions (no tag) sit alongside Dry run executions from the builder's Fetch sample / Test response mapping. Both are the same audit trail, distinguished only by the Dry run tag.

    Live executions (no tag) sit alongside Dry run executions from the builder's Fetch sample / Test response mapping. Both are the same audit trail, distinguished only by the Dry run tag.

    Filters

    • Organization — scope to one tenant.
    • Connector — scope to one connector definition.
    • Action — one or more of EXECUTE_STARTED, EXECUTE_SUCCESS, EXECUTE_FAILED, EXECUTE_BLOCKED, EXECUTE_RETRIED, EXECUTE_TIMEOUT.
    • Execution — All, Live, or Dry run. Dry run covers both the builder’s Fetch sample step and Test response mapping; Live covers real POST /connectors/:id/execute calls.
    • Error category — filters to one of the categories in Connectors — explicit security boundaries: configuration, schema_validation, policy_block, secret_unavailable, provider_error, timeout, internal.
    • From / To — date range.

    Row details

    Each row shows Connector, Method | Operation, Organization, Action (Success/Blocked/etc., plus a Dry run tag when applicable), Error category, Status (HTTP code), Duration, and Time. Click the Details icon for the full record:

    Execution details

    The sanitised URL never includes query-string secrets; the Authorization/credential header itself is never stored at all. Correlation ID ties this row to the same value returned in the API response and usable for cross-referencing provider-side support tickets.

    The sanitised URL never includes query-string secrets; the Authorization/credential header itself is never stored at all. Correlation ID ties this row to the same value returned in the API response and usable for cross-referencing provider-side support tickets.

    The details modal adds: Connector ID, the sanitised outbound URL, HTTP status code, retry attempt number, Correlation ID, the CYPEX User ID who triggered it, and IP address / User agent (populated for live executions, typically empty for builder dry-runs since those originate server-side from the admin session).

    This is the permission audit log, filtered

    Connector executions aren’t a separate audit system. Every row here is an EXECUTE_* action in cypex_log.t_permission_audit_log — the same table used for every other permission/role/organization change — read through a dedicated, connector-scoped endpoint:

    GET /admin/audit/connector-executions

    The endpoint and its sidebar entry are system-admin only, because the history spans every tenant. Organization admins review their own connector activity through the permission audit log instead. See Capabilities vs Data Scope — Permission audit cross-link for the shared audit model this page is part of.

    See also

    • Connectors (architecture) — the full error-category taxonomy and security boundaries.
    • Connectors — where Fetch sample / Test response mapping (the dry-run rows here) come from.
    • Connector Execution — gates whether a live execution can happen at all.
    • Audit — table-level and user-login audit (a separate, non-connector audit surface).
    Audit trails Configuration