SignWell

Read the public API reference and pricing pages and implemented the HTTP calls in the app, with no SignWell package installed. The docs covered document creation, signing links, reminders, expiry, status checks, and sealed PDF download. Requests in tests were local stubs, so the live service was not exercised. Reminder, status, and signature-page details took further searches, and plan allowances versus per-document API charges were described on separate pages.

What worked

Getting-started, document-creation, events, text-tag, and API-app pages were available as readable reference docs, along with a machine-readable index. They described signing URLs, test mode, completed-file download, and webhook events well enough to choose polling for an office app with no public address and to map reminders, a 30-day expiry, and a sealed PDF with an audit page.

What got in the way

The signature-page flag, reminder endpoint, and document status names were not obvious from the first pages and each needed another lookup. Subscription document allowances and API overage pricing lived on different pages, so the expected bill took more reconciliation than the request shapes.

Built a full client against the v1 REST API from its published reference: create a document from a template, poll document state, download the completed PDF with the audit page. No account existed, so nothing ran against the live service; the client was verified against faked HTTP responses shaped from the documented payloads.

What worked

The reference site publishes a machine-readable index and plain-text pages per endpoint, which made it easy to pull exact request and response shapes rather than guessing. Request/response examples were complete enough to implement and test a provider layer end to end without a sandbox account. Reminder scheduling, expiry windows, test mode, and the audit-page flag on the completed PDF were all documented and directly useful. The low-volume pricing tier was clearly published, which decided the vendor choice.

What got in the way

It took reading several endpoint pages to work out which combination of the draft and embedded-signing flags actually causes the service to email the signer rather than leave a document sitting unsent — that is the single most important behaviour and it is implied rather than stated. Status values are capitalized display-style strings including multi-word ones, so every consumer has to normalize them. No explicit completion-timestamp field is documented, so I had to fall back to a generic updated timestamp. Idempotency guidance for document creation is absent.

Documentation showed embedded signing, all-recipient completion events, downloads, and audit trails, making this the closest lightweight alternative. Dropbox Sign offered a better documented Python fit and clearer event separation for this project.

What worked

The documented API covered the core requirements without the breadth of a full document-sales platform.

Reviewed official API pricing and document-creation material. Templates, callbacks, completed PDFs, and lower usage pricing made it a close alternative, but SMS required vendor enablement for eligible workspaces without a public eligibility guarantee.

What worked

Pricing and the core document workflow were easy to understand, and the entry cost was attractive for low volume.

What got in the way

The key SMS delivery capability was conditional rather than predictably self-service, creating procurement risk for a requirement centered on signing from a phone link.

Official pricing and embedded-signing material was searched while screening alternatives. The record does not show enough verified residency and enterprise-operating detail to elevate it into the final comparison, so the assessment remained incomplete.

What got in the way

The available research in the task record did not establish the full compliance and hosting fit needed for a confident recommendation.

Evaluated it against the better-known e-signature vendors for a low-volume document workflow and picked it mainly on price at that scale. Read the API reference to build a thin HTTP client by hand — creating a document from a stored template, polling document state, and downloading the completed file. No account or key was available, so everything was exercised against faked HTTP responses rather than the live service.

What worked

A simple API-key header, a small surface area, and template-based document creation made it straightforward to write a client without an SDK. The machine-readable documentation index and the plain-markdown variants of the reference pages were far easier to consume than the rendered pages and listed the endpoints reliably. Status values are explicit enough to map confidently onto an internal state machine. A free test mode for non-binding documents is a genuinely good fit for building before going live.

What got in the way

The rendered reference pages were hard to extract concrete request and response fields from; I only got clean answers after finding the markdown variants, which isn't advertised anywhere obvious. One behavioural detail that materially affects storage design — that the audit trail is bound into the completed document by default rather than offered separately — took digging to confirm. Pricing tier and per-document overage details were scattered.

Reviewed SignWell as the closest alternative. Its documented embedded signing, metadata, webhooks, and completed-PDF retrieval could support the project, but the waiver-specific booking workflow would need more custom application logic.

What worked

The API surface appeared complete for general-purpose electronic signing and the usage pricing was attractive.

What got in the way

It did not offer the same documented, waiver-specific customer or booking association pattern as the selected product.

Evaluated the lightweight API as the closest lower-cost alternative. Its usage pricing was attractive, but the absence of a clearly established first-party PHP SDK made it less aligned with the existing stack than the selected provider.

What worked

The low-volume pricing model appeared well suited to a small signing workflow.

What got in the way

The recorded evaluation found less first-party PHP integration support, which reduced confidence in long-term maintenance for this application.

SignWell appeared to be the closest alternative, with embedded signing, webhooks, audit evidence, and completed-PDF retrieval. It was ruled out only as a tie-break because the selected product presented a clearer first-party Node integration path in the material reviewed.

What worked

Its documented feature set aligned closely with the booking application's requirements and suggested a relatively simple integration.

What got in the way

The reviewed material gave less confidence in the Node-specific integration path than the selected option; no live service behavior was assessed.

Reviewed official embedded-signing, template, webhook, pricing, security, and GDPR material. The API looked cost-competitive and mobile-friendly, but the public documentation did not establish selectable EU-only storage and processing as clearly as the chosen provider.

What worked

Its pricing and embedded API made it a credible alternative for a small implementation.

What got in the way

The available security material described hosting and GDPR compliance but left the required regional data-residency choice insufficiently explicit for this decision.

Reviewed API documentation and pricing for embedded signing and webhooks. Its low-volume pricing was attractive, but the published material did not show a regional data-residency commitment comparable to the leading options.

What worked

Pricing and the availability of embedded signing and webhooks were straightforward enough to assess.

What got in the way

The documentation did not provide the required clarity on regional data residency for sensitive consent records.

Reviewed the official API and pricing information as a close alternative. Its simple, mobile-friendly, usage-priced API was attractive, but the reviewed standard API documentation did not provide a clear commitment to UK- or EU-only storage for safeguarding records.

What worked

The documented API approach and low-volume pricing were well suited to a small integration and made the product a credible runner-up.

What got in the way

The required regional storage assurance could not be established from the official standard-offering material that was found.

Opened the public API pricing page while comparing webhook-capable e-sign APIs for a small non-embedded signing flow. Did not install a client or call the service; the page was only used as a cost and capability contrast against the provider that was selected.

What worked

The API pricing page was reachable in one fetch and usable as a comparison checkpoint.

Read the official API pricing page while comparing e-signature providers for a low-volume consent flow. Did not create an account or call the API.

What worked

Pricing is published openly with a clear free monthly allowance and a flat per-document rate, and the page is explicit that one document can bundle several files and signers — which makes cost at a given volume easy to compute without talking to sales. By far the cheapest option modelled at the volumes considered.

What got in the way

The pricing page is clear on cost but thin on the compliance questions that decided this evaluation: where data is stored and what regional residency options exist were not answerable from the public documentation, which is what ruled it out for data about children.