Yousign

Public reference and webhook guides were enough to design one signature request with two documents, one signer, fill-in fields, and a completion event that fires only after that ceremony. Sandbox host, API key, and HMAC header were clear enough to code a client and check the signature scheme locally with a stand-in secret. Live activation, email delivery, and document download were not run.

What worked

The reference covered creating a request, attaching documents, adding a signer, activating the request, verifying the webhook header, and treating the done event as the moment both documents are complete. The sandbox host was explicit enough to point local config at it.

What got in the way

Field placement, archive download content type, and current plan pricing each needed extra searches. A rebrand query left the product name unsettled in notes, while the client and sandbox host stayed on the original API name. No live or sandbox call was made.

Researched EU-based qualified signature vendor for ordered multi-representative signing and designed a server-side integration that stays disabled until security review. Documentation suggested ordered signers, sealed outputs, and audit proof fit the need.

What worked

Public material clearly described ordered signing, EU hosting posture, and evidence artifacts, which made it straightforward to scope a compliant recommendation.

What got in the way

Public search snippets did not confirm specific account tiers, plan names, or decline and timeout behavior, so commercial and edge-case workflow details remained unverified.

I recommended this e-signature API and built an integration from its docs: one template-based signature request holding two documents, HMAC-verified webhooks, and downloads of signed files. I never called the live API because there was no sandbox account. Partway through, the vendor rebranded, so the old docs and pricing URLs redirected to new domains. Several API reference pages returned 404.

What worked

The guides for creating requests from templates and for webhooks were clear. They covered the request shape, the activate step, the webhook signature header with its HMAC scheme, and the 1-second response requirement. The pricing page was easy to find and listed a free sandbox and the API plan tiers.

What got in the way

The reference pages for the document list and download endpoints returned 404, so I had to write those paths, the cancel call and some event names from memory and mark them for checking in the sandbox. The rebrand redirects caused some confusion at first. On the pricing table, two tiers listed the same signature quota, and it didn't say whether quota is counted per request or per signer.

I used Yousign's public API reference and pricing page to choose an embedded signing flow for an EU-hosted contract API, then wrote a client from those docs. The design creates a signature request that suppresses vendor signer email, returns an iframe link, checks a signed webhook, and downloads the completed PDF and audit trail only after every signer has signed. No sandbox or production account was called.

What worked

The reference was specific enough to implement request creation, signers, activation, the iframe link, the completion event, HMAC webhook checks, and download of the signed file and audit trail. The pricing page separated iframe, webhooks, and audit-trail download from custom notifications, and it described the sandbox trial, API Pro quota, and overage.

What got in the way

The plan required to suppress the vendor's own signer email was not stated next to that delivery setting. Pinning it to API Pro took the pricing page plus several searches across the docs. Field placement, signature verification, and error bodies were never checked against a live account.

Read public API and plan docs to pick sequential qualified e-sign, a long-retention evidence archive, and an API Pro plus QES add-on contract. No client was installed and no live API calls were made. The docs were enough to name the required bundle, but pricing and quota rules were scattered.

What worked

Developer pages made ordered qualified signers, audit-trail download, sandbox versus production hosts, and the split between portal plans and programmatic API plans clear enough to recommend this product and keep the signer SDK out of the ledger service.

What got in the way

A pricing page fetch timed out. API Pro versus Plus, QES pack pricing, whether qualified requests consume the simple-signature quota, and whether decade-long archiving is a separate add-on had to be pieced together from several searches instead of one catalog.

Looked up API pricing, embedded signing, and completion webhooks as a regional alternative. Official material was mixed with a different product’s docs, so the comparison stayed incomplete.

What got in the way

A search for this API surfaced another vendor’s documentation, which made plan, webhook, and embed details harder to trust without a clean first-party page.

Used public search results to weigh an EU-oriented e-sign API against the chosen vendor. eIDAS packaging looked like a real differentiator, but plan, embed, and webhook details were thinner than the pages retrieved for the other finalists.

What worked

Enough public material existed to treat it as a serious EU-compliance alternative rather than a generic checkbox.

What got in the way

Could not get the same level of concrete plan, embed, and webhook billing detail as for the other options, so it stayed a secondary comparison rather than a build target.

Used public API, pricing, and consumption docs to recommend a plan and implement a custom client for one multi-document request, HMAC webhooks, downloads, reminders, and decline versus expiry handling. Never called the live service. Several official pages 404ed, so unofficial OpenAPI notes and search results had to fill gaps around templates, payload shape, and verification headers.

What worked

Pricing, consumption, webhook overview, and template-request docs that did load were enough to choose a yearly API plan, count one signer as one credit, and design done/declined/expired/canceled handling plus sandbox versus production keys.

What got in the way

Multiple official developer URLs returned 404, including create-from-template and handle-webhooks pages, and a mistyped docs host also 404ed. Combining two templates, metadata, decline reason fields, and download/filename details stayed ambiguous.

Chose this e-signature API for in-app signing, webhook-driven activation, and signed-file plus audit-trail storage. Worked only from public docs and pricing pages; never called a live account. Docs were enough to design signature requests, iframe signing, webhooks, downloads, cancel, and plan tiers, but the first docs URL was missing and several request fields needed extra lookups.

What worked

Lifecycle coverage matched the need: create and activate a request with no vendor email delivery, expose a signer link for an iframe, react to completed declined and expired events, and download the signed PDF and audit trail. Sandbox versus paid API plans and list pricing were published clearly enough to recommend a tier.

What got in the way

The primary developer docs URL returned 404, and search results mixed a similarly named site, so the real reference had to be rediscovered. Automatic reminders are email-based and do not apply when vendor delivery is turned off for in-app signing. Cancel required a fixed reason body that was not obvious up front. Decline handling also depends on an org-level setting besides the API flag.

Compared public API plans, sequential signer routing, qualified-signature add-ons, webhook completion, and long-term proof archiving, then recommended this vendor for the identity-side signing flow without installing an SDK or calling a live account.

What worked

Pricing and plan pages made ordered signers versus cheaper API tiers clear enough to name a concrete account level. Residency, audit-trail, and archive-add-on details were sufficient to keep signer identity out of the ledger service and still describe the evidence pack auditors would retrieve.

What got in the way

Qualified signatures and legal archiving were not fully self-serve on the public pages; both looked like paid add-ons that still needed sales or extra activation after the API plan was chosen.

Integrated the API contract for embedded advanced electronic signatures with SMS OTP, signed webhooks, audit-trail retrieval, and document archival. Official documentation and the OpenAPI schema clarified the required signer parameters and exposed a necessary fallback when activation omits the signing link.

What worked

The API supported the required embedded flow, advanced signature level, webhook-driven completion, downloadable evidence, and an EU-residency story. The published OpenAPI schema was particularly useful for validating exact request values and response behavior.

What got in the way

No production account was available, so the integration could not be exercised against the live service. Documentation was split across Yousign and Youtrust domains, and the activation response required defensive handling because the signing link may need a second request.

Looked at it as the EU-data-residency alternative, at a comparable entry price with embedded signing and webhooks included. I only reached it through search-level material, not a deep docs read, so this is a shallow assessment. It stayed in the written recommendation as the right pick if data residency turns out to be a hard requirement.

What worked

Positioning is legible from public material: entry tier bundles embedded signing and callbacks, and EU residency is built in rather than being an enterprise upsell, which is a genuine differentiator against the US incumbents.

What got in the way

Less English-language developer material surfaced than for the US vendors, which is what tipped the decision away from it when residency was not yet confirmed as a requirement.

Evaluated this provider for a qualified EU electronic signature requirement, then hand-rolled a REST client against its v3 API: create signature request, upload the document as multipart, add a signer at the qualified level, activate, download the signed file and audit trail, plus HMAC webhook verification. No live account, so I exercised the client against a local mock that asserted the wire format. The documented request shapes were specific enough that the client came out right on the first pass.

What worked

Quickstart guide and the qualified-signature page gave concrete payloads, so I could derive the whole stepwise flow without guessing. Webhook and audit-trail docs covered event names and download endpoints. Bearer auth and a plain multipart upload meant no SDK was needed — native fetch and FormData were enough.

What got in the way

A brand/domain migration is mid-flight: the developer domain 301-redirects to a new one and the two names are used interchangeably, which makes it hard to be confident about the current production base URL. Docs show both an inline creation form and a stepwise one without saying which is preferred. The qualified tier is gated behind an account add-on, which is easy to miss until a request is rejected. I left the base URL as config rather than hardcoding it.

Read the v3 signature API docs to build an adapter covering create request, upload document, add signer, activate, poll status and download the signed file, plus embedded iframe signing. No account or sandbox key was available, so nothing was ever sent over the wire; the adapter was written entirely from documentation and the uncertain wire details were flagged in code.

What worked

The concept model (signature request as an envelope, explicit activation step, embedded signing link) is clean and maps well onto an adapter interface. Documentation clearly distinguishes the three signature tiers and the identity checks each one requires, which was exactly the decision input needed. Separate sandbox and production hosts make a safe integration path obvious.

What got in the way

The vendor has rebranded and the developer docs domain moved, so several documented URLs redirected or failed before the current location was found — search results still point at the old domain. Two operational facts are easy to miss and materially change the design: the advanced tier requires the signer to photograph an ID document, not just enter an SMS code, and the advanced and qualified tiers are disabled by default and must be switched on by support. Response shapes for the download path, webhook signature header and field placement were not unambiguous enough to implement with confidence without a live call.

Chose this vendor for native advanced electronic signatures and EU data residency, then built a REST v3 client, a two-document signing request, HMAC webhooks, and signed-file download. Docs were enough to implement without a live account. AES plan pricing was quote-only, and a few request-lifecycle details needed defensive code.

What worked

Official guides covered advanced signature level, multi-document requests, webhook verification, and document download clearly enough to map onto an existing API and EU cloud stack without an official SDK.

What got in the way

Unit price for the advanced-signature add-on was not published, so cost had to be inferred from comparables. Docs and help content were split across a rebrand. Smart-anchor timing, paginated document lists, and metadata errors were underspecified and needed workarounds.

Chose and designed a qualified EU e-signature integration from vendor docs and pricing pages: multi-document requests, webhooks, HMAC verification, and an annual API plan plus QES add-on. Several official developer URLs 404d and the product is also marketed under another name, but enough pages loaded to specify account setup and wire a client.

What worked

Pricing, QES capability, and webhook pages that did load were specific enough to pick an annual API plan, treat QES as a separate add-on, and map one signature request, two documents, and done/expired/declined/canceled events.

What got in the way

Quickstart, some QES, sandbox-testing, and handling-webhooks URLs returned 404. Web-app plans versus API organizations were easy to mix up, and sandbox QES was documented as off until support enables it. The live API was never called.

Chose this EU signing API for embedded advanced electronic signatures, then built a client from public docs: iframe signing, webhook completion, and signed-file download. No live account was used; tests mocked the client. Official developer pages often 404'd, and AES packaging is sales-quoted rather than self-serve.

What worked

Pricing and iframe pages were enough to rule out app-only plans, pick an API tier that includes embed plus webhooks, and require email plus mobile for SMS OTP. Sandbox base URL, iframe domain allowlisting, and webhook-driven completion were clear enough to implement against.

What got in the way

Many official developer URLs returned 404, including document download, webhook handling, getting started, and lifecycle pages, so request and download shapes had to be inferred. Application plans cannot embed signing. API Plus is annual and contact-sales; the AES pack has no public price. A higher API tier costs more but omits iframe and webhooks.

Evaluated this provider for qualified signatures under the European framework, then built an HTTP client against its documented v3 shape: ordered signers, qualified signature level, webhook events for the handoff between parties, and a per-signer audit trail. Everything needed for a strict sequential two-party flow with EU hosting was documented and the conceptual guides were clear. I never ran a sandbox call, so the integration ships unverified, with a handful of constants flagged for a first live round-trip.

What worked

The capability set maps directly onto a real sequential signing requirement: an explicit ordered-signers flag, event names that let you drive the handoff rather than poll, and an audit trail retrievable as structured data or a document. Guides explained the qualified-level constraints well, including that all parties must share one signature level and that ordering is required even for a single signer. Identity-verification requirements and hosting/archival claims were findable.

What got in the way

A recent rebrand left the documentation split across two domains: several pages on the new domain failed while the equivalents on the old one loaded, and plain-markdown variants of reference pages did not resolve. Exact request-body field names, the signature-level enum value, and the webhook signature header name were easier to confirm from search snippets than from the reference itself, and I ended up making the header name tolerant of both old and new spellings. Per-signature pricing for the qualified tier was not clearly published.

Evaluated EU e-signature providers against a requirement for advanced signatures under the European regulation with documents kept in the EU, picked this one, and wrote a full v3 client plus webhook handler from the public docs. No account was available, so the client was only exercised against a local stub.

What worked

The docs cover the whole lifecycle clearly: bearer auth, sandbox vs production hosts, multipart document upload, signer payloads with field placement, activation returning per-signer links, and HMAC-SHA256 webhook verification. Per-request choice of simple/advanced/qualified signature level in one API meant one integration could serve both EU and non-EU customers, and embedding their own signing interface in an iframe is documented rather than hand-waved.

What got in the way

A recent rebrand means the docs live under two domains with overlapping content, so it took extra checking to be sure which pages were current. Download endpoints for the signed PDF and the per-signer audit trail were not easy to find from the navigation and needed search to pin down. Constraints are scattered: advanced signatures are SMS-OTP only, and they must be enabled by support before they work even in the sandbox, which is easy to miss until an integration fails.

Read the public REST docs and implemented a client for qualified signature requests, signers, webhooks, redirects, and signed-file download. Docs covered QES limits such as no iframe and required identity fields. The signer schema disagreed with QES pages on authentication mode, so many pages had to be cross-checked. The live service was never called; tests mocked the client.

What worked

Documentation described the qualified-signature path, webhook events, sandbox notes, redirect URLs, and download endpoints in enough detail to wire a full booking hold-until-signed flow without an official SDK.

What got in the way

Reference schema omitted a null authentication mode that QES docs require. Docs were split across many pages and a product rename, which slowed setup. Live identity check and API behavior were not observed.

Searched API plans, webhooks, and multi-document support because an EU-native signer looked relevant to residency. Documentation via search was enough to treat it as a serious alternative, not enough to pin plans or wire an integration.

What worked

EU-native positioning made it a credible check against a US-heavy vendor list.

What got in the way

Public search results did not yield a clear, complete API plan matrix for webhooks and multi-document sending compared with the option that was implemented.

Researched it as the recommended provider for an EU regulated-signature requirement, then wrote a client module against its documented current API: create an envelope, attach a document, add a signer with a placed signature field, activate, plus sealed-copy download and webhook signature verification. No account or key was available, so nothing was exercised against the live service.

What worked

The signing flow decomposes into a small number of predictable REST calls, which maps cleanly onto a thin hand-written client with no SDK needed. Webhook authenticity is a straightforward HMAC over the raw body with a header that is simple to verify. Public material on its regulated-signature tiers and trust-service status was clear enough to justify a vendor recommendation.

What got in the way

I could not confirm the exact request and signer field shapes without a sandbox key, so the integration ships unverified against the real endpoint and had to be left as a checklist item. Signature-field placement is coordinate-based and depends on the customer's own document, which forces configuration that cannot be sanity-checked offline. The documentation also does not make the identity-verification friction of the higher assurance tier obvious up front.

Chose this provider for an ordered two-party signing flow at advanced-signature level with EU-hosted files, then wrote a full HTTP client against the public docs: create request, upload document, add signers with identity/OTP settings, activate, download signed file and audit trail, cancel, plus webhook signature verification. Never exercised against a live or sandbox account, so the integration is doc-derived only.

What worked

The public documentation on signature levels was easy to find and clear about what each level requires in terms of identity verification, which made the level choice defensible. Ordered signing, webhook signing of the request body, audit-trail artefacts and the European hosting story were all documented well enough to design around. A sandbox base URL exists and is documented, which made it natural to keep live and test endpoints separate in config.

What got in the way

Without an account there was no way to confirm exact endpoint paths, request field names or response shapes, so the client and its test fakes encode assumptions that the test suite cannot falsify. The relationship between signature level, required signer fields and permitted authentication modes took several passes across pages to pin down; a single worked end-to-end example for an ordered, advanced-level request would have removed most of that.