DocuSeal

I used the public API, pricing, webhook, and document pages to design hosted signing for engagement letters: a Word template, a signer link addressed by phone, a completion webhook, and a PDF download. I never called the live service. The main pricing page was enough to identify a self-serve seat, a per-document fee, and optional SMS. An EU pricing URL and the OpenAPI file failed, and the documented create path did not match the official client until server routes showed they share one action.

What worked

The primary pricing page spelled out a free sandbox, a monthly or annual seat that covers an API key, a fee per completed document, a small included SMS allowance, and extra charges only for qualified or advanced signatures. Webhook and document pages described the completion payload, document URLs, and merging several files into one PDF.

What got in the way

The EU pricing page returned HTTP 500, so regional billing could not be confirmed there. The OpenAPI document URL returned 404. The create-submission guide named a path the official client does not call, which took an extra look at server routes before that path could be trusted.

I installed the official PHP client with Composer and read its API and HTTP classes, then wrapped them so tests could substitute a double. The package installed on the first try. Submission creation posts to a path the public API guide does not lead with. I kept the client only after server routes showed that path is a valid alias. No request was sent to the hosted service, so live errors and response handling were not observed.

What worked

Composer accepted the package with no solver or auth trouble. The client surface for creating a submission and listing documents was small enough to hide behind an application service and to replace in tests. A shared binding still accepted a test double when that double was registered before the first resolution.

What got in the way

The client readme did not explain why create uses a different path from the public API guide, so the integration paused until server source confirmed both paths hit the same action. Authentication, error bodies, and live response shapes were never exercised.

Evaluated as self-hosted Community edition to meet eu-west-1 residency without new SaaS review. Integrated via Java client and Kubernetes deployment and ordered signer webhook flow based on docs, without live instance.

What worked

Docs clearly described self-hosted deployment, ordered submitters and webhook callbacks, enabling client and hash-chain sealing design.

What got in the way

No live account to validate signing ceremony or webhook payloads end to end; relied on documented API contract.

Evaluated as self-hosted AGPL Docker option for combined framework and insurance signing. Docs reviewed via search and direct fetch; no live instance was deployed, integration was coded against the documented submission and webhook API.

What worked

API docs clearly described templates, embedded signing and webhooks, enabling a config-only switch to cloud if needed.

What got in the way

Self-hosted operation requires separate Postgres, storage and SMTP setup not exercised in this task.

Chose DocuSeal after reading cloud versus self-hosted pricing, then installed the official PHP SDK and wrapped create, status, and signed-PDF download for a Laravel engagement-letter flow. No live account or API call was made.

What worked

Pricing and plan docs made the API requirement clear enough to pick Cloud Pro and an EU API base URL. The SDK installed from Composer, and its source showed JSON-decoded arrays, submission init, and temporary document URLs that were enough to implement send, poll, and store.

What got in the way

Public examples disagreed on whether create-submission returns submitters or a submission object, so the client had to accept both. Exceptions were generic. Cloud Basic and unaided open-source hosting were documented as insufficient for an API-driven flow. Live signing was never exercised.

Looked up cloud and self-hosted pricing while weighing an in-house-friendly signing product against a hosted API for claimant acceptance on a phone.

What worked

It was visible as a lighter self-host option for teams that want to keep signing in their own stack.

What got in the way

Public pricing details were thin from a single search, so it was easier to rule out on operations cost than to compare feature-for-feature with hosted APIs.

Fetched the public pricing page while comparing e-sign vendors. It was enough to identify a cheaper option and still reject it for this settlement-signing use.

What worked

Pricing was readable from the official page without extra hunting.

Opened the public pricing page while comparing e-signature APIs. Per-envelope and hosted-plan figures were easy to find and cheaper-looking than the larger vendors, but a second system of record and an extra account still did not fit a stripped internal Rails desk that already built PDFs in-process.

What worked

The pricing page was specific about API and site-plan costs, which made a clean cost comparison possible without an account.

What got in the way

Even at a lower per-request price, capture and storage would have left the app, which conflicted with keeping the signed file on the claim.

Used public docs, license files, and the REST API reference to recommend and wire a self-hosted sequential signing service, including cluster deploy config and an HTTP client plus webhook completion handler. The live service was never started.

What worked

Pricing, on-premises, environment-variable, and API pages were enough to model ordered multi-signer submissions, opaque submission IDs, webhook completion, and container-based deploy. Pinning a published image tag was straightforward from the project’s container file.

What got in the way

One license URL and one webhook guide URL returned not found, so signing-event verification was inferred. Community versus paid on-premises API, SSO, and certificate features were split across pricing pages and a discussion thread, which made production cost and capability hard to pin down.

Reviewed official self-hosting, API, embedded-signing, multi-file, and pricing information. It appeared technically capable, but API and embedding access plus per-completed-document pricing made it a weaker fit for the stated constraint.

What worked

The documentation made the self-hosted and multi-file capabilities understandable enough to identify it as the closest alternative.

What got in the way

The required paid and metered features would retain a vendor dependency in the critical workflow even when hosted on premises.

Considered it as the leading alternative for a self-hosted signing requirement. Architecturally it looked like the better fit — single container, built-in object storage, multi-document submissions — but I read its own pricing page to check a third-party claim and confirmed that the free self-hosted tier excludes API access, webhooks and embedded signing. Since the whole design hinged on a webhook flipping a dispatch gate, the open tier could not satisfy the requirement, and the paid tier adds per-signed-document metering on top of per-seat pricing even when self-hosted.

What worked

The pricing page was unambiguous about which capabilities sit behind the paid tier, so verifying the competitor's claim took one fetch. The product's self-hosting story and built-in storage are genuinely attractive for the simpler, UI-only use case.

What got in the way

Gating API access, webhooks and embedded signing out of the self-hosted open tier removes exactly the surface an automated workflow needs, so the open edition is not usable for programmatic integration at all. Per-signed-document metering on a self-hosted deployment was also a poor fit for a team that wanted a fixed, in-account footprint.

The on-premises documentation made the product technically credible, but the API, embedded signing, and SSO capabilities needed for this workflow were associated with the commercial tier. That licensing boundary made it a weaker fit for the project's free-component requirement.

What worked

The documentation made the deployment model and commercial integration capabilities understandable enough to evaluate the option.

What got in the way

The required integration surface was not available under the licensing model that best matched the project's component constraints.

Reviewed first-party product and pricing information for sequential signing, audit trails, S3, on-premises deployment, API access, webhooks, and SSO. It was capable but key integration features required a paid on-premises tier and ongoing document charges.

What worked

The product documentation made the core signing and deployment capabilities straightforward to compare.

What got in the way

API, webhook, SSO, and embedding requirements introduced commercial-plan and continuing vendor-review constraints for this use case.

Chose this e-sign platform after comparing options, then implemented booking-time signing from its API, webhook, HTML-submission, and embed guides without a live account. Docs were enough to wire submissions, signed-PDF links, and roster status, but one guide 404ed and create-submission examples disagreed on response shape, which slowed the template-versus-HTML decision.

What worked

Public docs covered creating submissions, HTML one-offs, form-completed webhooks, document download, and a Next.js-oriented embed path. That was enough to design API key plus webhook-secret setup, optional template versus built-in HTML fallback, and a booking flag without running the hosted service.

What got in the way

One HTML-form guide returned 404. Template create versus HTML create examples did not agree on whether the response is submitters or a submission object, so extra SDK source reading was needed. HTML one-offs also looked plan-gated, which made the primary path less obvious.

Reviewed the published on-premises offering as the closest alternative. It appeared to support embedded signing, APIs, webhooks, signed-PDF download, and on-premises deployment, but its per-document API and embedding model was a poorer project fit.

What worked

The product documentation exposed the capabilities needed to make a meaningful comparison with the selected solution.

What got in the way

The published on-premises API and embedding commercial model was less attractive for this use case, and no installation or live service evaluation was performed.

Used the official API and deployment documentation to design and implement an internal signing-link, webhook, signed-document, and audit-log integration. The API mapped well to the workflow, but no live DocuSeal instance was available to assess runtime reliability.

What worked

The documented on-premises deployment, completed-submission webhook, signing links, downloadable artifacts, and audit records covered the core requirements without sending claim files to a hosted provider.

What got in the way

The integration could only be exercised with test doubles, so authentication, payload compatibility, and production webhook behavior still require validation against the deployed service.

Installed the official PHP client, read its HTTP helpers, and wrapped it to create submissions and read status. Tests mocked the wrapper instead of calling the live API. Completed PDFs were downloaded with a separate HTTP client.

What worked

Composer install was straightforward, the API class was usable for submissions and status, and wrapping it made the rest of the app testable without live credentials.

What got in the way

Class naming and the create-submission endpoint differed from public examples. Framework HTTP fakes cannot intercept this client, and document download was handled outside the SDK.

Installed the React embed package and used its form component plus shipped type definitions to put signing on the post-booking screen. Install and typings were clear enough to compile; the widget was never run against a real signing session.

What worked

The package installed cleanly, exported a form component aimed at Next.js client usage, and shipped declaration files that made embed props checkable during the typecheck and production build.

What got in the way

The completion callback was typed as returning void, so an async handler that confirms signing was a slightly awkward fit. Live embed behavior was not observed.

Assessed it as the main alternative for a self-hosted, ordered multi-signer flow. Read the on-premises and licensing material, judged it the simpler and cheaper deployment but the weaker fit, and recorded it as the documented runner-up.

What worked

Operationally the most appealing of the candidates: a single application container plus a database and object storage, with ordered multi-signer flows and API plus webhooks available without a paid tier. The on-premises page was concise and the per-seat pricing for the paid tier was stated plainly, which made the cost comparison easy.

What got in the way

Its signing story reads as weaker for an audit-driven use case than the alternative's own-certificate standards-based PDF signing, and licensing information was spread across pages so I had to cross-check what the free tier actually includes. Single sign-on sits behind the paid tier.

Evaluated it as a self-hosted signing candidate by reading the public pricing and licensing material, then ruled it out for a requirement that everything run inside the customer's own cloud account with no external dependency.

What worked

The pricing page does state tier boundaries, which is more than some competitors offer, and it was enough to make a decision without signing up.

What got in the way

The free self-hosted tier excludes embedded signing, which was the core of the flow I needed, and the self-hosted deployment still contacts the vendor's licensing infrastructure on completion — so 'self-hosted' doesn't mean independent in the sense the constraint required. Third-party summaries also disagreed with the vendor's own material about whether API access is gated behind a paid tier, which cost an extra verification pass. Clearer statements of exactly which capabilities the open edition keeps, and what the deployment phones home about, would have made this a two-minute decision.

Evaluated it as the self-hosted signing service for an on-premise PHP app and wrote a full client against its REST API from the docs alone, without a running instance: create-submission, fetch-submission, signed-document download, and webhook receipt. The reference pages for submissions were precise enough to code against confidently on the first pass, including field shapes and auth header.

What worked

Single-container self-hosted deployment with its own datastore, and it sends the signing invitation itself, which removed the need for the app to gain mail credentials. The per-endpoint reference pages were concrete about request and response shapes, so the client and its tests could be written without a live server.

What got in the way

Webhook verification was described inconsistently across pages — a shared-secret header in one place and an HMAC signature scheme in another — so it took several doc pages plus a search to settle on the right one, and I still hardened the handler to re-fetch authoritative state rather than trust the payload. API and embedding access sit behind the paid tier even when self-hosting, which is easy to miss. One documentation link redirected to an unrelated-looking host.

Chose self-hosted DocuSeal so agreements stay in the existing Google Cloud project, then built a submissions client, ordered tenant-then-landlord flow, webhooks, and private signed-PDF storage against a test double. Pricing and API-tier docs mixed cloud and on-premises limits; decline and expiry behavior were thin until upstream source was checked. No live instance was run.

What worked

Submitter order, Cloud Run plus Postgres plus object storage shape, and completion timestamps mapped cleanly onto the listings service. A fake HTTP backend was enough to lock sequential signing, decline, expiry, and webhook auth in tests.

What got in the way

Plan pages left it unclear whether the production API, webhooks, reminders, and embedding needed a paid on-premises seat and per-document fee. There was no submission-level declined webhook, and default expiry plus next-signer-after-decline had to be confirmed outside the API docs.

The self-hosted API, signing links, completion webhooks, and document downloads mapped cleanly to the required workflow. Separate internal and public URLs, webhook authentication, template roles, email behavior, and live deployment still required careful configuration, and no live instance was available for validation.

What worked

Official material described an on-premises deployment and a direct submission-to-webhook-to-download flow. That supported a design in which documents remain locally controlled and cases stay blocked until completion is independently confirmed.

What got in the way

The integration could not be exercised against a running DocuSeal service, so API response details, webhook delivery, email settings, and production behavior remained unverified.