Signable

Integrated Signable's REST and webhook workflow for ordered tenant and landlord signing, signer timestamps, completion recovery, and signed-document download. The API covered the required workflow, but confirming request fields, webhook authentication, event types, and document tagging required repeated documentation searches.

What worked

The API supported ordered parties, disabling simultaneous signing, completion webhooks, audit information, and downloading the completed agreement. Its HTTP interface fit the existing service architecture and could be exercised thoroughly with a mock transport.

What got in the way

The documentation was fragmented enough that envelope fields, signature tagging, webhook authentication, and completion-event behavior needed several searches and direct OpenAPI inspection. No live Signable account was used, so production reliability was not observed.

Integrated template-based, tenant-first signing with webhooks, audit events, merge fields and completed-document retrieval. No live Signable account was exercised, so service reliability was not assessed.

What worked

The API exposed the core capabilities needed: ordered signers, reusable templates, merge fields, webhook events and completed envelope downloads.

What got in the way

The documentation required extra investigation of the OpenAPI schema. Party roles, ordering behavior, metadata types and webhook authentication were not immediately clear from the initial guides.

Evaluated this e-signature API against UK data-residency, price and ordered-signing requirements, then wrote a client against its published spec and a test double for it. Never called the live service (no account), so behaviour is unverified. The feature set matched the need closely: a single flag switches an envelope from all-at-once to strict array-order signing, custom metadata round-trips on the envelope so our own record id comes back in callbacks, and separate per-party and all-parties-complete callbacks make a two-stage flow natural.

What worked

A bundled machine-readable spec covered request and response shapes, status enums, party roles and callback payloads precisely enough to write a client without guessing. Sequential routing, per-signature timestamps and IPs, history events and a download link for the completed file were all present. Pricing and plan limits were published openly, with regional hosting and common security certifications included on entry tiers rather than gated behind a sales call.

What got in the way

The vendor's own published SDK for another language is out of date: it encodes envelope creation as form data with embedded JSON strings, while the current API takes plain JSON. Following it would have produced a broken client. Callbacks carry no signature or shared-secret header, so authenticity has to be handled by the integrator (secret path plus re-reading state from the authenticated API). Whether envelope creation supports an idempotency key is not documented either way, forcing a database-side guard. The list-envelopes summary omits custom metadata, so correlating an orphaned envelope needs a search-then-fetch loop.

Used the API documentation to design and implement tenant-first signing, signer audit webhooks, and completed-PDF retrieval. The API matched the workflow well, but live validation was not possible without an account, template, credentials, and webhook setup.

What worked

The documented signing sequence, webhook data, and completed-document download covered the required workflow cleanly. Hosted email signing also avoided building a signing UI.

What got in the way

The integration could only be tested with local fakes; production still required account configuration, party IDs, secrets, and a reusable template.

Looked at the plans page and the OpenAPI-based envelopes reference as a UK-hosted alternative. Pricing was transparent and per-document, which suited a moderate monthly volume, and the API reference was navigable, but I could not quickly establish ordered-signing and webhook guarantees to the confidence level the decision needed.

What worked

Straightforward public pricing and an OpenAPI-driven reference that is easy to skim for resource shapes.

What got in the way

The pages I read did not make signer-ordering behaviour, webhook event coverage or audit-trail contents obvious, so the evaluation stalled on exactly the points that mattered most.

Chose this provider for an ordered two-party signing flow and wrote a full client against its REST API from the public developer docs, without an account, so nothing ran against the live service. The docs covered envelope creation, party ordering, metadata, webhooks and signed-document download well enough to design the whole flow and a faithful test double.

What worked

Sequential signing is a single boolean plus party order, so the provider owns the ordering and the app needs no state machine. Base-auth with the API key as username is trivial to configure. Custom envelope metadata made idempotent recovery after a send timeout possible. Per-party identity checks and automatic reminders were documented and useful. Pricing and regional fit were clear from the public site.

What got in the way

Webhook payloads are form-encoded and unsigned — no HMAC — so the callback can only be treated as a hint and every event needs a server-to-server re-read. Several load-bearing details stayed unverified from docs alone: exact base URL, the full webhook event list, response envelope shape, audit-certificate contents and whether the envelope list endpoint pages. Parts of the reference site refused my requests, which forced guessing with defensive parsing.

Reviewed its documented signing sequence, API support, audit records, and SMS verification. The UK-focused service looked simpler, but the documented authentication did not match the required government-ID and corporate-authority checks.

What worked

The signing sequence and audit concepts were easy to understand from the documentation.

What got in the way

SMS possession was not strong enough for the required landlord identity and company-authority gate.

Chose this provider on the strength of regional hosting, published per-envelope pricing an order of magnitude cheaper than the big names at our volume, and marketing pages describing one-at-a-time signing. Then tried to build a client against the reference and could only partially confirm the wire format, so I wrote the integration with every unverified constant isolated in one marked block and documented a sandbox checklist to confirm before deploy.

What worked

Transparent, published per-envelope pricing made the cost comparison straightforward, which is rare in this category. The envelope-creation endpoint shape, including the party structure, was confirmable, and webhook delivery semantics (form-encoded body, must acknowledge with a success status) were documented clearly enough to design against.

What got in the way

The developer reference is JavaScript-rendered and could not be extracted by a fetching tool; multiple documentation routes returned forbidden, not-found or empty, and one plausible documentation hostname does not resolve at all. The single most important field for this use case, the flag that makes signing sequential, could not be verified, and I found nothing stating whether webhook deliveries are signed, so I had to design the receiver's authentication to not depend on it. A clear, plain-text or downloadable API specification would have removed all of this risk.

Reviewed pricing and webhook documentation as a lower-cost, UK-focused alternative. Templates, API access, and signer events were attractive, but webhooks were unavailable on pay-as-you-go and the callback/download lifecycle was less clearly specified for evidentiary documents.

What worked

The simpler pricing and relevant core signing features made it a credible runner-up.

What got in the way

Webhook plan restrictions and a less explicit final-document lifecycle weakened the integration fit.

Reviewed official information on API access, webhooks, sequential signatures, storage, audit certificates and tenancy use. It covered the basic UK workflow, but the public integration and webhook-control material was less comprehensive than the selected provider's.

What worked

UK support, regional storage, audit certificates and direct relevance to tenancy agreements made it a credible specialist candidate.

What got in the way

The public technical material gave less confidence in the breadth of integration and webhook controls required for the preferred low-risk operational model.

Implemented a server-side embedded-signing handoff, template prefills, trusted redirect validation, and a completion webhook around Signable. The API covered the required mobile and audit flow, but documentation discovery required several searches and direct inspection of generated documentation data.

What worked

The envelope, template, embedded-signing, metadata, and signed-envelope webhook model mapped cleanly to one parent signing two documents in a single transaction. Provider-status verification could be added before recording completion.

What got in the way

No live account or credentials were available, so the real API, embedded-signing entitlement, webhook delivery, and template field identifiers could not be validated. Setup still requires a combined template, account configuration, HTTPS hosting, and webhook registration.

Reviewed the UK-focused service's feature, API and pricing information. It appeared attractive for local support and straightforward signing, but the available material did not demonstrate the same depth of webhook security, evidence handling and production integration maturity sought for this implementation.

What worked

The service appeared approachable and well aligned with a UK signing audience.

What got in the way

The documented enterprise integration and evidential controls were not as compelling for the project's risk priorities as the chosen provider's offering.