# EviSign

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.

EviSign requests are created in the Namirial Notify platform. This page focuses on workflow behaviour, signer experience, and callback semantics. For issuer step-by-step instructions, see [How to create a new EviSign](/products/namirialnotify/issuer/create-evisign).

For shared concepts and terminology used across services, see [States and outcomes](/products/namirialnotify/user-guides/states-outcomes) and [Evidence and affidavits](/products/namirialnotify/user-guides/evidences-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](/products/namirialnotify/services/evimail).
- You need recipients to access hosted content and record on-platform interactions. Use [EviNotice](/products/namirialnotify/services/evinotice).
- You need to deliver a certified message via SMS or RCS. Use [EviSMS](/products/namirialnotify/services/evisms).
- You need certified physical mail. Use [EviPost](/products/namirialnotify/services/evipost).


A side-by-side comparison is on the [Services](/products/namirialnotify/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.


```mermaid
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#E4F2F2', 'primaryBorderColor': '#006660', 'primaryTextColor': '#0A1111', 'lineColor': '#047C76', 'secondaryColor': '#CDDBDB', 'tertiaryColor': '#f5fafa', 'edgeLabelBackground': '#f5fafa', 'transitionColor': '#047C76'}}}%%
flowchart LR
    ES["EviSign<br/>(1 document + N signers)"] --> SP["Signing parties<br/>(Signers, Reviewers, Interested)"]
    ES --> EV["Events<br/>(Processed, Sent, Delivered,<br/>Signed, Rejected, Closed…)"]
    EV --> EVI["Evidence items<br/>(stage timestamps + details)"]
    EVI --> AFF["Affidavits<br/>(PDFs signed by Namirial Notify)"]
    EV --> CB["Callbacks<br/>(filtered by push notification settings)"]
    CB --> YS["Your system<br/>(HTTPS endpoint)"]
    AFF -.->|"via AffidavitPublished<br/>callback"| YS
```

- **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


```mermaid
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#E4F2F2', 'primaryBorderColor': '#006660', 'primaryTextColor': '#0A1111', 'lineColor': '#047C76', 'secondaryColor': '#CDDBDB', 'tertiaryColor': '#f5fafa', 'edgeLabelBackground': '#f5fafa', 'transitionColor': '#047C76'}}}%%
stateDiagram-v2
    [*] --> Submitted : Submit accepted
    Submitted --> Processed : Content certified, workflow prepared
    Processed --> Sent : Signature requests sent to first signer(s)
    Sent --> Closed : Signed outcome
    Sent --> Closed : Rejected outcome
    Sent --> Closed : Expired / Cancelled / Failed outcome
    Submitted --> Closed : Failed (processing error)

    note right of Sent
        Sent reflects the evidence-level state.
        Each signer has their own party status:
        None → Signed or None → Rejected.
        FullySigned fires when all required
        signers have signed.
    end note
```

### 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.

| Value | Description |
|  --- | --- |
| `MobilePin` | A PIN is sent to the signer's mobile number. The signer enters it to confirm the signature. |
| `EmailPin` | A PIN is sent to the signer's email address. The signer enters it to confirm the signature. |
| `Challenge` | The signer answers a challenge question defined when the request is created. |
| `Handwriting` | The signer draws their signature on a web canvas. |
| `ExternalHandwriting` | Handwriting signature collected via an external service. |
| `UserCertificate` | The signer signs using their own personal digital certificate. |
| `WebClick` | Simple web click to accept. Deprecated — use `MobilePin`, `EmailPin`, or `Challenge` for new workflows. |


The signing methods available depend on the certification level selected and on which methods are enabled for your tenant.

## Request delivery channel

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

| Parameter | Values | Meaning |
|  --- | --- | --- |
| `SigningParties[n].AddressType` | `Email`, `PhoneNumber` | Whether the signature request is delivered to an email inbox or to a mobile number. |
| `SigningParties[n].Address` | string | The actual email address or international-format phone number. |


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

| Value | Behaviour |
|  --- | --- |
| `SmsOnly` | Send the request by SMS only. |
| `WhatsAppOnly` | Send the request by WhatsApp only. |
| `SmsThenWhatsApp` | Try SMS first, then WhatsApp as fallback. |
| `WhatsAppThenSms` | Try WhatsApp first, then SMS as fallback. |


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

| TypeName | What the signer provides | Validation |
|  --- | --- | --- |
| `Text` | Free text (single line) | None |
| `MultiLineText` | Free text (multiple lines) | None |
| `Number` | Integer number | Must be a valid integer |
| `Decimal` | Decimal number | Must be a valid decimal |
| `Date` | Date | Must be in `dd-MM-yyyy` format |
| `CheckBox` | Checkbox (true / false) | None |
| `SelectList` | One option from a provided list | Must match a value in `SelectListItems` |
| `Password` | Text (input is masked) | None |
| `EmailAddress` | Email address | Must be a valid email format |
| `PhoneNumber` | Phone number | Must be in international format (e.g. `+34914237080`) |
| `BankAccount` | Bank account number | No format validation |
| `BankAccountES` | Spanish bank account (20 digits, no spaces) | Must be a valid Spanish account with check digit |
| `BankAccountIBAN` | IBAN account (ISO 13616) | Must be a valid IBAN |
| `BankAccountIBANES` | Spanish IBAN (24 digits, no spaces) | Must be a valid Spanish IBAN with check digits |
| `SwiftCode` | SWIFT / BIC code | None |
| `DocumentId` | Identity document or passport number | None |
| `SpanishDocumentId` | Spanish NIF or NIE (including check digit) | Must be a valid Spanish NIF/NIE format |
| `IntlVatId` | International VAT ID | No check-digit validation |
| `SpanishVatId` | Spanish tax ID (NIF, CIF, or VIES VAT number with country prefix) | Must be a valid Spanish fiscal identifier |
| `Image` | Image file upload (JPEG or PNG) | Must be a JPEG or PNG |
| `File` | Any file upload | None |
| `DynamicSignature` | Biometric handwritten signature with metadata | Requires a mobile device and the Namirial signing app |
| `None` | No input — displayed as informational text only | None |


`DynamicSignature` requires a supported mobile device and the Namirial mobile signing app. It is not available in standard browser-based flows.

## 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`).

| Value | When authentication happens | Lite Flow | Typical use |
|  --- | --- | --- | --- |
| `Begin` | **Before everything** — authentication is the first action the signer takes, before any document or attachment is shown. | ✅ Compatible | When the issuer wants to confirm signer identity before exposing any content. |
| `BeforeDoc` | After any pre-document attachments, **before the main document** — signer authenticates, then reads the document. | ❌ Incompatible | When the issuer wants identity confirmed before the document is opened, but after optional prior information is reviewed. |
| `AfterDoc` | **During or immediately after** viewing the main document — the signer reads the document, then completes the authentication/signature step. This is the **default** when `SignStep` is not set. | ✅ Compatible | Standard signature flows where the signer reads the document and then signs. |
| `End` | **After all documents and attachments** — the signer reviews everything first, then authenticates and commits at the very end. | ❌ Incompatible | When the issuer wants the signer to see the complete package before any commitment. |


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

The older `SignDelivery` boolean is an earlier equivalent of `SignStep`: setting `SignDelivery: true` is the same as `SignStep: Begin`. To avoid ambiguity, set `SignStep` on its own rather than combining the two.

## 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:

| Parameter | Type | Description |
|  --- | --- | --- |
| `Options.GenerateSignedDocument` | bool | Set to `true` to enable GSD for this submission. |
| `Options.GenerateSignedDocumentOptions.CertificationCertificate` | string | Identifier of the site or user certificate to use when certifying the generated document. Omit to use the default configured certificate. |


### 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:

| Field | Type | Description |
|  --- | --- | --- |
| `PageNumber` | int | 1-indexed page number where the signature box is placed. |
| `Left` | number | X coordinate of the **left edge** of the signature box, in PDF points from the left of the page. |
| `Bottom` | number | Y coordinate of the **bottom edge** of the signature box, in PDF points from the bottom of the page. |
| `Right` | number | X coordinate of the **right edge** of the signature box, in PDF points from the left of the page. |
| `Top` | number | Y coordinate of the **top edge** of the signature box, in PDF points from the bottom of the 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`:

| Parameter | Type | Default | Description |
|  --- | --- | --- | --- |
| `SigningParties[n].LiteFlow` | bool? | `false` | Set to `true` to activate Lite Flow for this signer. Can be mixed — some signers can use Lite Flow while others use the standard flow in the same submission. |


### Compatibility

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

| Feature | Supported |
|  --- | --- |
| `Challenge` signing method | No |
| `Handwriting` signing method | No |
| `SignatureAppearances` | No |
| `SignedRedirectUrl` | No — always redirects to the finish page |
| `BeforeDoc` sign step | No |
| `End` sign step | No |
| Geolocation | No |
| `LandingPageInfoText` | No — accepted but not shown |
| `MobilePin` signing method | Yes |
| `EmailPin` / `WebClick` signing method | Yes |
| Voice PIN fallback | Yes |
| WhatsApp (Disabled, Optional, Fallback) | Yes |
| Iframe delivery | Yes — requires simple delivery |
| Signature questions | Yes |
| `Begin` sign step | Yes |
| `AfterDoc` sign step | Yes |
| Attachments (with or without required signature) | Yes |
| Additional commitments | Yes |
| Commitment options | Yes |
| Accept / reject reasons | Yes |
| Generated Signed Document (GSD) | Yes |
| Reviewer role | Yes |
| Signing order | Yes |


## Party roles

| Role | Description |
|  --- | --- |
| `Signer` | Must complete the signing step. Their action is tracked and drives the party status. |
| `Reviewer` | Reviews the document before the signing step. Depending on configuration, a reviewer may need to accept or reject before signers can act. |
| `Interested` | Receives notifications at configured stages but does not sign. |


## Certification level

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

| Value | Description |
|  --- | --- |
| `None` | No legal certification. Evidence is recorded but no certified affidavit is generated. |
| `Standard:EU` | Standard electronic signature under EU eIDAS. |
| `Standard:CO`, `Standard:CR`, `Standard:EC`, `Standard:MX`, `Standard:PE` | Standard signature for the respective country. |
| `Advanced:EU` | Advanced electronic signature under EU eIDAS. Requires a stronger signing method. |
| `Advanced:CO`, `Advanced:CR`, `Advanced:EC`, `Advanced:MX`, `Advanced:PE` | Advanced signature for the respective country. |


`Standard` and `Advanced` (without a country suffix) are accepted as legacy aliases and map to the `:EU` variants.

## Evidence access control

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

| Value | Behaviour |
|  --- | --- |
| `Default` | Uses the access control method configured for the site or reseller. |
| `Public` | No access restriction — anyone with the evidence URL can view it. |
| `Session` | **Deprecated.** Throws an error for all new integrations. Use `Challenge` or `AutoChallenge` instead. |
| `Challenge` | The viewer must correctly answer a custom question defined by the issuer at submission time. |
| `AutoChallenge` | The viewer must answer a system-generated question based on known transaction data (for example, the issuer's email address or the destination address used in the submission). |


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

| Parameter | Type | Description |
|  --- | --- | --- |
| `Options.EvidenceAccessControlMethod` | `AccessControlMethod?` | The access control method to apply. |
| `Options.EvidenceAccessControlChallenge` | string | The challenge question shown to the viewer. Required when method is `Challenge`. |
| `Options.EvidenceAccessControlChallengeResponse` | string | The correct answer. Required when method is `Challenge`. Comparison is case-insensitive. |


For how recipients experience the access challenge when following an evidence link, see [Accessing archived evidence as a recipient](/products/namirialnotify/user-guides/archiving#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](/products/namirialnotify/recipient/receive-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:

| Parameter | Type | Description |
|  --- | --- | --- |
| `DeliveryWebView` | string | Identifier of the WebView channel registered for your site. When set, the signing URL is scoped to that WebView context. |
| `DeliverySubDomain` | string | Custom subdomain under which the delivery area is loaded. Used when the signing flow should be served from a branded domain. |
| `DeliveryCustomUrl` | string | Custom redirect URL used when `DeliverySubDomain` is set. |
| `DeliveryProfile` | string | ID of the delivery profile that selects which delivery portal the signer should sign on. |


### 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](https://www.rfc-editor.org/rfc/rfc7807).

**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

| Field | Type | Description |
|  --- | --- | --- |
| `Type` | string | URI identifier of the event type. |
| `Status` | int | HTTP status code of the request. |
| `Title` | string | Short human-readable description of the event. |
| `Detail` | string | Detailed description of the event. |
| `Instance` | string | URL that triggered the event. |
| `Data` | object | Additional event-specific data. Common keys include `PartyId` (present when the event is associated with a specific signer) and error detail entries when a problem occurred. |


### Example payload


```json
{
  "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

| Event | When it fires |
|  --- | --- |
| `Processed` | The document was certified and the workflow was prepared |
| `Sent` | A signature request notification was sent to one signer |
| `Delivered` | A signature request notification was delivered to one signer |
| `Signed` | One signer completed the signing step |
| `Rejected` | One signer rejected the document |
| `FullySent` | Signature request notifications were sent to all parties |
| `FullyDelivered` | Signature request notifications were delivered to all parties |
| `FullySigned` | All required signers completed the signing step |
| `Closed` | The workflow reached its final state |
| `AffidavitPublished` | An affidavit was generated and is ready for download |


`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:


```json
{
  "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](/products/namirialnotify/dev/callbacks).

### `AdditionalData` fields — per event

Most events include signer details in `AdditionalData`.

The field names `SignerNotificationAddres` and `SignerNotificationAddresType` (both missing the final `s`) and `OutCome` (capital `C`) reflect the actual payload produced by the platform. Use these exact strings when reading from `AdditionalData`.

**`Sent` — signature request sent to one signer**


```json
{
  "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**


```json
{
  "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**


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

**`Rejected` — one signer rejected the document**


```json
{
  "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**


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

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


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

**`AffidavitPublished` — an affidavit is ready**


```json
{
  "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

| `Kind` | What happened | Typical action |
|  --- | --- | --- |
| `Processed` | Document certified, workflow ready | Log and wait for `Sent` |
| `Sent` | Signature request sent to one signer | Log signer notification |
| `Delivered` | Signature request confirmed delivered | Update signer delivery status |
| `Signed` | One signer completed signing | Track per-signer progress |
| `Rejected` | One signer rejected the document | Notify your process owner |
| `FullySent` | All parties notified | Confirm all parties received the request |
| `FullyDelivered` | All parties delivery confirmed | Confirm delivery for all |
| `FullySigned` | All required signers signed | Trigger downstream business process |
| `Closed` | Workflow complete | Check `OutCome` and update your records |
| `AffidavitPublished` | Affidavit ready | Download and store using `AffidavitId` |


### 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](/products/namirialnotify/dev/security-best-practices) for full guidance.

## States reference

| State | Description | Terminal? |
|  --- | --- | --- |
| `Draft` | The EviSign has been staged but not yet submitted | No |
| `Submitted` | The submission was accepted and is being processed | No |
| `Processed` | The document was certified and the workflow was prepared | No |
| `Sent` | Signature requests have been sent to signer(s) | No |
| `Closed` | The workflow reached its final state — no further changes expected | Yes |


`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.

| Outcome | When it is set |
|  --- | --- |
| `None` | Workflow is still active |
| `Signed` | All required signers completed the signing step |
| `Rejected` | At least one required signer rejected the document |
| `Expired` | The configured time to live elapsed before all required signers acted |
| `Cancelled` | The issuer cancelled the signature request |
| `Failed` | A processing error prevented the workflow from completing normally |


## Evidence and affidavits

### When each affidavit is generated

| Affidavit kind | Stage | What it certifies |
|  --- | --- | --- |
| `Submitted` | Processing | Document content and submission metadata at the moment of submission |
| `SubmittedAdvanced` | Processing | Extended submission certification |
| `SignatureRequestDispatched` | Per signer — Sent | That the signature request was sent to a specific signer |
| `SignatureRequestResult` | Per signer — Signed or Rejected | The signer's action (accepted, rejected, or expired) |
| `PartyCommitted` | Per signer — commitment | The signer's explicit commitment action with timestamp and identity details |
| `FinalNotificationDispatched` | Closure | That the final notification was sent after the workflow closed |
| `FinalNotificationResult` | Closure | That the final notification was delivered |
| `Main` | Closure | Main evidence document |
| `Summary` | Closure | Full workflow summary. Must be explicitly requested. |
| `Attachment` | Per attachment | Certifies each attached file |
| `Event` | Per tracked event | Per-event evidence record |
| `Failed` | On failure | Failure details and state at failure time |


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](/products/namirialnotify/issuer/create-evisign)
- [How a recipient receives an EviSign](/products/namirialnotify/recipient/receive-evisign)
- [Services](/products/namirialnotify/services)
- [States and outcomes](/products/namirialnotify/user-guides/states-outcomes#evisign-evidence-lifecycle)
- [Evidence and affidavits](/products/namirialnotify/user-guides/evidences-affidavits)
- [Callbacks and webhooks](/products/namirialnotify/dev/callbacks)