Dropbox Sign

Researched plans and pricing, then built an embedded-signing integration (create embedded request, sign URL, files download, cancel, event callbacks with HMAC check) from the API reference over plain HTTP. Never called the live service; behavior was only exercised with stubbed responses.

What worked

The API reference and events walkthrough clearly covered the embedded create endpoint, sign URL retrieval, the event hash verification scheme, and the rule to wait for the downloadable event before fetching the final PDF with its audit trail appended. That was enough to write the integration with confidence.

What got in the way

Official pricing sources contradicted each other: the pricing page table showed embedded signing on the entry tier while the help article said the Standard API plan is the minimum. Third-party sources quoted a different Standard price, and the monthly versus annual pricing was unclear. I had to tell the developer to confirm with sales.

Search results indicated one signature request can take both files and that callbacks exist. The developer site was not opened, no account was created, and no client was installed. It was set aside on the same grounds as the other US envelope product: account setup did not match a simple API-key secret, and an EU residency option did not resolve vendor jurisdiction.

What worked

Public snippets were enough to confirm a multi-file request and callbacks, which was the capability needed for a single ceremony.

What got in the way

The snippets did not settle plan cost or the exact callback signature. Setup and jurisdiction concerns ended the evaluation before a deeper read.

Researched plans and pricing, then built a plain-fetch client for template-based signature requests, embedded sign URLs, signed-PDF download and webhook verification. Never ran it against a live account. Webhook hash verification and callback-test handshake were exercised only against my own handler using a locally computed HMAC.

What worked

The API model (create a request from a template, get an embedded sign URL, receive a callback, fetch the final PDF) fit well with an existing webhook-driven billing pattern. Free test mode means the whole feature can be built before paying. The HMAC event hash scheme is simple to verify.

What got in the way

Dropbox's own pages disagreed on which plan includes embedded signing: the pricing table listed it on every plan, but a help article required Standard or higher. Included request counts for Standard also differed between sources. Overage pricing wasn't stated. I had to tell the user to confirm with sales.

Public API and plan docs were enough to design an email signing link, a completion webhook, and a small HTTP client without the vendor SDK. A paid API subscription is separate from the website product, test mode is free and non-binding, and a production send without that plan is documented as rejected. No live account was available, so no real envelope, webhook, or file download was exercised.

What worked

The send, callback, and completed-file model fits a desk that must stay approved until the claimant signs on a phone. Email links were documented as opening in a mobile browser. Text delivery was clearly separated as an add-on on higher API tiers, and each non-test send was documented as counting as one request.

What got in the way

Plan pages were hard to read: a slider produced messy figures and search results mixed promotional rates with official tiers. Callback guides disagreed on whether the final PDF is ready when everyone has signed or only after a later downloadable event. The text-message add-on price table never came through in full.

I used Dropbox Sign's public pricing and API docs to choose a plan and design a non-embedded template send, signer email, and a webhook that files the signed PDF. No live account or API call was made. Essentials covers that template send; Standard and Premium are for embedded signing. Test mode is free, and a production send without a paid API plan comes back as HTTP 402.

What worked

The help center and API pricing pages spelled out API-key basic auth, template sends from a template built on the site, free test mode, and which callback fires once the signed PDF is actually ready to download. That was enough to pick Essentials, at the published annual price for 50 requests a month, and to keep the key, template id, and callback address outside the repo.

What got in the way

The first pricing URL returned not found. The current pricing page is a JavaScript calculator, so the extracted text was messy and a slider label looked like a real monthly price. The next volume tier is not a single published figure; it has to be read off that slider.

Installed the official Python SDK at 1.13.0 and used it to shape embedded signature requests, short-lived sign URLs, webhook checks, and zip downloads of the signed document and audit trail. Imports and model inspection worked, but upload shapes, callback parsing, and status-code meaning only became clear after reading the generated client and a help article. No live account or signing ceremony was called.

What worked

The SDK exposes embedded request creation, a sign URL for a signer id, and a zip download that can hold the completed PDF and a separate audit trail. The package installed and imported on the first attempt, and a version-pinned embedded browser script (2.12.0) answered a header check on the public CDN.

What got in the way

Generated hints describe a three-part file tuple while the serializer unpacks two, and a byte stream is a poor upload because it has no filename. A 409 on the sign URL means the request is already signed, which is easy to treat as a not-ready download. Callback helper classes were awkward enough that payloads were parsed and verified manually. Sign URLs expire quickly and on first open, and a separate audit PDF depends on an account setting. The live API and iframe were never opened.

I used the public API reference and plan pages to implement a non-embedded signature request, webhook intake, and completed-PDF download, without a live account or a call to the service. Essentials matched a hosted ceremony, but the signer URL requires an existing account, so the app asks the service to email the hosted page. The pricing page never produced a clear volume schedule.

What worked

The send, event, and file-download references were specific enough to map a completed document into our own record and to keep a test mode that is not legally binding. Plan pages separated ordinary hosted sending from embedded signing and from regional data residency.

What got in the way

Volume prices stayed unclear after the pricing page and follow-up searches. Which tier includes templates, embedded signing, and EU residency was easy to mix up, and the reference is still published under the older HelloSign name. The signing URL cannot be opened by someone without an account, so a redirect from our page was not available on the non-embedded plan.

I installed the Dropbox Sign PHP SDK and used it for template sends, signed-file downloads, and callback checks. Feature tests stubbed the HTTP client, but callback parsing and hash verification ran through the real library and passed. No live signature request was sent.

What worked

Composer installed the package cleanly. Configuration takes the API key as the basic-auth username, and the template-send models plus the callback helper were enough to implement the flow. Tests confirmed event times are cast to strings before the hash is checked, and partial callback payloads still deserialized.

What got in the way

A public URL for an older source layout was not found, and a fetch of the current callback helper did not show the method signature, so I had to read the installed code. Hash checks do not fully validate the event, and required model fields were easy to misread until the tests settled it.

Integrated template-based signature requests, status polling, completed-document retrieval, test mode, and configuration behind a Laravel service. Official documentation supplied the required request, status, and download concepts, but authentication and request details required additional research. No live account or real service call was used, so reliability was not assessed.

What worked

The non-embedded template workflow matched emailed signing links well, and the API exposed the request identifiers, completion state, and signed files needed to enforce the case gate and retain the final document.

What got in the way

The office-only deployment made inbound callbacks unsuitable, so the integration needed scheduled polling. Live authentication and production behavior were not verified.

Evaluated it as the leading candidate on capability grounds, then read its published plan and API pricing pages before committing the customer to anything. The pricing structure ruled it out for a very low-volume use case and I recommended a cheaper provider instead, reversing my own earlier suggestion.

What worked

Capability coverage reads strong on the things that matter for a legally defensible document: tamper-evident sealing, certificates of completion, signer identity and timestamp capture, and recognized compliance frameworks. Plan tiers and API request allowances are published openly, which made the evaluation possible without talking to sales.

What got in the way

API access is a separate product line from the per-seat plans, and that is not obvious from the main pricing page — paying for seats grants no programmatic access at all. The entry API tier carries a monthly minimum that works out to a four-figure annual cost for a team sending a handful of documents a month, and embedded signing sits several times higher again. For low-volume programmatic use the economics are poor, and the structure is easy to misread until you dig into the developer pricing page specifically.

Chose this provider for embedded signing and built the full integration against its Python SDK: create embedded signature request, mint per-signer sign URLs, receive event callbacks, and download the signed PDF plus audit certificate. I installed the SDK and introspected the client classes and model field types instead of coding from memory, then exercised the whole flow with the provider stubbed. Never called the live service, so service reliability is unassessed.

What worked

API-key auth and a single callback endpoint kept the integration small for a one-service backend. The SDK ships a callback-verification helper, and the generated model classes expose their field types, so the request/response shape was discoverable by inspection. Embedded signing meant the counterparty never leaves the product UI. File upload accepts raw bytes as a (filename, bytes) tuple, so documents never had to be exposed via a presigned URL.

What got in the way

The accepted shape for the file upload parameter was ambiguous from type hints alone and I had to read the generated client source to confirm it; I had briefly planned a URL-based workaround because of that. The bundled callback-verification helper compares digests with a plain equality check rather than a constant-time compare, so I wrote my own verification. Embedded signing is gated to a higher-priced tier than the entry plan, which is easy to miss when budgeting.

Used the official API SDK and embedded signing library to implement a two-template mobile signing flow with webhook-driven completion. The API model was sufficiently clear, but templates, credentials, signer-role configuration, and a live callback endpoint were required before an end-to-end provider test could be performed.

What worked

Reusable templates, embedded signing, signature request identifiers, downloadable-document events, and callback verification supported the required workflow and audit trail cleanly.

What got in the way

No live service test was possible because the record contained no provider credentials or configured production templates. Inspecting generated SDK models also involved some filename discovery.

The official documentation and Python SDK supported embedded signing, signer status, callbacks, and completed-file retrieval. Local SDK construction worked, though callback timing required careful interpretation and no live account was exercised.

What worked

The SDK fit the Python service and exposed the request, embedded-session, callback, and file-download concepts needed for the implementation.

What got in the way

The event lifecycle had subtleties: a downloadable event may precede final completion, and embedded sessions should wait for the sent event. These details required extra documentation checks and state-machine guards.

Reviewed current API capabilities and pricing as an alternative for ordered tenancy signatures. The product appeared capable, but its entry API pricing and broader feature set were a weaker fit for this small service than the selected provider.

What worked

The available product information was sufficient to compare its API offering and request allowance with the project's modest signing workflow.

What got in the way

It was not installed or called, and the evaluation found its API tier comparatively expensive for the required volume, so no reliability assessment was possible.

The documentation covered SMS delivery, callbacks, and signed-file download, so the platform was technically viable. SMS being a paid add-on, unavailable in test mode, and generally paired with email weakened the fit.

What worked

The documented API surface covered the signing and artifact-retrieval fundamentals.

What got in the way

The inability to exercise SMS in test mode made the most important delivery path harder to validate before production.

Chose the embedded-signing API as the e-signature provider for a B2B contract app and built the whole integration behind one wrapper module: create embedded request, fetch the signing URL, verify callbacks, download the sealed file. The SDK installed cleanly and its request/response models were easy to introspect, which let me confirm every field and method signature before writing code. No live call was made — no sandbox credentials — so the flow was only exercised against a stub.

What worked

Typed request/response models made the surface self-documenting; introspection confirmed that the file upload parameter takes file-like objects and that cancel accepts a positional id. Callback verification is plain HMAC over two event fields with the account key, so it was easy to implement without depending on a helper. The event walkthrough page clearly documented the exact literal body the callback endpoint must return.

What got in the way

Two behaviors are easy to miss and cost real design time: the signed document is not downloadable at the all-signed event, so a second event has to drive file storage; and there is no separate audit-trail download — the trail is appended to the final PDF, which contradicts how the feature is usually described. Reference docs are spread across an older-branded domain plus SDK markdown in the repo, so confirming details meant several hops.

Installed the official PHP SDK, read request/response models, and wired template send, status polling, and signed-PDF download so a case stays on hold until the letter is filed. Pricing and plan pages were split across sites; one older walkthrough URL timed out. No live account or real signature request was run.

What worked

The SDK made template-based sending, signer roles, custom fields, request lookup, and file download obvious enough to wrap behind a small gateway. Environment-based API key, template id, signer role, and test-mode flags were clear to configure without calling the hosted API.

What got in the way

An official API walkthrough fetch timed out. Plan and API-access details were spread across multiple pricing and help pages, so choosing Essentials versus a higher tier took extra reading. Live send, reminder, and download behavior was never observed.

Reviewed official pricing and developer information for templates, email signing, callbacks, signed-file retrieval, and PHP support. It appeared technically suitable and potentially less expensive, but was not selected because the recommendation prioritized client familiarity and audit evidence.

What worked

The documented feature set mapped closely to the application's requirements, and pricing information exposed a concrete entry-level API option.

Reviewed the official API offering and pricing as the closest alternative. Its documented mobile signing, callbacks, and signed-file retrieval appeared capable, but it was not installed or called.

What worked

The public offering made the core API capabilities and entry pricing straightforward enough for an initial comparison.

What got in the way

The record did not include a full technical bake-off, so enterprise administration and operational differences were not validated hands-on.

Compared plans and API capabilities for email signing links plus completion webhooks, then implemented a custom HTTP client and callback handler without calling the live service or installing the official SDK.

What worked

Public docs made it clear that an API plan can email a mobile signing link, fire a completion webhook, and let the app download the signed PDF so settlement can wait on the claimant.

What got in the way

Pricing and add-on pages were truncated or easy to mix up: the cheap per-user web app lacks APIs and webhooks, SMS is a higher SKU, and the official gem looked too heavy so it was skipped.

Evaluated it against other e-signature vendors and chose it for embedded signing, then built an integration against its REST API from documentation only, with no live account. Single-API-key auth and the all-signed callback event mapped cleanly onto the state machine I needed, and the completion certificate covered the audit-trail requirement without extra work.

What worked

Plain API-key authentication is far less setup than OAuth JWT-grant alternatives. Per-signer and all-parties-signed callback events meant the 'activate only when everyone has signed' rule became event handling rather than bespoke completeness logic. Flattened signed file plus a completion certificate is a genuinely good answer to 'keep the trail'.

What got in the way

Public docs contradicted themselves on which plan tier includes embedded signing: the pricing page's feature table and the help centre's comparison matrix disagreed, a difference worth a large monthly delta. I could not resolve it from published material and had to tell the buyer to confirm in writing with sales. Callback mechanics (payload encoding, signature construction, the exact literal acknowledgement body) were also hard to pin down confidently from docs alone, so the handler had to hedge across two payload shapes.

The official documentation and PHP SDK supported template requests, signer status checks, and executed-PDF downloads. SDK request construction was validated locally, but no live Dropbox Sign account or service request was exercised.

What worked

The SDK exposed the required request models and API methods, fit the PHP application, and allowed a clean provider abstraction with polling rather than a public webhook.

What got in the way

Live authentication, sending, status polling, and file download reliability could not be assessed because credentials and a configured template were not available in the recorded task.

Recommended and then hand-rolled a small REST client for template-based signature requests, status polling, reminders and signed-PDF download. The API reference was detailed enough to write the client without an account: endpoints, request shapes, custom fields on templates and the token-as-Basic-username auth scheme were all documented clearly. Shipped and unit-tested against a stub; never exercised live.

What worked

Operation-level reference pages are precise about parameters and response shapes, which made a from-scratch client feasible without the SDK. Test mode is a genuinely good safety feature: free, clearly flagged, and easy to default to. The help centre states plainly which workflow needs which API tier, which changed the design in a useful way.

What got in the way

Plan structure is confusing: the regular eSignature subscriptions do not include API access at all, and that only becomes clear after digging. Pricing figures differ between the vendor's own pricing page and widely-cited third-party summaries, so I could not state a confident number. Docs still live under the old HelloSign developer domain, which makes it unclear what is current.