Connector library

Implemented source Enterprise, ERP & HR APIs

Yoti Sign connector.

Read native Yoti Sign envelope status and selected envelope ID/status metadata through two named actions.

Connector download

Download Yoti Sign

Versioned ZIP for your CXFabric tenant.

Use this connector in a flow

  1. Register the ZIP in your tenant, or add a new version if the connector is already installed.
  2. Create or select a credential if the action requires one.
  3. In a Draft flow, add an available action, choose its version, connect it, and map inputs.
  4. Test the step and flow; review output and failures before activation.

See readme.md in the ZIP for settings and limitations.

Version
v0.2.0.0 Choose version
Release
2026-10-04
Package
Implemented source
Schema credentials
Bearer token
Connection settings
Environment
Package size
8 KB
SHA-256
4335a2eb1ffbd7fe5fc36d73f9ae373d2da880f1efc2e655e29d881ad53091bb

Version history

What's new

  1. v0.2.0.0Latest · 2026-10-04 · Implemented source

    Two named v2 envelope reads preserve native endpoint-specific status labels and verified ID/status metadata, with managed environment-specific Bearer API keys. Personal/signing details are omitted; replaces the generic scaffold with hosted/live validation pending.

  2. v0.1.1.0Earlier · 2026-10-02 · Starter scaffold

    Historical configurable HTTP scaffold; not a vendor-specific implementation.

Included in this version

Included actions

Implemented in v0.2.0.0. Use a separate flow trigger; no webhook trigger is included.

Get envelope status

Read the native status endpoint; COMPLETED is retained without renaming.

Get envelope metadata

Read selected envelope ID/status only; COMPLETE is retained without renaming. Recipient and signing details are omitted.

Vendor API

API and access

Implementation considerations
  • Native envelope status: Read the native status endpoint and retain its documented status label.
  • Selected envelope metadata: Read and verify the exact returned envelope ID with native status, omitting personal and signing details.
  • Caller-managed reads; no polling, document download, creation, signing or other writes are included.
  • Select Sandbox (https://demo.api.yotisign.com) or Production (https://api.yotisign.com) to match the issued API key. Store only that key in a managed Bearer Token credential; the native header is Authorization: Bearer. Key issuance/rotation and creator/key permissions remain external. Envelope ID must be the exact issued UUID string without whitespace or an arbitrary URL.
  • The status endpoint uses COMPLETED, ARCHIVED, ACTIVE and ERRORED. The envelope endpoint uses QUEUED, ACTIVE, ARCHIVED, COMPLETE and ERRORED. COMPLETE and COMPLETED remain distinct native labels; no alias or shared-state conversion is invented. Unknown/missing statuses and mismatched IDs fail. Status metadata does not independently prove signature authenticity, document validity or a legal outcome.
  • Metadata output deliberately omits recipients, signer tokens, emails, IP addresses, tags, document names and raw creation-error details. If a status response includes an envelope ID it must match; the metadata action requires it. HTTP 404 and API errors remain failures and do not establish global absence.
  • Request Budget is 1000–8000 ms shared by transport and validation, default 7000; strict UTF-8 JSON has a 1 MiB response cap. Normal TLS verification remains enabled; redirects and environment proxies are disabled, with no replay. Hosted import, saved mappings, executor dependencies and live key/environment/creator/envelope checks remain untested.
  • Two packaged v2 reads return native envelope status or verified selected ID/status metadata. Current public guides establish fixed environment hosts, Bearer API-key authentication and endpoint-specific status labels; live creator/key/envelope behavior and hosted dependencies need validation.

Support

Need help with Yoti Sign?

Tell us what you need to connect or change.