EviNotice

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

EviNotice is the Namirial Notify certified hosted notice service. When you submit a notice, Namirial Notify sends a delivery notification to the recipient via email, SMS, RCS, or WhatsApp, and hosts the certified content on a secure platform page. Every step — delivery, access, reading, acceptance, rejection, or refusal — is recorded as evidence and optionally generates a signed affidavit.

For the API reference, see the EviNotice API.

When to use EviNotice

Use EviNotice when:

• You need controlled access to the content — the recipient must authenticate before reading, using a challenge question, a mobile PIN, or an email PIN.
• You need acceptance or rejection on record — the recipient can explicitly accept, reject, or refuse the notice, generating legally binding evidence of their decision.
• You need to certify what the recipient saw — the notice content is hosted on Namirial Notify and certified there, so the evidence covers both delivery of the notification and the recipient's interaction with the content.
• You need recipient identity verification — QERDS-level certifications can require government-issued identity verification before the recipient can read the notice.

Use EviMail instead when the certified content should arrive directly in the recipient's inbox without requiring them to follow a link. Use EviSMS when the certified communication is the SMS message itself rather than a hosted document.

How the pieces fit together

An EviNotice involves two distinct layers:

1. The notification channel — how the platform alerts the recipient. This can be email, SMS, RCS, or WhatsApp. The notification contains a secure link to the hosted notice.
2. The hosted notice — the actual certified content, living on Namirial Notify. The recipient clicks through to read it, and all on-platform interactions are recorded as evidence.

This separation is why EviNotice has more lifecycle states than EviMail or EviSMS: Delivered refers to the notification reaching the recipient's device; Received refers to the recipient following the link; Read refers to the recipient opening the content on the platform.

How EviNotice works

Lifecycle overview

Key state transitions

Submitted → Processed — Namirial Notify validates the attachments, certifies the content, and prepares the notice for dispatch. If an attachment is invalid (corrupted or password-protected), the notice transitions directly to Failed then Closed without being dispatched.

Processed → Dispatched → Sent — Once processing is complete, Dispatched marks the point where the platform has run all its checks and accepted responsibility for the communication; the notification is not yet sent, so DispatchedOn typically matches ProcessedOn to the second. Sent is recorded once transmission is confirmed by the remote system, so SentOn is always equal to or later than DispatchedOn.

Sent → Delivered — A delivery confirmation is received from the channel. For email this is a delivery notification from the recipient's mail server; for SMS, RCS, and WhatsApp this is an operator acknowledgement.

Delivered → Received — The recipient clicks the secure link in the notification. This fires before the recipient has authenticated or read the content. Received is specific to EviNotice — it does not exist in EviMail or EviSMS.

Received → Read — The recipient completes any required authentication and opens the notice content on the hosted page.

Read → Replied — If commitment is configured, the recipient accepts or rejects the notice. When the lifecycle closes, the final outcome is Accepted or Rejected.

Any state ≥ Dispatched → Closed (Refused) — When AllowRefusal is enabled, the recipient can refuse the notice without opening the hosted content. The lifecycle ends immediately with outcome Refused.

Submit a certified notice

POST /v2/EviNotice/Submit

Returns { "Id": "<uuid>" } on success. Note that Id is PascalCase, unlike the camelCase eviId returned by EviMail and EviSMS v1 endpoints.

Required fields

Useful fields you should configure

• LookupKey — your own correlation key, filterable in Query. No uniqueness enforced server-side — make it unique within your domain.
• IssuerLegalName — the legal name of the sending organisation, recorded in the certification evidence.
• RecipientDisplayName — the display name shown to the recipient in the delivery notification.
• RecipientLegalName — the legal name of the recipient, recorded in the evidence.
• CertificationLevel — the legal framework applied. Supported values include Standard, Advanced, QERDS, and regional variants such as Standard_EU, Advanced_EU, QERDS_ES, or QERDS_IT. Available levels depend on your account subscription — submitting an unsupported level returns 400. See Certification levels for the full list and QERDS profile details.
• TimeToLive — minutes the platform will attempt delivery and keep the notice accessible. Range: 60–86,400 (1 hour to 60 days). Defaults to the account-configured value when omitted.
• Language — language for the delivery notification and hosted notice UI. Accepted values: ca, de, en, es, fr, it, pt, pt-BR, ro.
• AffidavitLanguage — language for generated affidavit PDFs. Accepts el (Greek) in addition to the Language values.
• NotificationLayout — visual layout of the hosted notice page: Certified (default, Namirial Notify branded) or AsIs (plain, without certification branding). EviMail exposes the same concept through DeliveryAppearance.
• OnlineRetentionPeriod — number of years the notice and its evidence remain accessible online. Valid values depend on your subscription.
• LandingPageInfoText — additional text shown on the EviNotice landing page before the recipient opens the hosted content.

Notification channels

NotificationChannels controls which channels are used to alert the recipient. Supported values: SMS, WhatsApp, RCS, Email.

When RecipientAddress is an email address, Email is the default channel. When it is a mobile number, SMS is the default. Use NotificationChannels to add or override channels.

Recipient authentication

DeliverySignMethod controls how the recipient authenticates before accessing the hosted notice content.

MobilePinChannels configures PIN delivery attempts as an array of arrays. Each outer element is one attempt; all channels in the inner array are tried simultaneously for that attempt:

"MobilePinChannels": [
  ["SMS", "RCS", "WhatsApp"],
  ["SMS", "RCS", "WhatsApp"],
  ["SMS", "RCS", "WhatsApp"]
]

Supported channel values: SMS, RCS, WhatsApp.

QERDS recipient identity

For QERDS-certified EviNotices, recipient legal-ID verification is required before the hosted notice is shown. QERDS submissions also require the issuer account and site to be provisioned for the QERDS API flow, including the required client-certificate or two-factor authentication configuration. Send QERDS API calls to the Namirial Notify API host for the environment, not to the customer's site host.

• RecipientLegalIdRequired — must be true for QERDS notices.
• RecipientLegalIdKind / RecipientLegalIdValue — optionally predefine the legal document type and value the recipient must confirm.
• QERDSEnrollmentAllowed — when true, recipients without a registered identity can complete enrollment during the same notice flow.
• QERDSEnrollmentProfile — selects the enrollment profile to use for in-flow registration.
• QERDSIdentityTenant — identifies the tenant or identity context used by the QERDS verification flow.

For QERDS_ES, the delivery sign method must match the recipient address channel: email recipients use EmailPin and mobile recipients use MobilePin, with the fixed PIN destination matching RecipientAddress.

For QERDS_IT, the issuer must have the QERDS_IT identity-verification schema enabled. Email recipients must use a mobile PIN destination (DeliverySignMethod: MobilePin plus DeliverySignFixedMobile), while mobile recipients must use an email PIN destination (DeliverySignMethod: EmailPin plus DeliverySignFixedEmail). RecipientLegalIdKind and RecipientLegalIdValue are required and must validate together.

If the recipient is not yet registered, the platform redirects them to the enrollment flow only when QERDSEnrollmentAllowed is enabled and the supplied QERDSEnrollmentProfile is configured on the site. Otherwise, access is blocked until the issuer resolves the identity requirement.

Commitment and refusal

CommitmentChoice controls whether the recipient can accept or reject the notice. Cannot be changed after submission.

Additional commitment fields:

• CommitmentCommentsAllowed — when true, the recipient can add a free-text comment with their decision.
• AcceptReasons / RejectReasons — predefined reasons the recipient can select from.
• RequireAcceptReason / RequireRejectReason — force the recipient to select or enter a reason before committing.

EviMail and EviSMS expose the same concept through a field named CommitmentOptions.

AllowRefusal is separate from commitment. When true, the recipient can refuse the notice without opening the hosted content after following the secure link. In standard non-QERDS flows, refusal is presented on the landing step before the content is shown. Refusal closes the notice immediately with outcome Refused and generates a Refused affidavit if Refused is included in AffidavitKinds.

Affidavit configuration

AffidavitKinds selects which evidence events generate affidavits. For the full catalog and the lifecycle moment each kind is tied to, see Evidence and affidavits.

Callbacks

• PushNotificationUrl — HTTPS endpoint to receive state callbacks. Must be publicly reachable from Namirial Notify infrastructure.
• PushNotificationFilter — state transitions that trigger a callback. Valid values: Processed, Dispatched, Sent, Delivered, Received, Read, Replied, Failed, Closed, AffidavitPublished. AffidavitPublished is a platform meta-event that fires when affidavit generation completes — it is not a lifecycle state. Received is unique to EviNotice.
• PushNotificationExtraData — arbitrary string echoed back in every callback for this notice. Use it to embed a routing key or internal record ID so your callback handler can route the event without a separate lookup.

Idempotency

Include X-Evi-IdempotencyToken on every Submit. Use a UUID and keep it constant across retries. A replay of a previously 200 OK submission returns 202 Accepted; the notice is not resubmitted.

Attachments

Include files in the hosted notice via the Attachments array. Each attachment requires Filename, MimeType, and base64-encoded Data.

Limits: maximum 15 attachments per submission; maximum 8 MB per attachment; maximum 25 MB total across all attachments.

Use ContentId to reference an attachment inline in the Body HTML using cid: syntax. Set IncludeOnAffidavits: true to include the attachment reference in generated affidavits.

Reminders

EviNotice supports automatic reminder notifications sent to the recipient if the notice has not been acted on. Configure via the Reminders object:

What the recipient sees

The recipient's experience depends on the configured DeliverySignMethod.

WebClick

The recipient receives a notification (email, SMS, RCS, or WhatsApp) containing a secure link. Clicking the link opens the hosted notice page directly when no additional access step is configured. Appropriate for non-sensitive communications where you need evidence of delivery and access but not identity verification.

Challenge

After clicking the link, the recipient is presented with a challenge question configured in DeliverySignChallenge. They must provide the correct answer (configured in DeliverySignChallengeResponse) before the notice content is revealed. Use when you need to confirm the recipient's identity using information only they would know — a contract reference, last four digits of a document, or similar.

MobilePin

After clicking the link, the recipient is prompted to enter a one-time PIN delivered to their mobile device via the channels configured in MobilePinChannels. If the mobile number for PIN delivery differs from RecipientAddress, configure it in DeliverySignFixedMobile. Each element of MobilePinChannels is one attempt; all channels in that element are tried simultaneously.

EmailPin

After clicking the link, the recipient is prompted to enter a one-time PIN sent to an email address. If the PIN delivery address differs from RecipientAddress, configure it in DeliverySignFixedEmail.

Captcha and QERDS-specific checks

Depending on tenant configuration, the recipient can also encounter a captcha step before the content is displayed.

For QERDS-certified notices with legal-ID verification, the recipient can be asked to confirm a government-issued document number before any other access step. If no verified identity is already registered and in-flow enrollment is enabled, the recipient is redirected to the identity provider and then returned to the notice.

Commitment actions on the hosted page

When CommitmentChoice is not Disabled, the hosted notice page displays the configured action buttons after the recipient has opened the content. If CommitmentCommentsAllowed is true, a comment field is shown alongside the buttons. If AcceptReasons or RejectReasons are configured, the recipient selects from those predefined options rather than typing freely. CommitmentChoiceButtonText and CommitmentChoiceButtonOnly further customize how the commitment control is presented.

Callbacks and what you receive

When a state in PushNotificationFilter is reached, Namirial Notify sends an HTTP POST to PushNotificationUrl with the following JSON payload.

Base payload

AdditionalData fields — always present

AdditionalData fields — per event

Callback reliability

Make your callback handler idempotent, keyed on Identifier — duplicate deliveries will occur. Return 2xx promptly; the platform interprets timeouts as failures and retries. Use PushNotificationExtraData to embed a routing key so your handler can correlate the callback to your internal records without a separate API call.

Securing your callback endpoint

See Security and authentication for callback hardening guidance including signature verification and IP allowlisting.

States reference

On Replied: by default, the notice closes immediately after the commitment is recorded. Some configurations keep tracking open until the TTL elapses. Subscribe to both Replied and Closed if you need to react to the recipient's answer and then mark the lifecycle as final.

On Received vs Read: Received fires when the recipient clicks the link; Read fires when they open the content. A recipient can click the link and abandon the page without reading — both events are recorded independently.

On refusal: when a notice is refused, the state moves directly to Closed with outcome Refused. Refused does not appear as a lifecycle state — it only surfaces as an outcome value.

Evidence and affidavits

AffidavitKinds selects which evidence events generate signed affidavit PDFs. Generation is asynchronous; you receive an AffidavitPublished callback when each affidavit is ready (if AffidavitPublished is in PushNotificationFilter).

When each affidavit is generated

For the legal implications and cross-service comparison of each affidavit type, see Evidence and affidavits.

Querying status

Use the Query endpoint as a fallback when callbacks lag, for point-in-time snapshots, or for batch reconciliation.

POST /v2/EviNotice/Query

EviNotice Query uses cursor-based pagination, unlike the offset-based pagination in EviMail and EviSMS. Pass Cursor from the previous response to retrieve the next page. When Cursor is absent from the response, there are no further results.

Response field names are PascalCase (Cursor, Results) rather than the camelCase used by EviMail and EviSMS v1 query endpoints. Deserialise accordingly if sharing response models across services.

Common filters:

• LookupKeys: ["your-key"] — fetch by your correlation key.
• State: "Closed" — fetch only closed notices.
• Outcome: "Refused" — fetch by final outcome.
• Limit — maximum results per page (1–100, default 100).

To retrieve affidavit or attachment metadata, use the Get endpoint (GET /v2/EviNotice/{Id}) with IncludeAffidavits=true or IncludeAttachments=true. To download all affidavits or attachments as a ZIP file, use the dedicated download endpoints.

First-call walkthrough

What you need

• Namirial Notify credentials (username and password)
• A recipient email address or mobile number for testing
• An HTTPS endpoint to receive callbacks (or use a tool like Webhook.site for initial testing)

Step 1 — Submit your first notice

POST /v2/EviNotice/Submit
Authorization: Basic <base64(username:password)>
Content-Type: application/json
X-Evi-IdempotencyToken: <uuid>

{
  "Subject": "Test certified notice",
  "Body": "<p>This is a test certified notice. Please read and acknowledge.</p>",
  "RecipientAddress": "recipient@example.com",
  "LookupKey": "test-001",
  "CertificationLevel": "Standard_EU",
  "DeliverySignMethod": "WebClick",
  "NotificationLayout": "Certified",
  "Language": "en",
  "AffidavitKinds": ["Submitted", "DeliveryResult", "Read", "Closed"],
  "PushNotificationUrl": "https://your-endpoint.example.com/callbacks",
  "PushNotificationFilter": ["Sent", "Delivered", "Received", "Read", "Closed", "AffidavitPublished"]
}

A 200 OK response contains { "Id": "<uuid>" }. Store the Id — you will use it to poll status and retrieve evidence.

Step 2 — Verify the notice progresses

Query by Id to confirm the notice moves through Submitted → Processed → Dispatched → Sent:

POST /v2/EviNotice/Query
Authorization: Basic <base64(username:password)>
Content-Type: application/json

{
  "LookupKeys": ["test-001"]
}

Or retrieve it directly:

GET /v2/EviNotice/<Id>
Authorization: Basic <base64(username:password)>

Step 3 — Follow the notice as the recipient

Open the delivery email in the recipient's inbox, click the secure link, and read the notice. Verify that:

• A Received callback fires when the link is clicked
• A Read callback fires when the notice is opened
• The notice state in Query advances to Read

Step 4 — Confirm closure and download the affidavit

After the notice closes, retrieve the affidavit:

GET /v2/EviNotice/<Id>/Affidavits
Authorization: Basic <base64(username:password)>

This returns a ZIP file containing all generated affidavit PDFs. Verify the affidavit content covers the lifecycle events you configured in AffidavitKinds.

Step 5 — Test the failure path

Submit a notice with an invalid or encrypted PDF attachment and set IncludeOnAffidavits to true for that attachment. Confirm that:

• The notice reaches Failed then Closed with Outcome: Failed
• A Failed callback fires to your endpoint
• The Closed callback includes Outcome: Failed in AdditionalData

Integration checklist

• Set LookupKey on every Submit and persist Id from the response.
• Send X-Evi-IdempotencyToken (UUIDv4) on every Submit. Treat 202 Accepted as success.
• Choose DeliverySignMethod deliberately — WebClick for low-friction; MobilePin or Challenge for sensitive content.
• Subscribe only to the callback kinds you act on. Received and Read are unique to EviNotice — include them if your flow depends on distinguishing link-click from content-open.
• Make your callback handler idempotent, keyed on Identifier.
• Store the raw callback body before parsing.
• Include AffidavitPublished in PushNotificationFilter if you download affidavits programmatically — it tells you exactly when each affidavit is ready.
• If using CommitmentChoice, test both the accept and reject paths in pre-production.
• If using AllowRefusal, subscribe to Closed with outcome Refused and handle it as a terminal negative result.
• Include OnDemand in AffidavitKinds at submit time if you plan to call the affidavit request endpoint later — this cannot be added retroactively.
• Remember that EviNotice query responses use PascalCase field names (Cursor, Results, Id) — deserialise separately from EviMail/EviSMS if sharing models.
• Use the GET /v2/EviNotice/{Id}/Affidavits endpoint to download affidavit ZIPs rather than requesting them one at a time.

Troubleshooting

Related

• EviNotice API
• How to create a new EviNotice
• How a recipient receives an EviNotice
• EviMail
• EviSMS
• API documentation
• Callbacks and webhooks
• Security and authentication
• States and outcomes
• Evidence and affidavits