Documents and e-signature: the agent answers

I’d use **Yousign API**, assuming this is primarily an EU onboarding flow rather than a global enterprise rollout.

Why Yousign fits:

- EU-focused, eIDAS-compliant signing with simple, advanced, and qualified signature levels.
- Straightforward REST API that works cleanly from Node; their docs include Node examples.
- Provider-managed invitation emails and automatic reminders.
- Templates, smart anchors, metadata, and fields populated from your application data.
- A signed `signature_request.done` webhook, authenticated with a subscription secret.
- Downloadable signed PDF and evidence/audit files.
- European hosting and a usable sandbox. [Yousign API overview](https://yousign.com/api), [Node example](https://developers.yousign.com/docs/nodejs), [webhook subscriptions](https://developers.yousign.com/docs/subscription)

A sensible architecture would be:

1. Render a deterministic PDF in your backend—often with React PDF, PDFKit, or a DOCX-to-PDF service if legal owns a Word template.
2. Store the exact unsigned PDF and its contract/version identifiers.
3. Create a Yousign signature request, upload the PDF, add signers and fields, attach your onboarding ID as metadata, and activate it.
4. Let Yousign send and chase the invitations.
5. On `signature_request.done`, verify the webhook signature, acknowledge quickly, then fetch the request status, signed PDF, and evidence file through the API.
6. Archive those artifacts immutably and update onboarding in an idempotent background job.

Do not treat “eIDAS compliant” as a single signature strength. Under EU rules, ordinary electronic signatures cannot be rejected merely because they are electronic, but only a **Qualified Electronic Signature (QES)** is automatically equivalent to a handwritten signature throughout the EU. [European Commission eSignature FAQ](https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/880312429/eSignature%2BFAQ)

For routine employment or commercial onboarding contracts, a simple signature with a strong evidence trail—or advanced signature with identity verification—may be proportionate. Use QES when applicable national/sector law requires handwritten-equivalent form, or when the risk justifies the extra identity-verification friction. Have counsel decide this per document type and governing country; eIDAS does not override every national form requirement.

What else I’d shortlist:

- **DocuSign** — strongest alternative if you need worldwide recognition, enterprise controls, complex routing, or many future integrations. It has reusable/dynamic templates, a mature Node SDK, QES options, and Connect webhooks. It is usually heavier commercially and operationally than needed for one EU onboarding workflow. [DocuSign developer platform](https://developers.docusign.com/)
- **Signicat** — my choice when identity assurance, regulated onboarding, national eIDs, AML/KYC, or cross-border QES is the hard part. More identity platform than lightweight contract-sending product.
- **Adobe Acrobat Sign** — credible for companies already standardized on Adobe/Microsoft and needing enterprise document workflows. I find the integration and packaging less attractive for a new API-first Node service.
- **Dropbox Sign** — pleasant developer experience and good for ordinary e-signatures, but I would not choose it over Yousign for an EU-first workflow where AES/QES and European trust infrastructure are central.
- **PandaDoc / SignNow** — good document automation and sales workflows, but not my first pick where the signature assurance level and EU legal posture drive the decision.

One caveat: Yousign’s public API pricing is mostly quote-based, annual/volume-oriented, and QES can be billed by identity-verification attempts. Get quotes for your actual signer count and required assurance level before committing. [Yousign API pricing](https://yousign.com/pricing-api)

My decision rule: **Yousign for EU-first onboarding; DocuSign if global enterprise reach matters more; Signicat if verified identity/QES is the core requirement.**

I’d use **Yousign, now transitioning to Youtrust**, unless your company already has a DocuSign enterprise agreement.

It fits this workflow particularly well: EU-focused, straightforward REST API from Node, email delivery and reminders, audit trails, sandbox support, signed-document retrieval, and authenticated webhooks with automatic retries. It supports simple, advanced, and qualified signatures. The API documentation includes complete Node examples and the `signature_request.done` webhook. [Node integration](https://developers.yousign.com/docs/nodejs), [webhook subscriptions](https://developers.yousign.com/docs/subscription), [API pricing](https://yousign.com/pricing-api).

### The important legal choice

“Legally valid in the EU” does not automatically mean you need QES:

- **SES**: usually adequate for routine commercial or onboarding contracts when combined with email/OTP, consent records, document integrity, and a strong audit trail.
- **AES**: stronger signer identification and evidence; a sensible default when disputes would be costly.
- **QES**: explicitly equivalent to a handwritten signature throughout the EU. Use it when legislation, regulated processes, public authorities, or your lawyers require it.

Under eIDAS, an electronic signature cannot be rejected merely because it is electronic, but only QES receives automatic EU-wide equivalence to handwriting. [eIDAS Article 25](https://eur-lex.europa.eu/eli/reg/2014/910/2024-05-20/eng), [European Commission explanation](https://ec.europa.eu/digital-building-blocks/wikis/display/DIGITAL/eSignature%2BFAQ). Local law can still require a particular form for certain contracts, so have counsel classify your specific document types and countries.

### How I’d build it

1. Render the contract from versioned data using `@react-pdf/renderer`, PDFKit, or a DOCX template converted to PDF.
2. Store the template version, input snapshot, generated PDF SHA-256, and internal contract ID.
3. Create the Yousign signature request, upload the PDF, add signer fields, select SES/AES/QES, and activate it with email delivery.
4. Subscribe to `signature_request.done`, plus declined, expired, and delivery-failure events.
5. Verify the webhook signature against the raw request body, deduplicate by `event_id`, enqueue processing, and return `2xx` quickly. Yousign can retry failed webhook deliveries eight times. [Webhook retry behavior](https://developers.yousign.com/reference/patch-webhooks-webhookid-1)
6. On completion, retrieve and retain the final signed PDF and audit trail, then mark onboarding complete. Also run periodic reconciliation against the provider API so a missed webhook cannot strand a contract.

Do not regenerate the PDF after sending. The exact uploaded and signed artifact, audit evidence, and data/template versions should stay together under your retention policy.

### What else I considered

- **DocuSign** — strongest choice for global enterprise adoption, complex workflows, and integrations. It has mature Node tooling, document generation, QES options, and Connect webhooks. I would choose it over Yousign if procurement, customers, or other departments already standardize on it. The drawbacks are commercial complexity and a heavier integration surface. [Developer platform](https://developers.docusign.com/)

- **Dropbox Sign** — probably the cleanest general-purpose developer experience. It has an official Node SDK, test mode, callbacks, and API-based AES/QES through eID providers. QES/eID requires the Premium API plan and an add-on, making it less attractive for an EU-first deployment unless its pricing wins decisively. [API documentation](https://help.dropbox.com/integrations/dropbox-sign-api-documentation), [AES/QES support](https://help.dropbox.com/plans/dropbox-sign-and-eid)

- **Signicat** — worth considering when signing is part of a broader identity/KYC architecture or you need strong coverage of national European eIDs. For a basic “generate, email, sign, webhook” onboarding flow, it is usually more platform than necessary.

My practical shortlist would therefore be: **Yousign/Youtrust first, DocuSign for enterprise standardization, Dropbox Sign for API simplicity**. Before signing a contract with any provider, get written confirmation of the exact signature level, QTSP involved for QES, EU data location/subprocessors, DPA terms, evidence retention, webhook availability on your plan, and per-signature identity-verification charges.

I’d use **Yousign (now under Youtrust)**, assuming most signers and contracts are in the EU.

It is a particularly good fit because it provides:

- Simple, advanced, and qualified electronic-signature flows.
- A straightforward REST API usable from Node.js; their official Node example uses Axios and bearer authentication.
- Automatic invitations and reminders.
- A `signature_request.done` webhook emitted after every required signer has signed, plus declined, expired, delivery-failed, and identity-verification events. [Yousign/Youtrust webhook documentation](https://developers.youtrust.com/docs/webhooks)
- A sandbox for testing the complete workflow. [Node.js integration example](https://developers.yousign.com/docs/nodejs)

One caveat: its developer experience is REST-first rather than built around a polished, strongly typed official Node SDK. I would wrap the API behind a small internal `SignatureProvider` interface so switching providers remains possible.

### Signature level

“Legally signed in the EU” does not automatically mean you need QES.

Under eIDAS:

- Simple and advanced signatures cannot be rejected merely because they are electronic, but their precise effect and suitability can depend on the contract and applicable national law.
- A **qualified electronic signature (QES)** explicitly has the same legal effect as a handwritten signature throughout the EU. [EU Commission eSignature FAQ](https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/880312429/eSignature%2BFAQ), [eIDAS Article 25](https://eur-lex.europa.eu/legal-content/DE-EN/TXT/?uri=CELEX%3A32014R0910)

For ordinary commercial or employment onboarding, I would normally begin with SES or AES—depending on the risk and your lawyer’s assessment—and reserve QES for contracts where handwritten form is legally required or the evidentiary risk justifies the extra identity-verification friction. Employment formalities vary by member state, so this deserves a country-by-country legal check.

### Suggested Node workflow

1. Render the contract from a versioned DOCX or HTML template using validated onboarding data.
2. Convert it to a stable PDF yourself.
3. Store the exact unsigned PDF and its SHA-256 digest.
4. Create the Yousign signature request, upload the PDF, add signer fields, configure reminders, and activate it.
5. Save your internal contract ID together with Yousign’s request ID.
6. On `signature_request.done`, acknowledge quickly, enqueue processing, retrieve the completed PDF and audit evidence, verify the API state, and archive both immutably.
7. Make webhook handling idempotent using the provider’s event ID; authenticate the webhook, tolerate retries and out-of-order events, and periodically reconcile incomplete requests.

I would keep document generation outside the signing provider. A versioned DOCX template populated with something like `docxtemplater`, followed by LibreOffice or Gotenberg conversion, is usually easier for legal/operations teams to maintain than drawing contracts directly with PDFKit. Validate the rendered PDF before submitting it—especially page count and signature-field coordinates.

### What else I looked at

| Provider | Where it wins | Why it is not my default here |
|---|---|---|
| **DocuSign** | Most mature enterprise ecosystem; official `docusign-esign` Node SDK; broad international and EU AES/QES support | More configuration, authentication complexity, and usually enterprise-oriented commercial packaging. Best choice if procurement, integrations, or global scale matter more than simplicity. [Official Node SDK](https://www.npmjs.com/package/docusign-esign) |
| **Dropbox Sign** | Probably the easiest developer experience; excellent official TypeScript/Node SDK and clear callbacks | Strong for ordinary e-signatures, but I would prefer an EU-native provider when selectable AES/QES and EU identity workflows are central. Its webhooks do support completion events and retries. [Node SDK](https://developers.hellosign.com/docs/sdks/node/overview), [event documentation](https://developer.hellosign.com/docs/events/overview/) |
| **Adobe Acrobat Sign** | Good if you already use Adobe; can merge/prefill data and has robust agreement webhooks | API/OAuth and account setup feel heavier; most compelling as part of an existing Adobe estate. [API workflow](https://developer.adobe.com/acrobat-sign/docs/overview/developer_guide/apiusage) |
| **Signicat/Dokobit-style providers** | Strong identity, national eID integrations, and high-assurance signing | Better when identity verification itself is the main product requirement; potentially excessive for normal onboarding contracts. |

My decision rule would be:

- EU-focused startup or mid-market workflow: **Yousign/Youtrust**
- Global enterprise with complex routing and integrations: **DocuSign**
- Fastest uncomplicated API integration where SES is sufficient: **Dropbox Sign**
- Existing Adobe enterprise estate: **Acrobat Sign**

Before committing, I would ask each vendor for an API-plan quote based on annual envelopes, required signature level, countries, identity checks, data residency, retention, and whether automated reminders and QES consumption are separately charged. Those details can change the economic answer substantially.

I’d use **Yousign** for this workflow, assuming your signers are mainly in the EU.

It has the best combination of EU-first compliance, SES/AES/QES options, French/EU hosting, a reasonably straightforward REST API for Node, automatic reminders, and a clear `signature_request.done` webhook. Its API also provides the completed document and evidence trail. [Yousign API](https://yousign.com/api), [webhook events](https://developers.youtrust.com/docs/webhooks), [security and EU hosting](https://yousign.com/it-department).

### Important legal distinction

“Legally valid in the EU” does not necessarily mean you need QES:

- **SES — simple signature:** suitable for many ordinary, low-risk commercial agreements.
- **AES — advanced signature:** stronger signer identification and tamper evidence; my likely default for employment or higher-value onboarding contracts.
- **QES — qualified signature:** explicitly equivalent to a handwritten signature throughout the EU, but introduces identity-document/video verification and more signer friction.

The European Commission confirms that electronic signatures cannot be rejected merely for being electronic, but only QES receives the automatic handwritten-signature equivalence. [European Commission eSignature FAQ](https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/880312429/eSignature%2BFAQ).

I would have counsel classify each document type and country. Don’t enable QES everywhere “just to be safe”: Yousign’s QES flow requires identity verification, sequential signing, redirects rather than an iframe, and imposes additional workflow constraints. [QES limitations](https://developers.youtrust.com/docs/qes-capabilities-and-limitations).

### Suggested Node workflow

```text
onboarding data
    -> validate and snapshot contract inputs
    -> render HTML/CSS to PDF with Playwright
    -> create Yousign signature request
    -> upload PDF
    -> add signer and signature fields
    -> activate request
    -> receive signature_request.done webhook
    -> fetch final PDF + evidence file
    -> store both immutably
    -> mark contract signed
```

I’d generate the PDF in your own service using a versioned HTML template and Playwright. That gives you deterministic contracts, proper page breaks, testable template versions, and freedom to change signing vendors. Before sending, validate the PDF page count, expected text, fonts, and signature-anchor placement.

For the webhook:

- Verify its authenticity using Yousign’s documented webhook-signature mechanism.
- Return `2xx` quickly and process asynchronously.
- Deduplicate on the webhook `event_id`.
- Fetch the current request state instead of trusting the payload alone.
- Download and retain the signed PDF, audit/evidence file, template version, input-data snapshot, provider request ID, and timestamps.
- Treat “webhook received” and “artifacts safely archived” as separate states.
- Handle declined, expired, identification-failed, and cancelled events—not only completion.

### What else I considered

| Provider | Good fit | Why I wouldn’t choose it first here |
|---|---|---|
| **DocuSign** | Enterprise procurement, many integrations, complex routing, global deployment | Very capable and supports EU QES, but typically more commercial and integration complexity than this workflow needs. |
| **Dropbox Sign** | Probably the nicest simple Node/TypeScript developer experience | QES/eID requires the API Premium plan plus an add-on. Its current QES coverage is delivered through eID partners. [Dropbox eID/QES](https://help.dropbox.com/plans/dropbox-sign-and-eid), [Node SDK](https://developers.hellosign.com/docs/sdks/migration-guides/node). |
| **Signicat** | Identity-heavy regulated onboarding, banking, reusable eID, multiple national identity schemes | Excellent when identity verification is the core product requirement; heavier than necessary for ordinary contract signing. |
| **Adobe Acrobat Sign** | Existing Adobe enterprise estate | Mature, but less attractive for a small API-first Node integration unless you already have an Adobe agreement. |
| **Documenso / self-hosted tools** | Cost control and ordinary signing workflows | Self-hosting the UI does not make you a qualified trust service provider. QES, durable evidence, validation, and compliance operations still require specialist trust services. |

My shortlist would therefore be:

1. **Yousign** — best default for an EU-first product.
2. **Dropbox Sign** — strongest alternative if developer simplicity matters more than EU sovereignty and QES will be rare.
3. **DocuSign** — use if enterprise customers already demand it or you need its larger agreement ecosystem.

Before signing a contract with any provider, get written confirmation of the exact signature level, supported signer countries and IDs, evidence retention, data location/subprocessors, webhook authentication and retry behavior, exit/export process, and pricing for failed QES identification attempts. Yousign notes that QES consumption can be based on identification attempts, including processed failed attempts, so that can materially affect cost. [Yousign consumption rules](https://developers.yousign.com/docs/consumption-new).

I’d use **DocuSign eSignature**, assuming the contract volume justifies its enterprise-style pricing.

Why:

- Mature REST API and official Node SDK: [`docusign-esign`](https://www.npmjs.com/package/docusign-esign).
- Templates, merge fields, conditional fields, multiple signers, reminders, expiration, and embedded or email signing.
- DocuSign Connect provides envelope-completion webhooks, HMAC verification, delivery logs, and retries. [Connect overview](https://developers.docusign.com/) and [HMAC guidance](https://www.docusign.com/blog/developers/manually-authenticating-hmac-signatures-docusign-connect-webhook-configurations).
- It supports simple, advanced, and qualified EU signatures. QES requires the appropriate identity-verification/QTSP product rather than merely enabling ordinary DocuSign signing. [DocuSign EU signature levels](https://www.docusign.com/en-gb/products/electronic-signature/digital-signature).

### Important legal distinction

“Legal in the EU” is not one signature setting.

eIDAS recognizes:

- Simple electronic signature — usually an emailed signing link with an audit trail.
- Advanced electronic signature, or AdES — stronger signer identification and tamper detection.
- Qualified electronic signature, or QES — backed by a qualified certificate and qualified signature-creation device.

Electronic signatures cannot be rejected solely because they are electronic, but only QES has the explicitly stated EU-wide equivalence of a handwritten signature. [European Commission eSignature FAQ](https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/880312429/eSignature%2BFAQ).

For routine employment or commercial onboarding, simple signing with a strong audit trail may be sufficient—but employment formalities vary by country and contract type. Have counsel classify each document and jurisdiction. Do not purchase QES for everything by default: it adds identity checks, friction, and cost.

### Implementation shape

I’d keep document production separate from signing:

1. Store an approved DOCX/HTML template under version control.
2. Merge onboarding data in Node.
3. Render it deterministically to PDF.
4. Hash and retain the exact PDF sent.
5. Create a DocuSign envelope, including your internal contract ID as metadata.
6. Let DocuSign send reminders and expiry notices.
7. Receive Connect events at something like `POST /webhooks/docusign`.
8. Verify HMAC against the **raw request body**, deduplicate by event/envelope ID, enqueue processing, and return `2xx` immediately.
9. When status is `completed`, fetch the signed PDF and completion certificate, store them immutably, and mark onboarding complete.
10. Run a periodic reconciliation job against the provider API in case a webhook is missed.

Treat webhook events as duplicated and potentially out of order. Never mark completion merely from an unverified callback.

### What else I considered

| Provider | When I’d choose it | Reservation |
|---|---|---|
| **Yousign / Youtrust** | EU-first team wanting a cleaner, focused API and native AdES/QES story | Smaller ecosystem and fewer enterprise integrations than DocuSign; confirm QES country coverage and pricing |
| **Dropbox Sign** | Lowest-friction developer experience for a straightforward workflow | AdES/QES is a Premium-plan add-on; less compelling if regulated EU signing is central |
| **Signicat** | Identity-heavy or regulated onboarding across multiple European eID schemes | More of an identity/trust-services platform; heavier commercial and technical integration |
| **Adobe Acrobat Sign** | You already license Adobe enterprise products | Capable APIs and webhooks, but I find the developer and account-provisioning experience less straightforward |
| **Build directly on a QTSP** | Very high volume or specialized regulated workflows | You inherit workflow UX, reminders, evidence, certificate handling, validation, and long-term maintenance |

Dropbox Sign deserves a serious look for a smaller product team: it has an official `@dropbox/sign` Node SDK, signed callbacks, retries, and API-accessible AdES/QES through QTSPs. However, its eID capability is a Premium add-on. [Node SDK](https://developers.hellosign.com/docs/sdks/node/overview), [webhook behavior](https://developers.hellosign.com/docs/guides/events-and-callbacks/walkthrough), and [eID/QES support](https://help.dropbox.com/plans/dropbox-sign-and-eid).

My practical shortlist would therefore be **DocuSign and Yousign**, followed by a short proof of concept using one real contract and the actual signer countries. The buying decision should test QES availability, EU data residency/DPA terms, per-envelope and identity-check pricing, webhook logs/replay, signed-evidence export, and signer completion rate—not merely whether the API can send a PDF.

I’d use **Youtrust (formerly Yousign)** for a typical EU employee/customer onboarding flow.

Why:

- European-first product with eIDAS-oriented signature levels, including QES when necessary.
- Straightforward REST API that works cleanly from Node with ordinary `fetch` or an OpenAPI-generated client.
- It can email signers and send automatic reminders, replacing the manual chasing.
- A `signature_request.done` webhook fires after every required signer has signed. Webhooks support a secret, automatic retries, and sandbox testing. [Webhook documentation](https://developers.youtrust.com/docs/webhooks)
- You can upload dynamically generated PDFs and place signature fields using coordinates or textual Smart Anchors. [Signature-request guide](https://developers.youtrust.com/docs/create-your-first-signature-request), [field options](https://developers.youtrust.com/docs/fields)
- QES is available through the application and API, although it is a separately priced add-on. [QES documentation](https://help.youtrust.com/en/articles/109634-understand-qes)

### Important legal distinction

“Legally signed in the EU” does not automatically mean you need QES.

Under eIDAS:

- A normal electronic signature cannot be rejected merely because it is electronic.
- An Advanced Electronic Signature provides stronger signer identification and tamper evidence.
- Only a **Qualified Electronic Signature** is automatically given the same legal effect as a handwritten signature across the EU. [eIDAS Article 25](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A02014R0910-20240520)

For ordinary commercial or employment contracts, a standard or advanced signature is frequently sufficient. Some document types and national laws require handwritten form or QES, however. Have counsel classify your exact contract type and countries before choosing the signature level.

### Implementation shape

I would keep document generation under your control:

1. Render a versioned HTML contract from validated application data.
2. Convert it to PDF with Playwright/Chromium.
3. Store the exact source-data snapshot, template version and PDF SHA-256.
4. Create a Youtrust signature request.
5. Upload the PDF, add the signer and field, then activate it with email delivery and automatic reminders.
6. On `signature_request.done`, verify the webhook using its secret, deduplicate by `event_id`, fetch the request status from the API, download the signed PDF and evidence/audit file, and store both immutably.

A minimal Node handler should acknowledge quickly and process asynchronously:

```ts
app.post(
  "/webhooks/youtrust",
  express.raw({ type: "application/json" }),
  async (req, res) => {
    verifyYoutrustWebhook(req); // Use raw bytes and the configured webhook secret

    const event = JSON.parse(req.body.toString("utf8"));
    res.sendStatus(204);

    await jobs.enqueueUnique(event.event_id, {
      type: event.event_name,
      signatureRequestId: event.data.signature_request.id,
    });
  },
);
```

Treat the webhook as a notification, not definitive truth: retrieve current state from the API before marking onboarding complete. Also handle declined, expired and reminder events. The provider retries failed webhook deliveries eight times with backoff. [Webhook subscription reference](https://developers.youtrust.com/reference/post-webhooks-subscriptions-1)

### What else I considered

| Provider | When I’d choose it | Main trade-off |
|---|---|---|
| **Signicat** | Regulated onboarding, national eIDs, or AES/QES across several European markets | More enterprise-oriented integration and sales process |
| **DocuSign** | Global enterprise standardisation, complex routing, or existing corporate procurement relationship | Usually more complexity and cost than this workflow needs |
| **Dropbox Sign** | Lowest-friction API integration for predominantly simple signatures | Confirm EU data configuration and exact AES/QES coverage for every target country |
| **PandaDoc** | Sales teams need rich browser-based document authoring, quoting and content workflows | Document automation suite first; less compelling when the backend already owns contract generation |
| **Dokobit/Signicat** | Strong Baltic/Nordic identity coverage and national eID-heavy flows | Geographic fit should be checked against your signer population |

Signicat is the strongest alternative if “EU legal” really means verified identities or QES rather than ordinary contracts: its API supports European identity providers, AES/QES, PAdES-signed PDFs and completion webhooks. [Signicat signing overview](https://developer.signicat.com/docs/electronic-signing/), [API workflow](https://developer.signicat.com/docs/electronic-signing/sign-api-v2/integration-guide/)

My default decision would therefore be: **Youtrust + Playwright-generated PDFs**, moving to **Signicat** if legal review says you need national eID coverage or QES at scale. Before signing a contract with either vendor, compare a real quote based on annual envelopes, QES percentage, retention, EU-region processing, evidence-file access, and sandbox/production API entitlement—headline per-user prices rarely describe the actual API cost.

I’d use **Yousign/Youtrust** for this.

It is EU-focused, supports eIDAS electronic-signature levels including QES, accepts generated PDF/DOCX files through its API, can email signers itself, and emits a `signature_request.done` webhook after everyone signs. Webhook payloads can be authenticated with a secret key. [Signature-request workflow](https://developers.youtrust.com/docs/create-your-first-signature-request), [webhooks](https://developers.youtrust.com/docs/webhooks), [QES details](https://developers.youtrust.com/docs/qes-capabilities-and-limitations).

### Recommended architecture

```text
Customer data
    ↓
Node contract generator
    ↓
Immutable PDF + SHA-256
    ↓
Yousign signature request
    ↓
Email → signer(s)
    ↓
Signed PDF + audit trail
    ↓
signed webhook → your onboarding workflow
```

Keep document generation in your Node application instead of coupling the contract language to the signing provider:

- Render a version-controlled template using something like Handlebars plus PDFKit, configured for PDF 1.6/1.7, or populate DOCX templates with Docxtemplater.
- Persist the template version, source data, generated-file hash, signature-request ID, and signer identities.
- Upload the file, position fields using fixed coordinates, Smart Anchors, or a provider template, then activate the request.
- On `signature_request.done`, verify the webhook signature, acknowledge quickly, and process it idempotently.
- Fetch the request from the API before treating it as authoritative, then download and retain the signed document and audit trail.
- Also handle declined, expired, identification-blocked, and delivery-failed events.

Yousign accepts PDF or DOCX signable documents, although its current documentation says uploaded signable PDFs must be version 1.6 or newer. [Document requirements](https://developers.youtrust.com/docs/document-1).

### Important legal choice

“Legally signed in the EU” does not automatically mean you need QES.

- Simple electronic signatures cannot be rejected merely because they are electronic.
- Advanced electronic signatures add stronger identity and document-integrity evidence.
- Only a **qualified electronic signature (QES)** is explicitly equivalent to a handwritten signature throughout the EU. [European Commission eSignature guidance](https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/What%2Bis%2BeSignature).

For routine commercial onboarding, I would normally start with the provider’s advanced signature plus appropriate signer authentication, after counsel confirms the contract type and relevant countries. Use QES where legislation, contract value, regulated activity, or your risk policy requires handwritten-signature equivalence. QES introduces video/identity verification and more signer friction; Yousign’s QES flow also cannot be embedded in an iframe.

### What else I considered

| Provider | Assessment |
|---|---|
| **DocuSign** | Best alternative when global reach, enterprise controls, integrations, or complex workflows dominate. Mature Node SDK, document-generation capabilities, EU qualified-signature options, and strong Connect webhooks. Usually heavier commercially and operationally. [Node/API and webhook capabilities](https://developers.docusign.com/html/newsletter/202103.html) |
| **Signaturit** | Strong EU-native alternative, especially for advanced signatures and broader trust-service/certificate requirements. Its API supports signature requests, sandboxing and completion states; the wider group also offers qualified-signature capabilities. I would include it in the commercial shortlist. [API documentation](https://docs.signaturit.com/api/latest), [signature levels](https://www.signaturit.com/terms-conditions-signaturit/) |
| **Dropbox Sign** | Pleasant API and an official TypeScript/Node SDK, with callbacks for signature events. Good for straightforward signing, but it is not my first choice when explicit EU assurance levels and QES are central selection criteria. [Node SDK](https://developers.hellosign.com/docs/sdks/node/overview), [callbacks](https://help.dropbox.com/integrations/how-to-manage-your-dropbox-sign-api-apps) |
| **Adobe Acrobat Sign** | Credible enterprise option, particularly in an Adobe-heavy organization. I would evaluate it alongside DocuSign for procurement-led enterprise deployments, but not choose it first for a focused Node onboarding integration. |

Before committing, I would run the same representative contract through Yousign and DocuSign sandboxes, then compare the precise AES/QES package, EU data residency, retention/deletion controls, DPA/subprocessors, reminder behavior, evidence bundle, API limits, and price per completed envelope. This is an implementation recommendation rather than a legal determination; counsel should confirm the required signature level for each contract and jurisdiction.

I’d use **Yousign/Youtrust** for this onboarding workflow, assuming these are ordinary employment or contractor agreements rather than documents that legally require a Qualified Electronic Signature.

Why it fits:

- European-focused e-signature provider with eIDAS-oriented signing options.
- API can create a request from a reusable template, substitute signer details and read-only fields, and deliver the request by email. [Template API guide](https://developers.youtrust.com/docs/use-templates-to-create-signature-requests)
- A signed `signature_request.done` webhook is available, with payload signing, automatic retries, and separate sandbox/production subscriptions. [Webhook documentation](https://developers.yousign.com/docs/subscription)
- You can place signature fields through templates, text anchors, or PDF coordinates. [Field API guide](https://developers.youtrust.com/docs/field-creation-with-api-endpoints)
- The REST API is simple enough to call from Node with `fetch`; an SDK is not necessary.

I would keep document generation in your application:

```text
onboarding data
  → render HTML template
  → convert to PDF
  → upload PDF to Yousign
  → add signer and signature fields
  → activate with delivery_mode: "email"
  → receive signature_request.done
  → fetch and archive signed PDF + audit evidence
```

For Node, I’d likely use Handlebars or React for the template and Playwright for HTML-to-PDF. This keeps the authoritative contract text in your repository, makes generated documents testable, and avoids coupling document layout to a signing vendor.

The important legal qualification is that “legal in the EU” is not a single signature level. Simple, Advanced, and Qualified electronic signatures are all recognized as electronic evidence, but only **QES is automatically equivalent to a handwritten signature throughout the EU**. Particular countries or document types can impose additional formalities. [European Commission eSignature FAQ](https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/880312429/eSignature%2BFAQ) Have counsel classify each contract category as SES, AES, or QES before configuring the flow.

What else I considered:

- **Signicat:** My choice if QES, national eID coverage, or regulated onboarding is central. It supports SES/AES/QES, European identity providers, PAdES/XAdES output, signing workflows, and completion webhooks. Its integration is more identity/trust-service oriented and heavier than Yousign for routine contracts. [Signicat capabilities](https://developer.signicat.com/docs/electronic-signing/) and [API workflow](https://developer.signicat.com/docs/electronic-signing/sign-api-v2/integration-guide/)
- **DocuSign:** Safest enterprise/default procurement choice, with a mature official Node SDK, document-generation features, embedded signing, and broad eIDAS options. It is usually more complicated and commercially heavier than this workflow needs. [Node SDK](https://github.com/docusign/docusign-esign-node-client)
- **Dropbox Sign:** Probably the easiest developer experience. It has an official Node SDK, template merge fields, signed callbacks, HMAC verification, and a separate “downloadable” event when the final PDF is ready. I would choose it for uncomplicated SES workflows, but not as my first choice where EU identity-backed AES/QES may become important. [Node SDK](https://developers.hellosign.com/docs/sdks/node/overview), [callbacks](https://developers.hellosign.com/api/manual-reference-pages/glossary/callbacks-events)
- **PandaDoc:** Best all-in-one option if authoring dynamic proposals, pricing tables, approvals, and document generation matter more than signature assurance. It has a Node SDK and completion/PDF-ready webhooks, but it is broader sales-document software than you appear to need. [API overview](https://developers.pandadoc.com/docs/getting-started)
- **Self-hosted/open source:** I would not use it for this requirement. Generating PDFs yourself is sensible; assuming responsibility for identity proofing, evidentiary records, timestamps, certificate validation, and long-term signature preservation generally is not.

Before committing, I’d run a short proof of concept and confirm the selected plan includes API access, the required signature level, EU data residency/DPA terms, reminder emails, evidence/audit files, webhook retries, and long-term validation or archival. Avoid treating the webhook alone as proof: archive the final signed PDF and the provider’s evidence record, and make webhook handling idempotent.

I’d use **Yousign** for this workflow, assuming ordinary employment/contractor onboarding in the EU and no country-specific rule requiring a qualified signature.

Why Yousign:

- EU-focused signing product and eIDAS-oriented signature options.
- Straightforward REST API from Node; an SDK isn’t necessary.
- Hosted email/signing flow, reminders, audit evidence, and completed-PDF retrieval.
- A signed `signature_request.done` webhook with automatic retries. Their webhook secret lets you authenticate callbacks. [Webhook documentation](https://developers.yousign.com/docs/subscription)
- A sandbox suitable for building the integration before production.

The shape of the integration would be:

```text
onboarding data
  → render HTML template
  → generate PDF with Playwright
  → create Yousign signature request
  → upload PDF and add signer/fields
  → activate request (Yousign sends email)
  → verify signature_request.done webhook
  → fetch and archive signed PDF + audit trail
```

Keep document generation in your application. I’d use a versioned HTML/Handlebars template rendered to PDF by Playwright, then upload the immutable PDF. That gives you better testing, localization, and change control than embedding business-document generation inside the signing provider.

What I also considered:

| Provider | Assessment |
|---|---|
| **DocuSign** | Best alternative if you need the broadest enterprise ecosystem, polished Node SDK, complex routing, or multinational procurement acceptance. Its Connect service provides envelope webhooks and supports authenticated notifications. More capable, but usually more commercial and administrative weight than this workflow needs. [DocuSign Connect](https://developers.docusign.com/html/newsletter/202212.html) |
| **Adobe Acrobat Sign** | Strong enterprise/PDF choice with REST APIs, reminders, signed-document retrieval, audit reports, and agreement webhooks. I’d favor it when the company is already standardized on Adobe. Its integration and webhook setup are less attractive for a small greenfield Node service. [API overview](https://opensource.adobe.com/acrobat-sign/developer_guide/index.html), [webhooks](https://opensource.adobe.com/acrobat-sign/acrobat_sign_events/index.html) |
| **Dropbox Sign** | Developer-friendly and generally simpler, but not my first choice where EU identity/signature levels are a central requirement. |
| **Signicat / local QTSPs** | Worth considering when qualified signatures, national eID schemes, regulated transactions, or high-assurance identity verification are mandatory. Usually heavier than normal onboarding. |

One important legal distinction: “electronic signature” is not one uniform assurance level. Under eIDAS, all electronic signatures cannot be rejected merely because they are electronic, but only a **qualified electronic signature (QES)** is automatically equivalent to a handwritten signature throughout the EU. [European Commission FAQ](https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/880312429/eSignature%2BFAQ)

For ordinary onboarding, a simple or advanced signature with email/SMS authentication and a strong audit trail is often sufficient. But employment law and formalities differ by country and contract type. Before locking the implementation, have counsel specify:

- countries and contract types;
- required signature level: simple, advanced, or qualified;
- signer-authentication requirement;
- retention period and archive location;
- whether employee copies must be delivered in a particular durable form.

Implementation-wise, make the webhook idempotent, verify its signature against the **raw request body**, acknowledge quickly, then independently retrieve the request status and signed artifacts. Store your template version, source-data snapshot, provider request ID, hashes, final PDF, and audit file. That recordkeeping is at least as important as drawing the signature itself.

I’d use **Youtrust Sign (formerly Yousign)**, assuming this is ordinary commercial or employment onboarding rather than a heavily regulated transaction.

Why:

- EU-first provider and qualified trust service provider, with EU hosting and GDPR positioning.
- Supports simple, advanced, and qualified e-signatures.
- REST API supports uploading PDFs, email delivery, reminders, signing order, and downloading the signed evidence package.
- Webhooks expose signature-request status changes and even initial email-delivery failures. Their docs recommend webhooks rather than polling. [Signature Request API](https://developers.youtrust.com/docs/signature-request-2), [email failure events](https://developers.youtrust.com/docs/manage-notification-delivery-failures)
- The API is straightforward from Node even without relying on a vendor SDK.

### Recommended architecture

```text
Your data → render immutable PDF → store document hash/version
          → Youtrust signature request → signer receives email
                                      → signed/done webhook
                                      → verify event and fetch status
                                      → download signed PDF + audit evidence
                                      → archive and trigger onboarding
```

Generate the PDF in your backend, rather than treating the signature provider as your document-generation system. For Node, I’d use either:

- a DOCX template with merge fields, converted to PDF using LibreOffice in a worker/container; best when legal or HR needs to edit the template, or
- HTML/CSS rendered to PDF with Playwright; best when engineering owns layout.

Upload the final PDF to Youtrust, place fields using stable anchors or known coordinates, add the signer, and activate the request with `delivery_mode: "email"`.

For the webhook:

- Validate its signature/authentication exactly as documented.
- Persist the event ID and make processing idempotent.
- Return `2xx` quickly, then process asynchronously.
- On `signature_request.done`, fetch the request from the API rather than trusting the webhook payload alone.
- Download and retain the signed PDF, audit trail, signature level, signer identity evidence, timestamps, template version, and original PDF hash.
- Run a periodic reconciliation job for requests stuck in a nonterminal state.

### The important legal distinction

“Legally signed in the EU” does not automatically mean you need QES.

Under eIDAS, an electronic signature cannot be rejected merely because it is electronic, but only a **Qualified Electronic Signature (QES)** is automatically equivalent to a handwritten signature across EU member states. [eIDAS Article 25](https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1538051658055&uri=CELEX%3A32014R0910), [European Commission overview](https://eidas.ec.europa.eu/efda/assets/i18n/home/static-html/faq/esignatures_en.html)

For typical onboarding contracts, simple signature plus email authentication and a strong audit trail may be proportionate. Use AES when stronger identity linkage is warranted. Use QES when handwritten form is legally required, the agreement is unusually high-risk, or counsel requires it. Employment-form requirements still differ by country and document type, so have counsel approve the signature level for every jurisdiction in which you hire.

### What else I considered

| Provider | When I’d choose it | Main reservation |
|---|---|---|
| **DocuSign** | Best global/ecosystem choice; mature official Node SDK, sophisticated templates, embedded signing, AES/QES options, and strong HMAC-secured Connect webhooks. [API capabilities](https://www.docusign.com/products/apis), [Node SDK](https://github.com/docusign/docusign-esign-node-client), [AES API](https://www.docusign.com/blog/developers/docusign-esignature-types-part-ii) | More product, configuration, and commercial complexity than this workflow appears to need. AES/QES features may require sales provisioning. |
| **Signicat** | Best when national eIDs, regulated identity assurance, or multi-country BankID/MitID/itsme-style authentication is central. Its APIs include callbacks, audit logs, and multiple signing mechanisms. [Signature API](https://developer.signicat.com/apis/electronic-signing/express/) | More identity-platform-oriented and typically a heavier integration for straightforward onboarding. |
| **Dropbox Sign** | Quickest developer experience for ordinary e-signatures; official Node SDK, callbacks, templates, and embedded signing. [Node SDK](https://github.com/hellosign/dropbox-sign-node), [API overview](https://sign.dropbox.com/en-GB/developers) | Less compelling when EU sovereignty and configurable AES/QES are decisive requirements. |
| **Adobe Acrobat Sign** | Worth considering if your company already standardizes on Adobe and procurement can bundle it. | I would not select it over Youtrust or DocuSign solely for this Node onboarding flow. |

My shortlist would therefore be:

1. **Youtrust** for an EU-first, focused implementation.
2. **DocuSign** if global scale, established enterprise procurement, or deeper agreement workflows matter more.
3. **Signicat** if verified national identity is the core requirement.

Before signing a contract with any provider, I’d run a small proof of concept covering QES availability in every target country, API-plan access, webhook authentication/retries, evidence-package contents, retention/deletion controls, DPA/subprocessors, data residency, accessibility, and actual per-signature pricing.

For legally compliant electronic signatures in the EU (under the **eIDAS** regulation) combined with document generation and a clean Node.js API/webhook integration, here is the recommendation and the evaluation of alternatives.

---

### 🏆 Recommended Choice: **Yousign** (or **DocuSign** depending on scale)

#### **Top Pick for EU-first: Yousign**
If your core requirement is European compliance, simple developer UX, and straightforward pricing:

* **EU / eIDAS Compliance:** Yousign is a pure EU/French eIDAS certified Trust Service Provider (eIDAS eSignature compliant: SES, AES, QES). All data is strictly hosted within the EU (GDPR native).
* **Node.js Integration & Webhooks:** Clean REST API with official/community Node SDKs, reliable event webhooks (`signature_request.done`, `declined`, etc.), and easy sandbox mode.
* **Document Generation:** Offers template endpoints where you can either merge fields into preset templates or upload your dynamically generated PDF (e.g. built via `@react-pdf/renderer`, `pdfmake`, or `Puppeteer`).
* **Pricing & Transparency:** Significantly more developer-friendly, predictable tier-based API pricing compared to legacy providers.

---

### 🔍 Providers Evaluated

| Provider | EU / eIDAS Compliance | Dynamic Doc Gen + Webhooks | Developer Experience (Node.js) | Notes & Trade-offs |
| :--- | :--- | :--- | :--- | :--- |
| **Yousign** *(Recommended)* | **Highest (Native EU/eIDAS)** | Excellent template merging & webhook events | Modern REST API, webhooks with HMAC signatures | Best balance of EU legal compliance, simple pricing, and modern developer tooling. |
| **DocuSign** | Full (eIDAS SES, AES, QES) | Document generation via API/merge fields, robust webhooks (DocuSign Connect) | Comprehensive official `docusign-esign` Node SDK | Enterprise standard worldwide; however, complex API surface/OAuth flows, expensive API plans, and historically clunky developer console. |
| **Signaturit** | **Highest (Native EU/eIDAS)** | PDF upload / dynamic field anchoring, reliable webhooks | Good Node SDK and clean REST API | Strong Spanish/EU presence; excellent audit trails and qualified time stamping, slightly more niche developer community than DocuSign. |
| **PandaDoc** | General e-signature (SES/AES); US/EU servers available | **Best-in-class built-in document builder/API generator** | Official Node SDK, great webhooks | Incredible dynamic doc generation from tokens/HTML. If your contracts require very flexible layouts directly built via API, it is great, but ensure their eIDAS level matches your specific legal risk tier. |
| **Dropbox Sign** *(formerly HelloSign)* | Standard e-signature (SES); eIDAS recognized | Simple template filling & PDF upload, solid webhooks | Very developer-friendly Node SDK | Very easy to implement, but less EU/eIDAS-focused if you require Qualified (QES) or Advanced (AES) European certification. |
| **Adobe Sign (Acrobat Sign)** | Full (eIDAS certified) | Strong template engine, webhook support | Official SDKs available | Solid enterprise choice, but API onboarding, developer tiers, and pricing are geared toward enterprise agreements. |

---

### 🛠️ Architecture Recommendation for Node.js

A standard and robust pipeline in Node.js looks like:

1. **Document Generation (Internal or Provider):**
   * *Option A (Self-generated PDF):* Render your contract in Node via `@react-pdf/renderer` or `puppeteer-core` (HTML/CSS to PDF) with dynamic placeholders.
   * *Option B (Provider Template):* Maintain a master template in the provider’s dashboard and send dynamic JSON field values.
2. **Signature Request Creation:**
   * Call the provider API (e.g., Yousign `/signature_requests`) passing signer details, authentication method (SMS OTP / email), and signature anchors.
3. **Webhook Listener:**
   * Expose an endpoint (e.g., `POST /api/webhooks/signature`) verified by secret/HMAC signature.
   * On completion event, download the signed PDF and legal audit trail directly to your storage (S3, GCS) and advance the onboarding state in your database.

---

### Next Steps / Decision Factors
* **Signature Level:** Do you only need **SES** (Simple Electronic Signature – sufficient for 90%+ of standard B2B/B2C onboarding agreements) or **AES / QES** (Advanced / Qualified, required for specific heavily regulated sectors like banking/real estate)?
* If you'd like, we can draft a minimal Node.js / Express implementation with webhook verification for your chosen provider.

For generating dynamic contracts and collecting **eIDAS-compliant legal signatures in the EU** with Node.js and webhook support, here is the recommendation and the comparative evaluation.

---

### **Top Recommendation: Yousign** (or **DocuSign EU / Dropbox Sign**)

#### **Why Yousign is the #1 Pick for EU + Node.js**
* **EU Native & eIDAS Focus**: Yousign is a French/EU-headquartered eIDAS Certified Trust Service Provider (QTSP). Data residency is strictly within the EU (GDPR native), avoiding US CLOUD Act/data transfer complications.
* **Signature Levels**: Offers standard Simple Electronic Signatures (SES), Advanced Electronic Signatures (AES with ID verification / SMS OTP), and Qualified Electronic Signatures (QES) out of the box.
* **Developer Experience**: Clean REST API with first-class webhook events (`signature_request.done`, `signature_request.declined`, etc.) and official/community Node.js client packages.
* **Cost & Workflow**: Extremely cost-effective compared to enterprise giants, with a modern API-first dashboard and sandbox.

---

### **Provider Comparison & What Else Was Evaluated**

| Provider | EU / eIDAS Compliance | Dynamic Document Generation | Node.js & Webhooks | Best For / Verdict |
| :--- | :--- | :--- | :--- | :--- |
| **Yousign** *(Top Pick)* | **QTSP Certified (EU)**; SES, AES, QES supported natively. | PDF upload / templating with custom anchor tags/fields. | Excellent REST API, reliable webhooks, easy payload verification. | **Best overall choice for EU businesses** needing compliance, simplicity, and fast developer onboarding. |
| **Dropbox Sign** *(formerly HelloSign)* | Standard eIDAS SES/AES compliance (US-based parent, EU data residency optional on enterprise). | Template fields & merge tags via API. | Official `@dropbox/sign` SDK for Node.js, mature webhooks. | **Best developer experience / documentation**, but lacks native QTSP status if you require regulated high-tier QES. |
| **DocuSign** | Full eIDAS compliance, QTSP across EU, global recognition. | Document Generation API + Envelope templating. | Official `docusign-esign` npm package, Connect webhooks. | **Best for large enterprise / global reach**, but significantly more expensive, complex API/auth (JWT OAuth), and heavy overhead. |
| **Signable / Scrive** | Scrive (Nordics) and Signable (UK/EU) offer solid eIDAS backing. | Form field mapping & PDF uploads. | REST API + webhooks. | Good niche EU alternatives, but developer tooling and ecosystem are smaller than Yousign or Dropbox Sign. |
| **DocuSeal** *(Open-source alternative)* | SES compliance, audit trail; self-hostable in EU infrastructure. | Built-in HTML-to-PDF / template field population. | Lightweight REST API + webhooks, Node.js SDK. | **Best for total data control & zero per-signature fees** if self-hosting fits your compliance needs. |

---

### **Recommended Architecture for Node.js**

Instead of relying purely on a signature vendor's template engine for complex dynamic layouts, the standard pattern is:

1. **Generate PDF in Node.js**:
   * Use [`@react-pdf/renderer`](https://react-pdf.org/) or HTML/CSS templates via [`puppeteer`](https://pptr.dev/) / [`playwright`](https://playwright.dev/) to dynamically render the contract PDF using your database data.
2. **Send via Signature API (e.g., Yousign)**:
   * Upload the generated PDF buffer to the provider’s API.
   * Define signer email, signature anchor coordinates/tags, and authentication method (e.g., SMS OTP for AES).
3. **Handle Completion Webhook**:
   * Set up an endpoint (e.g., `POST /api/webhooks/signatures`) in Express/Fastify/Nest.
   * Verify the provider signature header, download the signed PDF + audit trail certificate, and update your database/trigger onboarding completion.

### Recommended Choice: **DocuSign** or **Yousign** (depending on your compliance priority)

---

### Top Recommendation: **Yousign** (Best Pure EU / eIDAS-First) or **DocuSign** (Best Ecosystem)

#### 1. **Primary Pick for EU Compliance & Developer Experience: Yousign**
* **Why it fits:** Yousign is based in France, strictly hosts data in the EU, and is a certified Qualified Trust Service Provider (QTSP) under **eIDAS**.
* **eIDAS Levels:** Native support for Simple Electronic Signatures (SES) and Advanced Electronic Signatures (AES) with SMS/ID verification, compliant across all EU member states.
* **Document Generation:** You can upload dynamically generated PDFs (e.g., via `@react-pdf/renderer`, `pdfmake`, or `puppeteer`) or use their template system to inject dynamic text fields.
* **Webhooks:** Robust event notifications (e.g., `signature_request.done`, `signature_request.declined`).
* **Node.js Integration:** Clean REST API with simple auth and official/community Node SDKs.

#### 2. **Primary Pick for Global Reach & Enterprise Breadth: DocuSign**
* **Why it fits:** Market standard with official `@docusign/esign-node` SDK, robust eIDAS compliance, extensive EU data centers, and rock-solid webhook system (DocuSign Connect).
* **Downside:** Higher pricing, more complex API surface / permission setup.

---

### Comparison of Evaluated Alternatives

| Provider | EU / eIDAS Compliance & Data Residency | Dynamic Doc Generation | Webhook Support | Node.js DX | Best For |
| :--- | :--- | :--- | :--- | :--- | :--- |
| **Yousign** | **Native EU (QTSP)**, 100% EU servers (FR) | Pass PDF buffer or use dynamic templates | `POST` webhooks with payload verification | Excellent, clean REST API | EU-first products requiring strict eIDAS compliance & GDPR peace of mind |
| **DocuSign** | **Full eIDAS** support (SES/AES/QES), EU data residency option | Dynamic field merge tags or custom generated PDF | DocuSign Connect (HMAC-SHA256 signatures) | Full official Node SDK | Enterprises or apps needing global coverage & established brand recognition |
| **Dropbox Sign** *(HelloSign)* | Compliant with eIDAS (SES/AES), EU storage available on select plans | Excellent template API + custom PDF uploads | Built-in webhooks with event hashes | Official `@dropbox/sign` SDK | Fast dev turnaround, straightforward API |
| **Signable / PandaDoc** | EU-compliant (PandaDoc offers EU data residency; Signable is UK/EU based) | Strong built-in HTML/template document generators | Standard webhooks | Good REST API | Teams wanting built-in document builder UI rather than pure backend PDF generation |
| **Self-Hosted / Open-Source** *(e.g., Documenso / OpenSign)* | Full data ownership (host in EU), standard digital signatures | Backend-generated PDF sent to self-hosted instance | Configurable webhooks | Direct DB / REST access | Complete data residency control, no per-signature API cost |

---

### Recommended Node.js Architecture Pattern

1. **Document Generation:** Generate the contract PDF dynamically in Node from your data:
   * Lightweight/fast: `@react-pdf/renderer` or `pdf-lib`
   * Complex styling/HTML: `puppeteer` (HTML to PDF)
2. **Signature Request:** Send the generated PDF buffer directly to the provider's API with defined signer roles, email, and signature coordinates/anchor tags.
3. **Webhook Handler:** Express/Fastify endpoint verifying provider webhook signatures (e.g., `signature_request.done`), which:
   * Downloads the signed PDF audit trail.
   * Updates your database to mark the user as onboarded.
   * Sends final confirmation emails automatically.

Here is the recommended provider selection for EU-compliant e-signatures with a Node.js backend, automated document generation, and webhook event notifications.

---

### **Top Recommendation: Yousign (or DocuSign for Global Scale)**

#### **Primary Pick for EU: Yousign**
If your primary jurisdiction and focus is the EU, **[Yousign](https://yousign.com)** is generally the best fit.

* **Why Yousign:**
  * **EU/eIDAS Native:** It is an eIDAS-certified Qualified Trust Service Provider (QTSP) based in France, ensuring automatic compliance with EU regulations (SES, AES, and QES support) and GDPR (data residency strictly in the EU).
  * **Developer-Friendly REST API & Webhooks:** Clean API for uploading/generating PDFs, defining signer fields/anchors, and setting up granular webhook events (`signature_request.completed`, `declined`, etc.).
  * **Node.js Integration:** Straightforward integration using standard `fetch`/`axios` or community wrappers.
  * **Cost-effective:** Much lower entry cost and transparent API pricing compared to legacy enterprise platforms.

---

### **Provider Comparison & Alternatives Evaluated**

| Provider | EU Compliance / eIDAS Level | Developer Experience & Webhooks | Best Used When... |
| :--- | :--- | :--- | :--- |
| **Yousign** *(Top EU Pick)* | Native eIDAS QTSP (SES, AES, QES), 100% EU data residency | Excellent REST API, fast setup, robust webhooks, detailed audit trail | You operate primarily in the EU, want frictionless GDPR/eIDAS compliance, and need reasonable API pricing. |
| **DocuSign** | Full global compliance (eIDAS SES, AES, QES available via ID Verification) | Official `@docusign/esign-nodejs` SDK, highly mature webhook infrastructure (DocuSign Connect) | You are an enterprise needing global reach, complex routing rules, or brand recognition. (Drawback: Costly, complex API). |
| **Dropbox Sign** *(formerly HelloSign)* | eIDAS compliant (SES/AES) | Excellent `@dropbox/sign` Node SDK, easy template & merge field system, reliable webhooks | You want the fastest developer setup with great Node.js SDKs, though pricing is geared towards usage tiers. |
| **Signable** / **Oneflow** | eIDAS compliant | Standard REST APIs | You want simple UK/EU contracts or contract lifecycle management (CLM) with HTML-first documents (Oneflow). |
| **PandaDoc** | eIDAS compliant (SES/AES) | Strong document generation engine from JSON templates + signatures + webhooks | You want a single platform to handle both the dynamic templating/generation *and* the signature workflow. |

---

### **Architecture Recommendation for Node.js**

Depending on how complex your contract layout is, there are two common implementation patterns:

#### **Pattern A: Generate PDF Locally + Send via Signature API** *(Most flexible & cost-effective)*
1. **Document Generation:** Generate the PDF in your Node backend using a library like:
   * **`@react-pdf/renderer`** or **Puppeteer / Playwright** (HTML/CSS to PDF).
   * **`pdf-lib`** (filling an existing base template with form fields).
2. **Upload & Request:** POST the generated PDF buffer to Yousign / DocuSign API with recipient details and signature anchor tags (e.g., `{{sig1}}`).
3. **Webhook Listener:** An Express/Fastify endpoint to catch the `signature_request.completed` event, verify HMAC signatures, download the signed PDF, and update your onboarding DB.

#### **Pattern B: Provider-Side Template Merge**
* If you prefer not to manage PDF rendering infrastructure in Node, providers like **PandaDoc** or **Dropbox Sign** allow you to create templates in their dashboard and merge JSON variables via API before dispatching.

For a **Node.js backend** requiring automated document generation from data, legally binding EU signatures (eIDAS compliance), and webhook callbacks upon completion, here is the provider breakdown and recommendation:

---

### Top Recommendation: **DocuSign (eSignature API) + HTML-to-PDF / Document Generation** or **Boldsign** / **Signwell**

Depending on whether your priority is **brand trust/EU enterprise compliance** or **developer agility/pricing**, here is how to choose:

#### 1. Best Overall & Safest for EU Legal Compliance: **DocuSign API**
* **Why it wins:**
  * **EU Legal Framework (eIDAS):** Full compliance with standard electronic signatures (SES) and easy upgrade paths to Advanced (AES) / Qualified Electronic Signatures (QES) with EU trust service provider verification if needed. EU data residency available.
  * **Dynamic Generation:** Supports dynamic template generation (merge fields / anchor tags) or uploading raw PDF buffer generated via your Node backend.
  * **Node.js Integration:** Official, mature SDK (`docusign-esign`), robust webhook system (**DocuSign Connect** with HMAC signatures, idempotency, and retry mechanisms).
* **Drawback:** Higher pricing tiers and enterprise-heavy developer console.

#### 2. Best Developer-Friendly & Cost-Effective: **BoldSign** (or **SignWell**)
* **Why choose it:**
  * **eIDAS / GDPR Compliance:** Compliant with EU regulations (audit trail, certificate of completion, EU data hosting options).
  * **Node.js API:** Modern REST API with clean webhook notifications for events like `DocumentSigned`, `DocumentCompleted`, `DocumentDeclined`.
  * **Template API:** Pass key-value fields directly to a pre-defined template or push your generated PDF with dynamic signature anchors via API.
  * **Pricing:** Significantly cheaper than DocuSign for small-to-medium volumes.

#### 3. Best Specialized EU-Native Provider: **Yousign**
* **Why choose it:**
  * **EU-first focus:** French/EU-headquartered, built ground-up around eIDAS regulations (QES/AES support, GDPR-native).
  * **Node.js & Webhooks:** Excellent developer documentation, clean REST endpoints, and straightforward webhook event handling.

---

### Comparison Summary

| Provider | EU / eIDAS Level | Dynamic Doc Gen / Templates | Node.js DX & Webhooks | Best For |
| :--- | :--- | :--- | :--- | :--- |
| **DocuSign** | SES, AES, QES (EU Data Residency) | Strong (Merge fields + PDF API) | Official SDK, DocuSign Connect webhooks | Enterprise trust, strict legal/procurement requirements |
| **Yousign** | SES, AES, QES (100% EU Hosted) | Template fields + PDF upload | Clean REST API + Webhooks | Strict EU-native / French / German regulatory preference |
| **BoldSign** | SES (eIDAS compliant) | Merge fields + Dynamic PDF | Official SDK, fast setup, Webhooks | Best cost-to-feature ratio & developer velocity |
| **SignWell / PandaDoc** | SES (eIDAS compliant) | High (PandaDoc has strong native builder) | REST API + Webhooks | Simple contracts with standard SES legal requirements |

---

### Recommended Node.js Architecture Pattern

1. **Document Generation:**
   * Generate the base PDF dynamically in Node.js using **`react-pdf`**, **`puppeteer`** (HTML/CSS to PDF), or **`pdf-lib`**.
   * Add text anchor tags (e.g., `{{signature_1}}`, hidden in white text or positioned via coordinates).
2. **Signature Dispatch:**
   * Send the generated PDF buffer to the e-signature API endpoint with signer metadata (name, email, role).
   * Set the signing provider to automatically chase signers (auto-reminders / expiry).
3. **Webhook Reception:**
   * Expose a secure endpoint (e.g., `/api/webhooks/signature-completed`) validating HMAC signatures.
   * On `document.completed` / `envelope-completed`, automatically fetch the signed PDF and cryptographic audit trail and update your database.

**Yousign** for this setup: EU-native, eIDAS (AES and QES), solid REST API for Node, templates/merge from your data, and webhooks when a signature completes.

### Why Yousign
- Built for EU/GDPR and eIDAS, not bolted on later — better default than US-first tools for “legally signed in the EU.”
- Node talks to their REST API like any other HTTP client; you create a signature request from a template or uploaded PDF, then listen for completion webhooks.
- Fits onboarding: fill contract fields from your CRM/DB, send for signature, stop chasing email PDFs by hand.
- AES covers most B2B onboarding contracts; QES is there if counsel wants handwritten-equivalent weight.

**Practical split:** generate the PDF yourself (Puppeteer / `pdf-lib` / react-pdf) *or* use their templates with merge fields; then create the signature request and wire `signature_request.done` (or equivalent) to mark the user onboarded.

### What else I looked at

| Provider | Verdict |
|---|---|
| **DocuSign** | Strongest global SDK/webhooks (Connect), templates + tabs. Heavier and pricier; use if you already buy it or need multi-region enterprise. EU QES via their eIDAS path, but it’s not the simplest EU-first choice. |
| **Dropbox Sign (HelloSign)** | Best DX of the big US options, clean Node SDK + webhooks. Weaker EU/eIDAS story than Yousign; fine if SES/AES is enough and legal is comfortable with a US vendor. |
| **PandaDoc** | Nice “generate + sign” product for sales docs. More CRM/sales-shaped than a lean onboarding webhook flow. |
| **Adobe Sign** | Enterprise-grade; usually overkill and procurement-heavy for a Node onboarding backend. |
| **Signaturit / Scrive** | Solid EU alternatives (Spain / Nordics). Worth a bake-off if you need local eID (e.g. BankID) or Spanish-market QES specifically. |
| **Documenso** | Open-source, self-host, good cost/control. Weaker turnkey QES/compliance pack — pick only if SES + self-host is an explicit goal. |

### Decision shortcuts
- **EU-first onboarding, Node, webhook → Yousign.**
- **Already in DocuSign / need global enterprise → DocuSign.**
- **Max DX, SES enough, US OK → Dropbox Sign.**
- **Self-host / OSS → Documenso** (confirm legal level with counsel first).

One check before you lock it: ask counsel whether onboarding needs **AES or QES**. That single answer filters the shortlist more than feature matrices.

Checking current EU e-sign API options so the recommendation matches what’s actually solid for Node + eIDAS today.**Use Yousign.**

It fits this stack best: EU/eIDAS-native (SES → AES → QES), generate from templates or upload a PDF, Node-friendly REST API, and completion webhooks so onboarding can advance when the contract is signed. You stay in one EU vendor for both “legal signature” and the ceremony, without DocuSign-level enterprise overhead.

### How I’d wire it
1. **Generate the PDF in your backend** (template + merge fields, or Puppeteer/`pdf-lib` from your data) — don’t rely on the e-sign product as your document engine.
2. **Create a signature request** via Yousign API, attach the PDF, set signers.
3. **Subscribe to webhooks** for `signature_request.done` (and failure/expired); verify the signature, then mark the contract signed and continue onboarding.
4. Pick the **eIDAS level you actually need**: most B2B onboarding contracts are fine with AES; use QES only if a specific act or counterparty requires it.

### What else I looked at

| Provider | Why not first choice |
|---|---|
| **DocuSign** | Fine default if you already pay for it or need global enterprise recognition. Heavier, pricier, and US-centric for an EU-only onboarding flow. |
| **Dropbox Sign (HelloSign)** | Clean Node SDK and webhooks; weaker EU/eIDAS story if you care about AES/QES and European audit posture. |
| **PandaDoc** | Stronger when sales proposals + content editing matter more than a fixed onboarding contract. Overkill if you already generate the PDF. |
| **Adobe Acrobat Sign** | Solid, enterprise; similar bulk/cost profile to DocuSign. |
| **Scrive / Signaturit** | Good EU alternatives (Nordics / Spain). Prefer them if your signers are concentrated there or you need their local ID methods. |
| **Documenso / self-host** | Attractive cost/control, but you own more of the legal/ops burden for “legally signed in the EU.” |

**Bottom line:** Yousign for EU onboarding + webhooks + Node; DocuSign only if procurement/brand already pushes you there; generate the PDF yourself and treat the provider as the signature + evidence layer.

**I’d use Yousign** for this.

It’s built for the EU (eIDAS SES / AES / QES), GDPR-friendly hosting story, has a proper REST API that fits a Node backend, and supports completion webhooks so you can mark onboarding done without chasing people. Generate the PDF in your app (Puppeteer / `pdfkit` / `@react-pdf/renderer` from your CRM/DB fields), upload it, create the signature request, store the envelope/request id, and handle `signature_request.done` (or equivalent) on your webhook.

### Why not the others

| Provider | Verdict |
|---|---|
| **DocuSign** | Safest “nobody gets fired” pick, excellent Node SDK + Connect webhooks, eIDAS including QES. Heavier and pricier than you need if onboarding contracts are the main use case. |
| **Dropbox Sign (HelloSign)** | Best DX of the US APIs; webhooks and Node SDK are fine. Weaker as an *EU-legal* default if you may need QES or EU-only trust/compliance storytelling. |
| **Adobe Acrobat Sign** | Enterprise parity with DocuSign; same “overkill + procurement” problem for a simple onboarding flow. |
| **PandaDoc** | Strong if sales wants editable proposals/templates in-product. Worse fit if you already own PDF generation and only need sign + webhook. |
| **Scrive / Signaturit** | Solid EU alternatives (Nordics / ES). I’d shortlist them if you’re already in those markets or need local BankID-style ID; otherwise Yousign is the clearer general EU API. |
| **Documenso (self-host)** | Attractive cost/control, but you’re on the hook for uptime, evidence trail, and QES via a QTSP if “legally” means qualified. Not what I’d pick to *stop* chasing signatures. |

### Implementation shape (Node)

1. Render PDF from your data → store hash + version.
2. Create signature request with signer email(s) and AES (upgrade to QES only if counsel says the contract type needs it).
3. Persist provider request id ↔ user/org.
4. Expose an idempotent webhook; on completed, download the signed PDF + evidence/audit file, persist both, advance onboarding.

**AES is enough for most commercial B2B onboarding contracts under eIDAS.** Use **QES** only when local law or your lawyer requires a qualified signature—not by default.

If you already standardize on DocuSign company-wide, use that instead of adding a second vendor; otherwise Yousign is the better fit for “EU-legal + Node + webhook + stop emailing PDFs.”

Pulling current EU e-sign options that fit document generation, legal signing, and Node webhooks.**Yousign** — best fit for an EU onboarding flow on a Node backend.

### Why Yousign
- EU-native, built around **eIDAS** (SES / AES / QES), so “signed legally in the EU” is a first-class product story, not a bolt-on.
- REST API + **webhooks** for completed / declined / expired envelopes — straightforward from Node (`fetch` or their SDK).
- Fits your current process: build the PDF from your data (or use their templates + merge fields), create a signature request, email the signer, get a webhook when it’s done, store the signed PDF + audit trail.
- Default **EU data residency**, which matters if legal/compliance will ask where the contract lives.
- Usually cheaper and less enterprise-process-heavy than DocuSign for this use case.

**Practical shape:** generate the PDF in Node (Puppeteer / `pdf-lib` / your template engine) → upload → create signature request with signer email → listen for `signature_request.done` (or equivalent) → download signed file + proof.

Clarify with legal whether you need **AES** (typical B2B onboarding) or **QES** (higher-assurance / some regulated contexts). Yousign covers both; QES costs more and adds identity steps.

---

### What else I’d look at

| Provider | When I’d pick it instead |
|---|---|
| **DocuSign** | Global signers, enterprise procurement already standardized on it, complex multi-party / routing. Excellent Node SDK + Connect webhooks; pricier and heavier. |
| **Scrive** | Nordic-heavy base, BankID / local ID methods matter a lot. Strong eIDAS, less “default EU SaaS” DX than Yousign. |
| **Dropbox Sign** | Best DX/price if **SES** is enough and EU QES / residency is not a hard requirement. Weaker answer to “legally in the EU” if counsel wants AES/QES from an EU QTSP-style path. |
| **Adobe Acrobat Sign** | You’re already in Adobe enterprise; otherwise more ceremony than you need. |
| **Signaturit / Universign / Namirial** | Strong if you’re Spain/France-centric or need a specific QTSP; smaller ecosystem than Yousign/DocuSign. |
| **Documenso (self-host)** | Full control / cost; you own compliance, identity, and audit-trail credibility — not a drop-in for “legally signed in the EU.” |

---

### What I wouldn’t over-index on
- Building “legal EU signature” yourself on top of raw PDF + email — eIDAS value comes from identity assurance + evidence file, which these providers package.
- PandaDoc / proposal tools — fine for sales docs, less clean as a pure contract + webhook backend.

**Bottom line:** start with **Yousign** unless you already need DocuSign for enterprise/global reasons. Confirm AES vs QES with counsel, generate PDFs in your Node service, and drive state from their completion webhook.

Checking current EU e-sign options and Node/webhook support so the recommendation matches today’s market.**I’d use Yousign** for this: EU QTSP, eIDAS AES/QES, REST + Node-friendly client, templates/merge for contract data, and completion webhooks so onboarding can close itself.

### Why Yousign
- **EU-legal by default** — French QTSP, GDPR/EU residency; AES for normal B2B onboarding, QES when you need handwritten-equivalent weight.
- **Fits the flow** — generate from template + fields (or upload a PDF you built in Node), send for signature, get a webhook when it’s done; no more email chase.
- **Ops cost** — usually cheaper and less enterprise ceremony than DocuSign for a pure “contract out of onboarding” use case.

### Also looked at
| Provider | Take |
|---|---|
| **DocuSign** | Strongest global/eIDAS stack and Node SDK, but overkill and pricey if you’re only EU onboarding. |
| **Adobe Acrobat Sign** | Same enterprise bucket as DocuSign. |
| **Scrive** | Excellent EU/Nordics (BankID etc.); prefer if those markets/QES identity methods dominate. |
| **Dropbox Sign (HelloSign)** | Nicest simple Node DX; weaker “serious EU contract” story (more SES/AES, US-centric). |
| **PandaDoc** | Good docs + proposals; signing/legal depth secondary. |
| **Signicat / Namirial** | Great if you already need identity/QES infrastructure; heavier than a contract webhook. |
| **Documenso / DocuSeal** | Self-host open source; you own uptime, audit trail, and “is this legally enough?” — usually wrong for paid onboarding contracts. |

### Practical split
- **Generate PDF in Node** (Puppeteer / pdf-lib / your template engine) → upload to Yousign if layout is complex.
- **Or** keep a Yousign template and fill fields from your DB if the contract is mostly the same shape.
- Subscribe to the **signature/request completed** webhook; treat the signed PDF + evidence file as the source of truth in your DB.

If you already sell into Nordics with BankID, pick **Scrive** instead. If procurement already has **DocuSign**, stay there — the API is fine; you’re just paying for brand and global coverage you may not need.

Bez KB, więc odpowiadam z wiedzy własnej.

**Rekomendacja: Yousign.** Firma francuska, natywnie eIDAS (SES/AES/QES), dane trzymane w UE (istotne dla RODO), przyzwoite REST API + webhooki na każdy etap (wysłano, otwarto, podpisano, odrzucono), oficjalny Node SDK, i cennik sensowny przy niskim wolumenie z onboardingu. Największy kompromis: ekosystem i dokumentacja słabsze niż u DocuSigna, więc przy bardziej złożonych flow (multi-party, warunkowe pola) trzeba więcej ręcznej roboty.

Co jeszcze brałem pod uwagę:

- **DocuSign** - najbardziej dojrzały, najlepsze SDK i webhooki (Connect), ale to firma US-owa; eIDAS AES/QES owszem obsługuje, lecz przez dodatkowe partnerstwa/konfigurację, i jest wyraźnie droższy przy małej skali.
- **PandaDoc** - łączy generowanie dokumentu z danych (templating) z podpisem w jednym produkcie, wygodne jeśli chcesz uniknąć osobnego kroku "wygeneruj PDF, potem wyślij do podpisu". Słabszy jednak jako czysto prawny AES/QES w UE - dobry do prostych zgód, gorszy jeśli zależy ci na twardej zgodności eIDAS.
- **Adobe Acrobat Sign** - solidny eIDAS, ale enterprise'owy cennik i ciężka integracja jak na potrzeby jednego flow onboardingowego.
- **Scrive** - skandynawski, mocny w AES/QES z lokalnymi metodami identyfikacji (BankID itp.), ale API i webhooki gorzej udokumentowane, mniejsza społeczność.
- **Dropbox Sign (dawny HelloSign)** - fajne DX, ale rezydencja danych głównie US, słabszy fit pod czysto europejski wymóg.

Jeśli wolumen w onboardingu jest niski i nie potrzebujesz od razu kwalifikowanego podpisu (QES), AES z Yousign wystarczy prawnie w większości krajów UE i jest najtańszym/najszybszym wdrożeniem pod Node. Chcesz, żebym rozpisał konkretny flow (generowanie PDF z danych → wysyłka do Yousign → webhook → zapis statusu)?

Do generowania umowy z danych plus prawnie wiążącego podpisu w UE wybrałbym **Yousign**: jest EU-native (Francja), zgodny z eIDAS (SES/AES, opcjonalnie QES), dane trzymają się w UE więc RODO bez analizy transferu do USA, ma REST API z Node SDK, webhooki na zdarzenie podpisania i własne Document Generation API do wypełniania szablonu danymi, więc pokrywa cały flow jednym providerem. Główny kompromis: mniejszy branding i ekosystem integracji niż u amerykańskiej konkurencji, co czasem robi różnicę jeśli klienci oczekują rozpoznawalnej marki przy podpisie.

Co jeszcze sprawdzałem:
- **DocuSign** - najbardziej rozpoznawalny, mocny Node SDK i webhooki (Connect), ale US-centric (transfer danych do analizy pod RODO) i droższy/bardziej złożony pricing.
- **Dropbox Sign (HelloSign)** - prosty i tani, ale słabszy w generowaniu dokumentu z danych i w wyższych poziomach eIDAS (AES/QES).
- **PandaDoc** - dobre połączenie generowania dokumentu i podpisu, ale profil bardziej sprzedażowy (oferty/proposal), słabiej czysto pod eIDAS.
- **Autenti** - polski, dobra opcja lokalnie i tania, ale mniejszy zasięg jeśli część klientów jest poza PL.

Chcesz, żebym rozpisał integrację (endpoint na webhook, model danych do szablonu, retry/idempotency) pod Yousign, czy wolisz najpierw porównać koszty przy waszym wolumenie podpisów?

Do generowania dokumentu z podpisem elektronicznym w UE postawiłbym na **Yousign** - francuski, eIDAS-natywny provider z pełnym wsparciem AES i QES (kwalifikowany podpis przez certyfikowanych dostawców), dane trzymane w UE (dobre pod RODO), sensowne REST API + webhooks na zdarzenie podpisania, i rozsądna cena dla mniejszej skali. Do samego onboardingu wystarczy zwykle poziom AES (prawnie wiążący w całej UE z domniemaniem ważności), QES włączasz punktowo tylko tam, gdzie konkretny kraj/regulacja tego wymaga.

Co jeszcze sprawdzałem:
- **DocuSign** - branżowy standard, też ma eIDAS AES/QES i webhooki (Connect), ale droższy i cięższy do wdrożenia niż potrzeba na start.
- **PandaDoc** - fajnie łączy budowanie dokumentu z podpisem, ale to bardziej platforma sprzedażowa niż lekkie API; u was dokument i tak generujecie sami, więc ta warstwa jest zbędna.
- **Dropbox Sign / SignRequest** - tańsze i proste, ale słabsze wsparcie QES i mniej jednoznaczne pod kątem rezydencji danych w UE.
- **Documenso** - open source, ciekawe pod kątem suwerenności danych, ale niedojrzałe (brak QES, więcej pracy przy self-hostingu) - wart obserwowania, nie na produkcję teraz.

Główny kompromis: Yousign vs DocuSign to prostota/cena kontra rozpoznawalność marki i dojrzałość ekosystemu integracji - przy waszej skali Yousign wygrywa.

Rekomendacja: **Yousign** - europejski provider (dane w UE, RODO-friendly), natywnie eIDAS (AES i QES), proste REST API + webhooki na zdarzenie "signed", rozsądny cennik na start. Node ma tylko community SDK, ale REST jest na tyle prosty, że owinięcie go własnym klientem to pół dnia roboty.

Co jeszcze brałem pod uwagę i odrzuciłem:
- **DocuSign** - najszerszy globalnie, ale US-centric, droższy i cięższy w integracji (JWT auth, embedded signing) - przerost formy dla prostego flow "generuj z danych → wyślij → webhook".
- **Autenti** - dobry wybór, jeśli podpisujący są głównie w PL (profil zaufany, integracja z krajowym rynkiem); słabszy, jeśli macie klientów poza Polską.
- **Dropbox Sign** (dawniej HelloSign) - najprostsze API, ale słabsze pokrycie eIDAS/QES, głównie pod rynek US.
- **Adobe Acrobat Sign / SignRequest** - odpadły: Adobe to enterprise pricing, SignRequest ma słabszy developer experience.

Główna decyzja do podjęcia: czy podpisujący są głównie krajowi (wtedy Autenti ma sens) czy szerzej unijni/międzynarodowi (wtedy Yousign). Powiedz, w którą stronę to idzie, to naszkicuję integrację (generowanie dokumentu z danych + endpoint na webhook).

Rekomendowałbym **Yousign** - to francuski/unijny dostawca e-podpisu, natywnie zgodny z eIDAS (SES/AES/QES), dane trzymane w UE (dużo prościej pod RODO), rozsądne ceny, REST API + webhooks na zdarzenie "signed", i wspiera generowanie dokumentu z szablonu + danych, czyli dokładnie Twój flow. Główny trade-off: mniejsza marka i mniej gotowych integracji/case studies niż DocuSign, więc trzeba samemu spiąć REST API (nie ma oficjalnego Node SDK, ale API jest proste).

Co jeszcze porównywałem:
- **DocuSign** - rynkowy standard, najbogatsze API i oficjalny Node SDK, ale droższy i domyślnie dane trzymane w US (trzeba pilnować data residency / DPA pod RODO).
- **Adobe Acrobat Sign** - podobny profil do DocuSign, mocny enterprise, ale zbyt ciężki i kosztowny na prosty onboarding.
- **PandaDoc** - fajnie łączy generowanie dokumentu (szablony + zmienne) z podpisem w jednym flow, ale ich domyślny poziom podpisu to głównie SES, słabiej adresuje AES/QES pod eIDAS niż Yousign.
- **Dropbox Sign (dawniej HelloSign)** - prosty i tani, ale słabo dotyka eIDAS wprost, dane głównie w US.

Zanim zacznę cokolwiek wdrażać: jaki poziom podpisu faktycznie potrzebujesz prawnie (SES wystarczy do większości umów, AES/QES dopiero gdy jest konkretny wymóg regulacyjny)? To określi, czy Yousign się broni, czy trzeba celować wyżej.