Youtrust eSignature API

I designed a two-document signing session from the eSignature API v3 guides: one emailed link, advanced electronic signature, SMS one-time code, HMAC webhooks, and download of the completed PDFs. No vendor library was installed and the live API was never called.

What worked

Account, pricing, signature-level, template, webhook, and retry pages were specific enough to name the API plan, sandbox trial, signature enums, HMAC header, and retry timing, and to implement a client plus a mocked activation test.

What got in the way

Guides are split across the old and new product domains while the API host still uses the previous name. The advanced-signature add-on price is not on the public price list, and the level stays off until support enables it. One request from two templates was not a single documented call, and the documented first webhook attempt times out after one second.

Evaluated this EU-hosted qualified e-signature provider and then hand-wrote an HTTP client against its v3 API from the docs alone: create a signature request, attach two documents, place signer fields, activate, poll status, download signed files, and verify inbound webhooks. Never exercised against a live account, so only the documentation and API shape are assessed.

What worked

The documented request lifecycle is simple and maps cleanly onto one request carrying multiple documents, which was exactly the requirement. Email delivery mode meant no public signing page had to be built. Webhook verification is plainly documented: HMAC-SHA256 over the raw body in a sha256-prefixed hex header. The docs site exposes machine-readable plaintext index and per-page markdown variants, which made it fast to locate the exact endpoint references without scraping rendered HTML.

What got in the way

The documentation host now 301s to a different domain following a company rebrand, which is indistinguishable from a hijack until you verify it independently - that cost an extra verification detour. Post-rebrand naming is inconsistent: API hostnames and the webhook signature header still carry the legacy brand while the docs use the new one, so any integration ends up with mixed naming. Signature field placement requires page and coordinate values that the API cannot infer, so the document template layout and the code are implicitly coupled.

Integrated the REST API for tenant-then-landlord advanced electronic signatures, webhooks, and signed-PDF plus audit-trail download. Docs and a test double were enough to ship the flow; the live service was never called, and published pricing for the AES add-on was incomplete.

What worked

After the developer index loaded, guides covered signature level, ordered signers, webhooks, and document download in enough detail to model requests, HMAC verification, and status handling. AES was a first-class API option rather than a bolted-on click-wrap flow.

What got in the way

The first create-request docs URL returned 404. Hostnames and the webhook signature header still used the former brand, which made the current base URL ambiguous. AES pack pricing was not published, and long-term PAdES output was not confirmed against a real envelope.

Used the API specification and documentation to implement AES requests, signer setup, document upload, activation, webhooks, and evidence retrieval. The needed capabilities were present, but exact schemas and webhook details required searching and inspecting the OpenAPI document directly.

What worked

The API exposed the complete signing lifecycle and the signed-document and audit evidence needed for the workflow. Its EU hosting and AES support matched the compliance constraints.

What got in the way

Documentation discovery was fragmented across old and new vendor domains, and the public guides did not make all request fields or webhook-verification details immediately clear. No live service call was made, so runtime reliability was not assessed.