eSignature API, within your configured workflow.

What the eSignature API connects

An envelope groups the document, the people asked to sign it, and the agreed signature settings. The sender prepares a draft and sends it only after checking the document and recipient. The signer receives a personal link by email, confirms access with a one-time code, and signs or declines. When every required signer has signed, the envelope finishes and the signed package is sealed.

This page describes the documented Sign flow and the operations to discuss for a configured integration. It does not offer a public document-validation service or establish third-party trust-service certification. See Sign scope and availability in the platform catalog.

Operations in the configured envelope flow

• Create a draft — POST /envelopes creates the envelope with its name and configured settings. Keep the returned envelope identifier associated with your business record.
• Attach the document — POST /envelopes/{id}/documents uploads the document through the authenticated multipart operation.
• Add the signer — POST /envelopes/{id}/signers associates the intended recipient. Confirm recipient details before sending.
• Send the request — POST /envelopes/{id}/send sends a prepared draft into the signing flow. Sending has an external effect; inspect the response and status before deciding how to recover from an uncertain result.
• Follow and remind — GET /envelopes/{id} reads the envelope; POST /envelopes/{id}/remind resends the link to signers who have not answered, where the flow permits it.

These are relative service routes, not a public endpoint hostname or a complete request contract. Obtain the correct regional service address, authentication flow, permissions, request schemas, and error-handling agreement for your enabled tenant. Do not assume extraction API authentication, retries, or delivery behavior applies to Sign.

A small integration example

For a synthetic agreement, the integration first creates a draft, attaches the agreed file, adds the intended signer, then asks the authorized sender to confirm the send. A partial draft-body example is shown below; jurisdiction, signature level, expiry, and other settings must follow the enabled tenant contract. This is an illustration, not an executed signing request.

{
  "name": "Synthetic agreement for integration testing",
  "locale": "en-US"
}

After sending, read the envelope status rather than equating a successful creation with a completed signature. Decide how your application records Running, Finished, Refused, and Expired states and how a person handles delivery failures. An API response, an email being delivered, and a completed signature are different milestones.

Sender access and signer access are different

Envelope management is authenticated and subject to tenant permissions. Confirm which sender identity and profile may create, read, or send envelopes before integration. The documented Sign interface lets people with Sign access see the company's envelopes, so verify the access model against your confidentiality requirements.

A signer does not need a Cogneris account for the documented personal-link journey, but needs the signing link and access to the recipient email address for the one-time code. Treat personal links and codes as sensitive access material. The signer journey describes signing and declining.

Current documented limits

• Interface scope — the documented New envelope flow creates one document and one signer; it does not establish a general multi-document or multi-signer interface.
• Signature level — Simple electronic signature (SES) is the documented option. Confirm suitability for your use case with the responsible legal and business teams.
• Cancellation — the documented interface has no action to cancel a sent envelope. Confirm expiry and recovery needs before sending.
• Additional integration behavior — workflow-triggered envelopes, event delivery, retries, and signed-document validation require separately confirmed configuration and contracts.

Do not infer advanced or qualified signature levels, jurisdiction-wide legal acceptance, public authenticity validation, or regulatory certification from the existence of a signing flow. The settings displayed in the interface do not by themselves establish those claims.

Confirm the scope before going live

Use the send-an-envelope manual to review the sender's steps and current accepted inputs. Agree on regional hosting, access, retention, recipient handling, support, and the acceptance evidence for your integration. Check the platform security boundaries as part of that review.

Public component status is an availability signal for the service; it does not prove that a particular tenant or signing workflow is enabled. Contact Cogneris to confirm your Sign scope and commercial terms before planning production traffic.