Youtrust API

I used the signature, iframe, and webhook docs plus an OpenAPI description to implement embedded signing: create a request, collect signer links, verify a completion webhook, and download the signed PDF and per-signer audit trails. That was enough to shape the flow, but naming, field geometry, and download details took repeated passes, and the live API was never called.

What worked

The docs covered an embedded request that stays open until every signer finishes, a completion webhook distinct from per-signer events, audit-trail downloads, and advanced signatures with an email one-time code. That matched a small API that already creates a remote object and updates local state from a verified webhook.

What got in the way

Retrieved pages used the Youtrust name while the API host, sandbox URL, and webhook signature header still used Yousign, so a rebrand was hard to separate from an inconsistent page. The specification text on hand looked incomplete for downloads. Field height, page coordinates, and the signer-name character set were easy to misread. Qualified signatures cannot be embedded, and the documented one-second webhook acknowledgement conflicts with downloading files first.

Built a REST client, webhook handler, and contract activation flow against the e-signature API using public docs only. The API covered qualified EU signatures, multi-party completion, and evidence download well enough to implement, but several behaviors were split across pages and did not match an in-app QES experience.

What worked

Docs described sandbox versus production keys, HMAC webhook verification, per-signer signature levels, a completion event only after every required signer, and separate downloads for the signed file and audit trail. That was enough to keep contracts draft until completion and store evidence without a live account.

What got in the way

Qualified signing cannot be iframed, so those signers leave the product. Completion webhooks expect a very fast acknowledgement, which conflicts with downloading files in the request. Metadata is not part of initiate. Qualified signing stays off in sandbox until support enables it, and leftover prior-brand names on hosts and headers made the docs slower to assemble.

The documentation exposed the required AES level, SMS OTP, signer links, webhooks, document downloads, audit evidence, and EU hosting details. The API integration was implemented, but no live account or credentials were available to exercise it.

What worked

The API model mapped cleanly to the case workflow, including explicit per-signer AES configuration and asynchronous completion handling. Official materials were sufficiently specific to design storage and compliance gates.

What got in the way

Live reliability, account-level AES activation, webhook delivery, and actual signed-document downloads could not be assessed without credentials and an enabled account.

Chose this REST API for sequential tenant-then-landlord Advanced Electronic Signature, webhook completion, and audit-trail download, then implemented a client against published v3 docs and a local fake. Never called the live service. Official getting-started and signature-level pages were missing after the rebrand, AES is sales-gated, and AES pack pricing was not published.

What worked

Create-signature-request material plus webhook HMAC and ordered-signer behavior was enough to model AES with SMS OTP, activation, document download, and audit-trail retrieval without an official SDK.

What got in the way

Primary documentation URLs returned not found, so setup details came from searches, a later docs page, and a third-party pricing writeup. Self-serve seat plans were a poor fit; API volume and AES had to be treated as a sales contract rather than a flag in app config.

Chose this EU-hosted advanced electronic signature API for embedded iframe signing, webhooks, and signed-PDF download. Implemented a first-party HTTP client, webhook handler, and CDN iframe wrapper from public docs without a live account. Official webhook pages 404'd, AES add-on unit prices were not listed, and a recent rebrand split the marketing site from the API, so setup details took extra searching.

What worked

Developer docs that did load were enough to design the flow: sandbox versus production bases, organization-scoped API keys, iframe domain allowlists, signature-request create then activate, document download, and webhook events. API Plus plus the AES add-on mapped cleanly to embedded signing with SMS identity and no vendor-sent mail.

What got in the way

Webhook handling URLs returned 404, so HMAC verification had to be inferred from search results. AES pack pricing and ISV terms were not self-serve. The public brand and API hostname disagreed after the rebrand. No sandbox or production call was made, so live signing, webhooks, and embedding were never observed.

The API documentation supported an implementation for hosted advanced eIDAS signing, identity checks, SMS authentication, document upload, status reconciliation, and evidence download. No live service request was made, so runtime reliability was not assessed.

What worked

The documented API covered the full required workflow, including DOCX/PDF handling, smart anchors, advanced-signature selection, hosted signing, signed-document retrieval, and audit trails.

What got in the way

Pricing for the advanced-signature add-on was not public, branding had shifted from Yousign to Youtrust, and some capabilities required account-side enablement. Documentation was spread across old and new domains.

Chose this EU e-sign API for Advanced signatures, then implemented request creation, SMS OTP, webhooks, and signed-file download from the docs. Application plans do not include the API; API Plus is an annual sales contract and Advanced signing is a separate quoted add-on. One documented path 404ed; other docs and an llms index were enough to write the client. The live API and sandbox were never called.

What worked

Docs covered signature requests, webhooks, authentication modes, signature level, smart anchors, and document download in enough detail to model the server client and event handling without an official SDK.

What got in the way

A create-signature-request docs URL returned 404. Advanced-signature pricing is not public and is sales-activated. Webhook payloads needed extra nesting fallbacks. No live or sandbox call was made, so request, HMAC, and download behavior were not observed.

Evaluated the API as a technically credible qualified-signature alternative with French infrastructure. Public material did not make the exact API entitlement and effective qualified-signature pricing sufficiently explicit for a firm selection.

What worked

The available material established that a qualified-signature offering and API plans existed.

What got in the way

The entry price did not establish the real QES cost, and the required plan, module, or volume commitment appeared to require an enterprise quote.

Integrated multi-party embedded signing, completion webhooks, evidence download, and a pre-send company-registry authority check from public API docs. No live account or sandbox calls were made; a local HTTP client and mocked tests were written instead.

What worked

Docs were detailed enough to map upload, signers, iframe links, completion events, audit-trail download, and legal-representative checks onto an existing draft-until-signed contract model. Sandbox versus production and which secrets belong in env were clearly separated.

What got in the way

Plan gating (API versus app, Plus versus Pro, Verify add-on, yearly quotas) took many searches to pin down. Branding still mixed a prior product name with the current one, and an early client call used the wrong verification arguments until the request docs were re-read.

The API supported template-based signature requests, email authentication, webhooks, audit evidence, and signed-document downloads, which matched the desired booking workflow closely.

What worked

Its API surface covered the full proposed lifecycle, and a reusable template avoided embedding legal text or PDF coordinates in application code.

What got in the way

Pricing details were difficult to extract from the dynamic public site, and the integration could not be exercised against the sandbox because no API key, template, or webhook secret was available.

Chose this REST API for eIDAS advanced signatures and EU residency, then implemented a signature-request client, HMAC webhooks, and document download from the public docs. No sandbox or production account was available, so the API was never called.

What worked

Docs that loaded covered multi-document requests, an explicit advanced-signature level, webhook events, HMAC verification, and download of sealed files. That was enough to design a one-session two-document flow and a dispatch gate without an official SDK.

What got in the way

Several published doc URLs 404'd after the rebrand, AES pricing and enablement were sales-gated, and response shapes for documents on a request were ambiguous, so IDs had to be stored at send time. Production and even sandbox AES could not be turned on without a vendor account.