Goal: Choose the right model for how signers hear about an envelope—either Verdocs sends the standard invitation and lifecycle notifications, or your application owns every outbound message while Verdocs still powers signing workflows.

Who this is for: Backend engineers and technical product teams building white-label, embedded, or in-app signing experiences where communication should come entirely from their own platform.

Two notification models

The property no_contact is configured at the envelope-level during creation.

When to use each model

Use Verdocs-managed notifications when

• Verdocs-branded or co-branded email is acceptable
• You want built-in reminders and lifecycle messaging
• You prefer minimal notification infrastructure
• Your application only needs signing workflows, not messaging control

Use no_contact: true when

• Every signer-facing touchpoint must come from your brand
• Signers stay entirely inside your product experience
• Your organization already operates email, SMS, push, or in-app messaging infrastructure
• You need tighter control over notification timing, compliance, or localization

What Verdocs still handles in BYO mode

Setting no_contact: true does not disable the Verdocs signing engine.

Verdocs still manages:

The primary change is that Verdocs suppresses its own recipient-facing notifications for that envelope.

What gets suppressed

When no_contact is enabled:

• invitation emails are not sent
• reminder emails are not sent
• Verdocs-managed SMS notifications are not sent
• completion-style participant notifications are suppressed where applicable

What still works normally

Even with no_contact: true:

• webhooks continue firing
• signing sessions can still be created
• recipients still progress through workflows
• envelope lifecycle events still occur normally

Your application becomes responsible for turning those events into user-facing communication.

Important workflow difference

In the default flow, recipients typically receive a Verdocs-delivered invitation that starts the signing experience. In BYO mode, your application is responsible for:

1. deciding when the signer should act
2. generating or retrieving signing links
3. delivering those links through your own channels

That usually means your backend calls Start Signing Session (or equivalent APIs) and sends the resulting link through your own email, SMS, push, or in-app notification system.

BYO notification flow (no_contact: true)

Step 1 — Create the envelope

Include:

{
  "no_contact": true,
  "name": "Order #4412 — signature required",
  "template_id": "…",
  "recipients": [ … ]
}

The same approach works for both template-based and template-less envelope creation flows. The important part is: no_contact: true.

Step 2 — Subscribe to webhook events

Configure webhook subscriptions for the lifecycle events your application needs.

Typical integrations listen for:

• envelope lifecycle events
• recipient lifecycle events
• completion events
• failure events

**

Your webhook handler should:

1. authenticate the webhook request
2. validate tenant ownership (organization_id)
3. enqueue downstream notification work

Step 3 — Deliver signing links yourself

When recipients should sign:

• create or retrieve a signing session
• generate the signing URL
• send it through your own communication channels

**

Common delivery channels include:

• transactional email
• SMS
• push notifications
• CRM notifications
• in-app inboxes

Step 4 — Handle completion messaging

Verdocs still completes the envelope internally when signing finishes. However, completion emails are also suppressed in BYO mode.

If customers expect messages such as:

• “Your document has been signed”
• “Download your completed agreement”
• “All parties completed signing”

Your application must send those notifications itself. Most teams trigger those messages from webhook events.

Default Verdocs-managed flow (no_contact: false)

When no_contact is omitted or set to false:

• Verdocs sends invitation emails
• Verdocs sends reminders
• Verdocs sends completion notifications according to organization settings
• your integration can still consume webhooks for automation

This is the simplest integration path and usually the best starting point for new implementations.

Typical architecture comparison

Verdocs-managed notifications

Your App
  → Create Envelope
    → Verdocs sends notifications
      → Recipient signs

Bring-your-own notifications

Your App
  → Create Envelope (no_contact: true)
    → Verdocs emits webhooks
      → Your notification service sends links
        → Recipient signs through your experience

Commonly Asked Questions

Can we switch modes after envelope creation?

That depends on your API version and environment policy. Some versions may allow updating no_contact, while others treat it as immutable after creation. For new integrations, treat it as a create-time decision unless your API reference explicitly documents update behavior.

Does no_contact disable webhooks?

No. Webhooks operate independently from notification delivery. You continue receiving lifecycle events normally.

Does no_contact affect legal validity or audit trails?

No. It changes who delivers notifications—not the underlying signing process, audit records, disclosures, or retention behavior.

What about SMS notifications?

If your organization normally uses Verdocs-managed SMS delivery, BYO mode means your application becomes responsible for SMS delivery as well. The same ownership split applies across all signer-facing notification channels.

In Summary

Verdocs-managed notifications (no_contact: false)

Verdocs sends:

• invitations
• reminders
• completion notifications
• other lifecycle communications according to organization settings

This is the simplest operational model.

Bring-your-own notifications (no_contact: true)

Your application owns all signer-facing communication.

Verdocs still powers:

• signing workflows
• sessions
• documents
• webhooks
• audit trails

Use webhooks and signing-session APIs to drive your own branded notification experience.

**Learn More: **Verify signer, Start Signing Session, New Recipient Authentication Options, Understanding Profiles, or “Why do my API calls return the wrong data?” (for org vs recipient mental models)