EviSign

Copy

• Copy for LLM

  Copy page as Markdown for LLMs
• View as Markdown

  Open this page as Markdown
• Open in ChatGPT

  Get insights from ChatGPT
• Open in Claude

  Get insights from Claude
• Connect to Cursor

  Install MCP server on Cursor
• Connect to VS Code

  Install MCP server on VS Code

EviSign is the Namirial Notify service for sending documents for remote electronic signature. You create a signature request specifying the document, the signer or signers, and the signing method. Namirial Notify delivers the request, tracks each signer's actions, and records evidence for the configured workflow stages.

For shared concepts and terminology used across services, see States and outcomes and Evidence and affidavits.

When to use EviSign

Pick EviSign when you need to obtain a remote electronic signature on one or more documents and record evidence for the signature workflow. Pick a different service when:

• You need to deliver a certified message to a recipient's inbox without a signing step. Use EviMail.
• You need recipients to access hosted content and record on-platform interactions. Use EviNotice.
• You need to deliver a certified message via SMS or RCS. Use EviSMS.
• You need certified physical mail. Use EviPost.

A side-by-side comparison is on the Services page.

How the pieces fit together

EviSign involves a small set of related concepts. Keep these distinct as you read the rest of the page.

• EviSign — a single signature request for one document and one or more signers. Identified by a UniqueId assigned by the platform.
• Signing party — a signer, reviewer, or interested party. Each signer has their own delivery, access, and commitment events tracked separately.
• Event — a recorded fact during the lifecycle, such as Sent (signature request delivered) or Signed (signer completed the flow).
• Evidence item — the recorded data behind an event, including timestamps and signer details.
• Affidavit — a signed PDF that certifies one or more evidence items.
• Callback — an HTTP POST that Namirial Notify sends to a configured endpoint when an event matches the push notification filter you set.

How EviSign works

Lifecycle overview

Key state transitions

Submitted → Processed — Namirial Notify validates the submission, certifies the document content, and prepares the signature workflow.

Processed → Sent — Signature request notifications are sent to the first signer(s) in the configured order. For sequential multi-signer workflows, each subsequent signer receives their request only after the previous one completes. The evidence state moves to Sent when at least one signature request has been dispatched.

Sent → Closed — The workflow closes when all required signers have acted, the configured time to live elapses, the issuer cancels the request, or a failure prevents further processing. The Outcome field records the final result.

Party status (per signer) — Each signing party has its own status independent of the evidence state: None (awaiting action) → Signed or Rejected.

Signing methods

The signing method configured for each signer controls how they authenticate and complete the signature step.

Request delivery channel

Each signer is defined in SigningParties with both a notification address and the way that address should be interpreted:

When the signer is notified through a mobile number, SignatureRequestPolicy controls the channel used for the signature-request notification:

For MobilePin signing, the PIN delivery itself is configured separately:

• WhatsAppPinPolicy: Disabled, Optional, Fallback
• AllowVoicePinFallback: allows the signer to request the PIN by voice call if PIN delivery is needed

Other delivery-related fields on each signer include RequiresCaptcha, DisableSignRequests, DisableFinalNotification, and DisableStateNotifications. The older top-level Options.RequireCaptcha field is kept only for backward compatibility; use SigningParties[n].RequiresCaptcha instead.

Signature questions

Signature questions (SignatureQuestions) are additional data fields presented to the signer during the signing flow — for example, to capture identity data, consent answers, or other information required by the process.

Each question is an object in the SigningParties[n].SignatureQuestions array with a Key, Label, TypeName, and optional Required, ValidationRegex, DefaultValue, and SelectListItems (for SelectList type only).

Supported TypeName values

Signature step

SignStep controls at what point in the signing flow the identity or authentication step happens relative to document review. It is set per signing party as SigningParties[n].SignStep (nullable — when omitted the platform uses AfterDoc).

SignStep is independent per signer — different parties in the same submission can use different values.

Generated Signed Document (GSD)

GSD produces an additional PDF after the signing process completes. The output document contains the original content with each signatory's electronic signature graphically embedded at the configured position. It is independent of the affidavits generated during the process.

API parameters

GSD is controlled by two parameters in the top-level Options object:

Signature appearance per signer

Each object in SigningParties accepts a SignatureAppearances parameter that defines where the signer's signature is placed in the generated PDF.

SignatureAppearances: '[{"PageNumber":1,"Left":100,"Bottom":100,"Right":300,"Top":150}]'

The value is a JSON array serialized as a string. Each element defines one appearance on one page:

The PDF coordinate system has its origin (0, 0) at the bottom-left of the page. X increases to the right; Y increases upward. One point equals 1/72 of an inch.

If SignatureAppearances is omitted for a signer, GSD still runs but that signer's signature is embedded without a visual representation at a specific location.

SignatureAppearances requires Handwriting signing method and is not compatible with Lite Flow.

Lite Flow

Lite Flow is a simplified signing interface that reduces the number of steps a signer sees, for a faster signing experience.

API parameter

LiteFlow is set per signing party in SigningParties:

Compatibility

Not all EviSign features are supported when LiteFlow is true for a signer.

Party roles

Certification level

The certification level determines the legal strength of the signature and which signing methods are supported.

Do not submit Standard or Advanced without a country suffix. For regions not covered, the EU value is usually used, as European regulations are widely accepted.

Evidence access control

EvidenceAccessControlMethod controls who can open the evidence record after the process closes. It is set in Options alongside optional challenge fields.

When Challenge is selected, set the question and expected answer in the same Options object:

For how recipients experience the access challenge when following an evidence link, see Accessing archived evidence as a recipient.

What the signer sees

The signer receives the signature request through the channel configured for their party — email for Email parties, or SMS/WhatsApp delivery for PhoneNumber parties. They follow a secure link into the Namirial Notify signing flow, complete any required authentication step (challenge, PIN, etc.), review the document, and accept or reject.

For the full recipient experience, see How a recipient receives an EviSign.

Embedded delivery integration

EviSign supports loading the signing flow directly inside your application via an iframe or a native WebView. This allows you to embed the signing experience without redirecting the user away from your product.

Per-party delivery parameters

The following parameters in each SigningParties object control how the signing URL is delivered and loaded:

Status events during the signing flow

During the embedded signing process, Namirial Notify communicates status changes back to the host application through the X-Herma-Problem-Details response header. The payload follows RFC 7807 — Problem Details for HTTP APIs.

For WebView channels, the header is set on each response within the signing flow:

X-Herma-Problem-Details: <JSON>

For iframe channels, the same data is dispatched as a JavaScript event to the parent window, allowing the host page to react without inspecting response headers.

Payload structure

Example payload

{
  "Type": "https://namirial.com/evisign/event/signed",
  "Status": 200,
  "Title": "Signer completed the signature step",
  "Detail": "The signer accepted and signed the document.",
  "Instance": "/delivery/evisign/abc123/commit",
  "Data": {
    "PartyId": "f47ac10b-58cc-4372-a567-0e02b2c3d479"
  }
}

Callbacks and what you receive

When a state in the push notification filter is reached, Namirial Notify sends an HTTP POST to the configured endpoint. Callbacks are per-EviSign and opt-in. They are configured at creation time either in the platform UI or through Options.PushNotificationUrl and Options.PushNotificationFilter in API-based submissions.

Available events

Sent, Delivered, Signed, and Rejected fire once per party. FullySent, FullyDelivered, and FullySigned are aggregate events that fire once for the whole EviSign.

Base payload

Every callback shares the same envelope:

{
  "Identifier": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "Kind": "Signed",
  "Date": "2026-03-10T09:22:14.0000000+01:00",
  "EvidenceId": "9f3e1a02-b74c-4d8e-91c5-f00012345678",
  "EvidenceType": "eviSign",
  "EvidenceState": "Sent",
  "Owner": "John Doe",
  "OwnerEmail": "sender@example.com",
  "Site": "my-site",
  "AdditionalData": { }
}

Use Identifier as the idempotency key on your side. For retry behavior and general callback guidance, see Callbacks and webhooks.

AdditionalData fields — per event

Most events include signer details in AdditionalData.

Sent — signature request sent to one signer

{
  "Kind": "Sent",
  "AdditionalData": {
    "SignerName": "Alice Martin",
    "SignerNotificationAddres": "alice@example.com",
    "SignerNotificationAddresType": "Email",
    "SignerRole": "Signer",
    "TransmissionSuccess": true,
    "TransmissionDescription": "Signature request sent",
    "EventDescription": "Signature request dispatched"
  }
}

Delivered — signature request confirmed delivered to one signer

{
  "Kind": "Delivered",
  "AdditionalData": {
    "SignerName": "Alice Martin",
    "SignerNotificationAddres": "alice@example.com",
    "SignerNotificationAddresType": "Email",
    "SignerRole": "Signer",
    "TransmissionSuccess": true,
    "TransmissionDescription": "Delivery confirmed",
    "EventDescription": "Signature request delivery confirmed"
  }
}

Signed — one signer completed the signing step

{
  "Kind": "Signed",
  "AdditionalData": {
    "SignerName": "Alice Martin",
    "SignerNotificationAddres": "alice@example.com",
    "SignerNotificationAddresType": "Email",
    "SignerRole": "Signer"
  }
}

Rejected — one signer rejected the document

{
  "Kind": "Rejected",
  "AdditionalData": {
    "SignerName": "Alice Martin",
    "SignerNotificationAddres": "alice@example.com",
    "SignerNotificationAddresType": "Email",
    "SignerRole": "Signer"
  }
}

FullySent, FullyDelivered, FullySigned, Processed — no AdditionalData fields beyond the base payload.

Closed — workflow reached its final state

{
  "Kind": "Closed",
  "AdditionalData": {
    "OutCome": "Signed"
  }
}

When the outcome is Cancelled, CancelComments is also included if a reason was provided:

{
  "Kind": "Closed",
  "AdditionalData": {
    "OutCome": "Cancelled",
    "CancelComments": "Request withdrawn by issuer"
  }
}

AffidavitPublished — an affidavit is ready

{
  "Kind": "AffidavitPublished",
  "AdditionalData": {
    "AffidavitId": "b7f1e3c0-1234-5678-abcd-ef0987654321",
    "AffidavitKind": "PartyCommitted",
    "AffidavitName": "Party commitment affidavit"
  }
}

RequestId is included only for on-demand affidavits. Regenerated: true is included only when the affidavit was regenerated by a platform command.

What each callback means

Callback reliability

Namirial Notify retries failed callbacks. Return 2xx before doing heavy processing — use a background queue for the work. Use Identifier as an idempotency key; the same event can arrive more than once on retries.

Securing your callback endpoint

Namirial Notify sends callbacks as plain HTTP POST requests with no authentication header. Use HTTPS, restrict by IP, and validate EvidenceType and EvidenceId on every incoming request. See Security and authentication for full guidance.

States reference

Forwarded and Received exist in the source but are not part of the normal main workflow. They may appear in specific or legacy flows.

Outcomes reference

The Outcome is None until the EviSign reaches Closed. Once closed, it reflects the final result.

Evidence and affidavits

When each affidavit is generated

Affidavits are delivered via AffidavitPublished callbacks if subscribed.

Integration checklist

Use this as a reference when integrating callbacks or downstream processes with an EviSign workflow.

Workflow configuration

• Callback endpoint URL is HTTPS in production
• Push notification filter includes at minimum FullySigned,Closed,AffidavitPublished
• Affidavit kinds are selected to match your compliance requirements
• Certification level matches the legal requirements for your use case

Callback handling

• Your endpoint responds 2xx before doing any heavy processing
• Your endpoint is idempotent — the same callback may arrive more than once
• You validate EvidenceType == "eviSign" on every incoming callback
• You use Identifier to deduplicate retried callbacks

State handling

• You do not treat FullySigned as final — wait for Closed before updating your records
• You handle all terminal outcomes: Signed, Rejected, Expired, Cancelled, Failed

Affidavits

• You download and store affidavits when the AffidavitPublished callback fires

Troubleshooting

The signer never received the signature request

Possible cause: The notification address is incorrect, or the notification was filtered as spam.

What to check:

1. Ask the signer to check their spam or junk folder.
2. Verify the email address or phone number configured for the signer.
3. Check whether the Sent callback fired — if not, the notification may not have been dispatched yet.
4. Confirm the EviSign has progressed to Sent state.

I receive Signed callbacks but no FullySigned

Possible cause: Not all required signers have acted yet. FullySigned fires only when all required parties have signed.

What to check:

1. Review the signing party list and confirm whether parties with None status are required.
2. Check whether those parties have received their signature request — look for a Sent callback per party.
3. If the workflow uses a sequential signing order, earlier parties must sign before later ones receive their request.

The Closed callback arrived with OutCome: "Rejected"

Possible cause: At least one required signer rejected the document.

What to check:

1. Identify which party rejected by reviewing the Rejected callbacks received before Closed.
2. Decide whether to create a new EviSign with corrected content or contact the signer directly.

I am not receiving AffidavitPublished callbacks

Possible cause: AffidavitPublished is not in the push notification filter, or no affidavit kinds were selected at creation time.

What to check:

1. Confirm AffidavitPublished is included in the configured event filter.
2. Confirm at least one affidavit kind was selected when the EviSign was created.

The signing link does not work or has expired

Possible cause: The EviSign has already closed (signed, rejected, expired, or cancelled), or the signing link has reached its configured time limit.

What to check:

1. Check the current state of the EviSign.
2. If the EviSign is still open (Sent state), the issuer can use the platform to resend the signature request.
3. If the EviSign is already Closed, it cannot be reopened — create a new one.

Related

• How to create a new EviSign
• How a recipient receives an EviSign
• Services
• States and outcomes
• Evidence and affidavits
• Callbacks and webhooks