DocuSign eSignature

Selected as the representative managed signing service for template envelopes, provider-hosted signing links and completion webhooks with sealed document retrieval. Implemented against that pattern with secrets kept outside the repo, but never exercised against a live account so plan details and live delivery remain unverified.

What worked

The template plus link plus webhook pattern fit the requirements for external signing, audit evidence and filing without exposing the internal app.

What got in the way

Specific plan name and pricing could not be confirmed from the record, and live envelope creation and webhook delivery were not observed.

Recommended as the managed signing provider for hosted links, completion callbacks, and tamper-evident completed documents with audit trail. Implemented a credential-free sender abstraction plus webhook verification so tests use a fake, with real keys kept out of the repo. Live service was never exercised without an account.

What worked

Provider model cleanly covered the three needs without exposing the internal app or building audit and reminder machinery.

What got in the way

Plan and entitlement details change often, so no cost or tier could be quoted from the record and live behavior remained unverified.

Evaluated online signing against requirements for an online ceremony, a pending hold, and a producible sealed artifact with an independent audit trail. Designed around envelopes, templates, and webhook completion with idempotent activation, but implemented only as an abstraction without installing an SDK or using a live account.

What worked

Documentation made the envelope plus webhook completion pattern easy to map to pending-to-active transitions and certificate archiving.

What got in the way

No live envelope send, webhook delivery, credential handling, residency, or retention settings could be validated; account, plan, consent, and console configuration remain open.

Evaluated remote signing with mobile link delivery and signed completion callbacks to gate settlement, then implemented API and webhook integration code without a live account, so no real envelope was sent.

What worked

Documentation clearly described remote signer delivery, reminders and expiry, tamper-evident outputs, and signed webhook verification for gating completion.

What got in the way

Pricing tiers moved and production needed a paid API plan rather than a seat license, and live sending and callbacks could not be verified without credentials.

Recommended and implemented a single-envelope flow holding two documents with embedded signing and webhook completion. Wrote the integration without live credentials, so template setup, plan limits, and residency could not be verified against the real service.

What worked

Single envelope model fit the one-pass requirement and avoided partial-sign states. Embedded signing plus webhook completion mapped cleanly to pending to active gating and object storage for completed files.

What got in the way

Could not validate plan names, template behavior, or webhook signatures live. Setup requirements around contract tier, data residency, and signing configuration had to be left as unverified follow-ups.

Compared e-signature options and selected this envelope-based service for a two-document carrier ceremony with embedded signing, dispatch gating, and retained PDFs. Built a template-driven REST client and webhook handler from its docs without a live account.

What worked

Single-envelope model covered two fixed documents, free recipients, audit certificate, and an EU-friendly compliance story that fit the existing region and identity setup.

What got in the way

No live envelope, template, or webhook delivery was exercised in the record; plan names and pricing were explicitly left unverified.

Integrated remote signing for settlement acceptance using plain HTTP calls and webhook completion handling, with status gated until signed completion and signed artifact stored with the claim record. Built and tested without a live production account, using sandbox concepts and mocked HTTP in tests.

What worked

Remote signing model fit phone signing and audit needs well. Email and SMS link delivery, tamper-evident artifact, and completion webhook gave a clear way to gate settlement and preserve evidence.

What got in the way

Live verification was not possible without an account. Plan tiers, envelope limits, embedded signing availability, and messaging fees were hard to confirm from public summaries and required vendor confirmation.

Evaluated for mobile-friendly signing links, completion certificates, and webhook callbacks to gate settlement. Implemented a custom envelope client and completion webhook handling with stubbed tests, but no live account existed so no real envelope was sent and pricing and plan details could not be verified from the record.

What worked

The documented pattern of envelope creation plus completion callback fit the sign-before-settle requirement and the need to file the signed document with the record.

What got in the way

API setup details, live authentication, SMS delivery options, and account and pricing requirements remained unverified without a live account, and one delivery variant was deferred due to uncertain API shape.

Implemented remote signing flow with envelope creation, pending-status gating for proposals and endorsements, webhook completion handling with HMAC verification, resend with supersede, and decline and expiry handling plus signed document retention. No live account was available, so verification relied on fakes and unit tests only.

What worked

Envelope lifecycle, reminder and expiry settings, decline and void events, and completion evidence mapped cleanly to hold-pending-then-issue requirements without custom signature capture.

What got in the way

Could not verify against a live account; authentication, templates, and webhook subscription stayed outside the repo and untested.

Evaluated as the recommended e-signature option for in-product counterparty signing with completion webhook and tamper-evident audit trail. Reviewed plan and pricing material only; integration was implemented behind stubs without live credentials or production calls.

What worked

API and webhook concepts mapped cleanly to the requested flow: multi-party signing, completion callback gating activation, and downloadable signed file plus completion certificate.

What got in the way

Production behavior, account setup, and current pricing could not be confirmed from the record alone and still needed verification before purchase.

Researched production account, embedded signing, and Connect webhook requirements, then implemented a single-envelope flow for two required documents with completion-gated dispatch and server-side PDF storage.

What worked

Conceptual model fit the requirement well: one envelope containing both documents maps cleanly to an all-signed completion gate.

What got in the way

No live account was available, so envelope creation, recipient views, and Connect delivery were never exercised against the real service.

Reviewed this signing service through secondary listings as a functional alternative with EU data centers, and set it aside for this residency-constrained use case in favor of an EU-only qualified provider.

What worked

Listings made plan tiers, EU data center option, and workflow capabilities easy to compare at a high level.

What got in the way

EU storage combined with non-EU support access raised an additional cross-border review burden compared with an EU-only provider.

Used the official eSignature SDK for template envelopes, recipient signing views, signed document retrieval, and webhook signature verification, with a null fallback when unconfigured. Core capability matched the pending-status and producible-proof needs well; package naming and client class discovery took extra probing.

What worked

Template-based envelope flow and completion-certificate model fit the hold-until-signed and later-production requirements.

What got in the way

Package identity and client class naming were confusing and needed reflection probes to resolve.

Researched plans and API model, then implemented template envelope send, signing link flow, webhook completion handling, PDF archiving, and case status gating without a live account.

What worked

API concepts mapped cleanly to the need: reusable template, remote signing link with no client login, envelope status for gating, and completed document plus certificate for the case record.

What got in the way

Pricing and plan limits were unclear from public listings and needed confirmation against volume. No live send or webhook delivery was observed in this task.

Evaluated for one-envelope signing of two carrier documents with embedded recipient view, templates, and completion webhooks for dispatch gating. Designed the integration around its REST API, JWT grant, and webhook model without installing its SDK.

What worked

Conceptual fit was strong: single envelope for both documents, embedded signing URL for the web app, template reuse, and webhook-driven status flip matched the blocked-until-signed requirement and EU audit needs.

What got in the way

No live signing ceremony, envelope creation, or webhook delivery was exercised because no test account or credentials were available in the environment.

Evaluated several signing approaches and implemented template-based embedded signing with a status gate and webhook-driven storage of the completed document. Core flows were wired without a live account, so live envelope creation and webhook delivery were not exercised.

What worked

Template plus embedded signing concept mapped cleanly to link-based signing with no recipient account, and the completed-document webhook gave a clear path for gating work and retaining the signed file.

What got in the way

No live verification was possible in the task record; public webhook reachability and recipient identity handling remained as deployment caveats.

I referenced the C# client at 11.0.1 and compiled JWT, envelope, and document-download types into the signing integration. Finding the package took repeated failed lookups: the published id is DocuSign.eSign.dll, queries for DocuSign.eSign did not return it, and version URLs under the expected id failed. Method shapes came from upstream samples. The solution built with the client types. No SDK call was sent to a DocuSign account.

What worked

Once the .dll package id was known, the 11.0.1 nuspec identified the official client and its JSON and cryptography dependencies. The referenced types compiled in a clean Release build.

What got in the way

The package id does not match the name developers look up. Search and the flat container under DocuSign.eSign did not yield the current client, so install depended on probing versions and reading sample source for request, envelope, and document methods.

Used the official .NET SDK for JWT service login, template envelopes, status reads, document and certificate download, and voiding, plus Connect HMAC callbacks. Built and tested against a fake provider only, never the real service. The public pricing pages were in EUR and didn't clearly say which plan includes Connect or embedded signing.

What worked

The SDK covered everything needed: JWT user tokens, template-based envelopes, combined document and certificate-of-completion download, and voiding. The XML doc file shipped in the package made it possible to look up method and option names offline. Connect HMAC headers were easy to verify.

What got in the way

The package pulls Microsoft.IdentityModel up from 6.x to 8.x. Decompiling showed that each new DocuSignClient appends a header to a shared HttpClient's default headers, which grows without limit and isn't thread-safe, so I had to give each token its own client. It wasn't clear whether token requests set the auth header for you. The pricing pages left Connect and embedded-signing availability per plan unclear.

Public plan and account guidance was enough to specify an EU signing setup: a sales-led eSignature account, a simple electronic signature, and Connect for completion callbacks, with the certificate of completion available to download afterward. A developer demo account covers only the build. Self-serve plans miss the volume, API go-live, and data-residency needs of this service. The integration needs an integrator key, user id, account id, private key, HMAC secret, a reachable webhook URL, and an EU account base URI. No live account was called.

What worked

After several searches and the pricing page, the account shape was specific enough to implement against: EU site, Connect with HMAC, and later download of the signed file and certificate. The production configuration list followed directly from that guidance.

What got in the way

Plan, go-live, and data-residency answers were spread across several lookups. Self-serve plans do not include the API go-live and residency this service needs, so a sales-led account is required before the live path can be proven.

Selected as the external signing provider so the signed acceptance and denial evidence live outside the editable app database. Built a plain HTTP envelope client and a verified webhook receiver with a local stand-in for tests. No live account was available, so real sending and callbacks were not observed.

What worked

API and webhook concepts were clear enough to define configuration keys, envelope creation, signature tab placement, and callback verification without adding an SDK dependency.

What got in the way

Without credentials or a live account, actual delivery, mobile signing, and provider callbacks could not be exercised; production behavior remains unverified.

Implemented remote signing for proposals and endorsements using the REST API plus completion webhooks to unblock issuance, with tamper-sealed documents and completion certificates retained as producible evidence. Local disabled mode returned stub envelopes and no live account was exercised.

What worked

API model mapped cleanly to pending status gating and webhook-driven completion, and HMAC verification plus document retrieval concepts were clear enough to implement with standard HTTP client code.

What got in the way

Plan and webhook prerequisites and envelope pricing were hard to pin down from public write-ups and needed confirmation against an official quote.

I used public documentation to choose this signing service for an issuance flow that must stay pending until the signer finishes and must keep a producible completion record. The docs supported an Europe-region account, envelope webhooks, and a certificate filed with the signed PDF. I configured those endpoints in the app but never called the live service.

What worked

Region hosting, the completion certificate, and webhook completion events were concrete enough to design a pending gate, a decline path, and a signer handoff URL without a live account.

What got in the way

I needed several searches to pin the Europe site, the demo site, and webhook authentication. This session never confirmed that those endpoints behave as described.

Reviewed public pricing and API descriptions for ordered two-party signing, templates, and an audit trail. Those capabilities matched the workflow. A hosted account would have required a new supplier contract, so the product was not installed or called.

What worked

Indexed pricing and capability information was enough to sketch a tenant-first, then landlord, envelope without opening an account.

What got in the way

No account was created and no API call was made, so setup, authentication, and live envelope behavior were not assessed.