The signature is rarely the point. What matters is what happens next: an account is activated, a purchase order is released, a consent form is filed, a lease start date is locked, a payment is scheduled. In most eSignature integrations, the 'completed' signal triggers that consequential change, and it is often the least engineered step in the whole workflow.
This guide is for backend engineers, integration leads, and solution architects who own that step. It explains why completion handoff fails even on capable teams. It also proposes a vendor-neutral design, the Six-Gate Completion Handoff Ledger, for producing a downstream effect once, or for stopping safely and visibly when that cannot be confirmed. The ledger is a proposed design from the eSignly Expert Team for you to adapt. It is not a certified standard, and it does not assume any specific eSignly endpoint. Confirm event names, authentication, retry behavior, and retrieval calls in the eSignly API documentation, or in your own vendor's documentation.
Here is what you will get:
- A precise view of what a 'completed' event can and cannot prove.
- Three realistic failure patterns, labeled as illustrative composites, and the system gaps behind them.
- A six-gate design with a state model, a comparison of handoff approaches, and illustrative SQL.
- Rules for verified acknowledgment, terminal failure, uncertain input, tenant-safe identity, and privacy ownership.
- A mandatory go/no-go control list and a staged rollout path.
Key Takeaways
- Bottom line: Treat the completion webhook as a hint. Record it durably, confirm the state with the provider, and only then apply a conditional change to your own systems.
- Acknowledge after recording, not after processing. A 2xx response to the provider should mean the event, the operation, and its scheduled work are committed together.
- Bind each operation to a tenant-scoped identity and an immutable payload hash. Reject a reused key with a changed payload. A genuine amendment gets a new identity.
- Unknown is its own state. It means completion could not be confirmed. It is not success and it is not verified failure. Reconcile before you retry any consequential action.
- Identifiers can be sensitive. Build keys from opaque internal IDs, not signer emails or document names, and name an owner for ledger retention.
- Controls are all-required. The go/no-go list in this article is a minimum bar, not a score and not a production certification.
Why the Completion Event Is the Riskiest Moment in an eSignature Integration
Key takeaway: Sending a document is easy to correct. Acting on its completion often is not. The completion signal is a chain of claims, and each link needs its own evidence.
Most integration effort goes into the first half of the workflow: creating the request, placing fields, routing signers. Mistakes there are visible and usually recoverable, because a request can be voided and re-sent. The second half is different. When a completion triggers provisioning, a payment release, or a regulated record update, an error becomes a business event with customers, auditors, and finance attached to it.
Three properties of distributed systems make this moment hard. First, event delivery is typically at-least-once, so duplicates are normal rather than exceptional. The AWS Prescriptive Guidance on the transactional outbox pattern states plainly that the same message might be delivered more than once and recommends making consumers idempotent by tracking processed messages. Second, networks are ambiguous: a timeout does not tell you whether the other side acted. Third, the effects you trigger are consequential, so a wrong guess is expensive.
A practical way to think about it is to separate five different claims that people loosely call 'completed':
| Signal | What it tells you | What it does not tell you |
|---|---|---|
| Webhook delivered | A message arrived claiming a state change | That the sender is authentic, that the event is new, or that it is still current |
| Authoritative fetch shows 'completed' | The provider's recorded state at the time of the fetch | Whether your business preconditions still hold |
| Signed artifact retrieved and hash recorded | You hold the exact bytes you will rely on | Whether signer identity and consent satisfy your legal needs |
| Conditional change succeeded on the target | Target state moved once, under your operation identity | That every dependent system has caught up |
| Read-back from the target confirms the effect | The effect is observable and attributable to the operation | Anything about legal validity of the underlying signature |
One scope note. Whether a given signature is legally effective depends on jurisdiction, document type, signer intent and consent, and your record retention duties. In the United States, 15 U.S.C. 7001 is the starting point for the ESIGN Act's general rule, including its record retention provisions. Your counsel decides what applies to you. A handoff ledger row is an engineering control, not the legal record. The signed document and its audit evidence remain the record, as covered in our guide to long-term defensibility of e-signature data archival and retrieval.
Why This Fails in the Real World
Key takeaway: Capable teams fail here because the webhook handler quietly takes on three jobs at once: receiving, deciding, and acting. Each failure below is a system gap, not a personal one.
The most common approach is the inline handler. A webhook arrives, the code parses it, calls the CRM, provisions the account, updates billing, and returns 200. It works in every demo. It also bundles acknowledgment with processing, which means the provider's timeout, retry policy, and your slowest downstream call all become entangled.
The scenarios below are illustrative composites of common failure modes. They are not reports about specific customers.
Failure pattern 1: the partial apply and the racing retry
The handler activates a customer account, then times out calling the billing service. The provider, seeing no success response, redelivers. The second delivery arrives while the first is still running. Both check whether the account is active, both see 'not yet,' and both proceed. The team had written a guard, but it was read-then-write, which is not an atomic claim. Two workers can pass the same check. Intelligent teams miss this because the guard passes every single-threaded test.
Failure pattern 2: the deduplication key that collapses two tenants
A multi-tenant platform deduplicates on signer email plus template name. Two customers send the same template to the same signer, say a consultant who works with both. The second completion is discarded as a duplicate, and one tenant's activation silently never happens. The same design can also leak personal data into logs and caches, because the key is the personal data. The root cause is that operation identity was never defined as tenant-scoped and built from opaque internal IDs. For deeper isolation patterns, see our guide to multi-tenant e-signature workflows.
Failure pattern 3: the stale agreement that completes late
Sales corrects pricing and sends a replacement document. The original request is voided in the product, but a signer had already opened it, and a late event for the old request reaches the handler. The handler keys on the business object, not on the specific signing request and revision, and activates the account on the old terms. The system had no concept of supersession. The supersession design for voiding, correcting, and re-sending requests covers the request side of this problem. The handoff side needs the matching rule.
Failure pattern 4: unknown input coerced into success
A provider adds a new status value, or an event arrives with a missing field. A permissive parser maps anything not recognized to a default. Teams under delivery pressure choose defaults that keep the pipeline moving, and the pipeline moves in the wrong direction.
The shared root causes
- Acknowledgment was treated as completion of the work.
- No durable, tenant-scoped operation identity existed.
- The event was trusted without an authoritative check.
- Nobody owned the 'unknown' state, so it never got a name.
Illustrative arithmetic: assume 10,000 completions a month and a 1% duplicate delivery rate. Those are assumptions for the sake of the example, not measurements. That is 100 duplicate deliveries a month, each one a chance for a double effect unless something blocks it. Even if only a small fraction hit a race, a consequential action, such as a payment, makes each one worth designing against.
A Proposed Design: The Six-Gate Completion Handoff Ledger
Key takeaway: Put six explicit gates between 'an event arrived' and 'a business system changed.' Each gate records evidence and has a defined failure outcome.
The Six-Gate Completion Handoff Ledger is a proposed design, offered by the eSignly Expert Team as a starting pattern. It combines well-known techniques, including the transactional outbox and inbox idea, idempotent operation identity, lease-based claiming, and reconciliation, in a sequence tailored to eSignature completion. Adapt it to your stack and risk level.
| Gate | Question it answers | Evidence recorded | If it fails |
|---|---|---|---|
| 1. Authenticate and map | Is this event genuine, and which tenant does it belong to? | Verification result, tenant resolved from your own authoritative mapping | Quarantine. Never guess a tenant. |
| 2. Record durably | Is the event, the operation, and its scheduled work committed together? | Inbox row, operation row in READY state | Return a non-2xx so the provider can redeliver. |
| 3. Verify authoritatively | Does the provider's own record confirm completion, and do I hold the signed artifact? | Fetched status, artifact hash, fetch time | Unconfirmed becomes UNKNOWN. Declined, expired, or voided becomes a terminal non-completion state. |
| 4. Bind and claim | Is this the same operation as before, with the same approved payload, and do I exclusively own it? | Operation key, write-once payload hash, lease owner | Hash mismatch becomes CONFLICT. Lost claim means stop. |
| 5. Apply conditionally | Can the target change state only if it is still in the expected prior state? | Rows affected, or target response with operation reference | No effect or ambiguous result leads to reconcile, not blind retry. |
| 6. Confirm and close | Does a read-back show the effect, and is the ledger state final? | Read-back result, terminal state, outbox events | Remain UNKNOWN and alert the owner. |
How the main handoff approaches compare
This table helps validate the decision. It is not a recommendation to over-build every integration.
| Approach | Build effort | Duplicate-effect risk | Unknown-outcome handling | Scale behavior | Hidden failure mode |
|---|---|---|---|---|---|
| A. Inline handler | Lowest | High | None; retries repeat work | Weak; slow work collides with provider timeouts | Overlapping redeliveries run concurrently |
| B. Queue after ack, dedupe on event ID | Medium | Medium | Partial | Good | Ack before durable enqueue loses events; different event IDs for one business action defeat the dedupe |
| C. Six-gate ledger | Highest | Low, if the target supports conditional change | Explicit UNKNOWN state with reconcile | Good; partition work by tenant and object | Operational burden: monitoring, retention, and runbooks must have owners |
The state model that falls out of these gates is small: READY, CLAIMED, APPLIED, UNKNOWN, QUARANTINED, and a few terminal states. The next section shows how the first four gates look in code.
Implementing the Gates: Atomic Recording, Claiming, and Conditional Apply
Key takeaway: Deduplication, recording, and work scheduling must happen in one transaction. A read followed by a write is not a compare-and-swap. The target itself must enforce the condition.
The SQL below is illustrative PostgreSQL-style code. It is not an eSignly API contract, and it assumes you own the database tables involved. The principles are what matter.
-- Illustrative schema. Opaque IDs only, no signer PII. CREATE TABLE event_inbox ( tenant_id uuid NOT NULL, provider_event_id text NOT NULL, received_at timestamptz NOT NULL DEFAULT now(), PRIMARY KEY (tenant_id, provider_event_id) ); CREATE TABLE handoff_operation ( tenant_id uuid NOT NULL, operation_key text NOT NULL, -- derived from internal IDs, see section 6 payload_hash bytea NOT NULL, -- write-once hash of the approved payload state text NOT NULL DEFAULT 'READY', lease_owner text, lease_expires_at timestamptz, attempt_count int NOT NULL DEFAULT 0, PRIMARY KEY (tenant_id, operation_key) ); -- Gate 2: one transaction. Return 2xx only after COMMIT succeeds. BEGIN; INSERT INTO event_inbox (tenant_id, provider_event_id) VALUES (:tenant, :event_id) ON CONFLICT DO NOTHING; INSERT INTO handoff_operation (tenant_id, operation_key, payload_hash) VALUES (:tenant, :op_key, :hash) ON CONFLICT (tenant_id, operation_key) DO NOTHING; COMMIT; -- The READY row is the scheduled work. There is no separate enqueue step to lose. -- Then compare the stored hash with :hash. The hash is never updated, so the -- comparison is safe. On mismatch, write a quarantine record and alert. -- Gate 4: atomic claim. Concurrent workers cannot both win. UPDATE handoff_operation SET state = 'CLAIMED', lease_owner = :worker, lease_expires_at = now() + interval '5 minutes', attempt_count = attempt_count + 1 WHERE (tenant_id, operation_key) = ( SELECT tenant_id, operation_key FROM handoff_operation WHERE state = 'READY' ORDER BY tenant_id, operation_key LIMIT 1 FOR UPDATE SKIP LOCKED) RETURNING tenant_id, operation_key, payload_hash; -- Sweeper: an expired lease means the effect may or may not have happened. UPDATE handoff_operation SET state = 'UNKNOWN' WHERE state = 'CLAIMED' AND lease_expires_at = now() - interval '0 seconds'; -- Use a real expiry comparison in production. Never return an expired lease to READY. -- Gate 5: target-side conditional mutation. UPDATE customer_account SET status = 'ACTIVE', activated_by_operation = :op_key WHERE tenant_id = :tenant AND id = :account_id AND status = 'PENDING_SIGNATURE' AND activated_by_operation IS NULL; -- 1 row: applied. 0 rows: read the row. If activated_by_operation = :op_key, -- an earlier attempt already applied it. Otherwise record CONFLICT for review. -- Gate 6: fenced close. Fails if the lease was lost. UPDATE handoff_operation SET state = 'APPLIED', lease_owner = NULL WHERE tenant_id = :tenant AND operation_key = :op_key AND state = 'CLAIMED' AND lease_owner = :worker;What each choice protects against
- Inbox plus operation row in one transaction. This is the inbox-side counterpart of the transactional outbox pattern, which exists because sending a message separately from a database commit cannot be made reliable without it. If the commit fails, you return a non-2xx and rely on redelivery. Confirm in your provider's documentation how redelivery works rather than assuming it.
- Write-once payload hash. The hash covers the approved, canonicalized data the effect will apply, such as plan, amount, effective date, and the signed artifact's hash. A retry with the same key and the same hash is a retry. The same key with a different hash is a conflict. Stripe's documentation describes the same discipline for its own API: reusing a key with different parameters produces an error. See its idempotent requests reference. This is a cited example of the pattern, not a statement about eSignly's API.
- Claim by atomic update with a lease. The claim succeeds for exactly one worker. The fenced close at the end prevents a slow worker from marking work complete after it lost its lease.
- Expired lease goes to UNKNOWN, not READY. The original worker may have applied the effect just before it died. Re-running blindly is the exact error the design exists to prevent.
- Conditional mutation on the target. The WHERE clause is the compare-and-swap. A separate SELECT followed by an UPDATE is not, because another writer can intervene between the two statements.
When the target is not your database
If the target is a third-party CRM, ERP, or billing API that lacks conditional updates or idempotency support, disclose that limitation in your design review. Mitigations include serializing work per tenant and object through a partitioned queue, passing your opaque operation reference if the target supports it, and always reading target state before any retry. These reduce risk but do not eliminate it, because other writers outside your control can still change the target. Record that residual risk and name who accepted it.
Uncertain, Unknown, and Terminal: Handling Outcomes You Cannot Confirm
Key takeaway: Define three kinds of acknowledgment and a small set of terminal states. Treat 'unknown' as a first-class outcome with an owner, never as a synonym for success or failure.
Verified acknowledgment has three layers
- Transport acknowledgment. Your 2xx tells the provider that you durably recorded the event. It does not claim the business action happened.
- Business acknowledgment. The target confirmed the effect through a conditional change result and a read-back.
- Human acknowledgment. A named person resolved a quarantined, conflicting, or unknown operation and recorded the decision.
Mixing these layers is what lets an operation look done when it is not.
The state model
| State | Meaning | Allowed next | Owner and signal |
|---|---|---|---|
| READY | Recorded, verified inputs pending, unclaimed | CLAIMED | Queue age alert |
| CLAIMED | One worker holds a lease | APPLIED, UNKNOWN, TERMINAL states | Lease expiry sweeper |
| APPLIED | Effect confirmed by read-back | None | Audit record |
| UNKNOWN | Completion or effect could not be confirmed | APPLIED or TERMINAL after reconcile | Integration on-call; age-based escalation |
| QUARANTINED | Input was unrecognized, unmapped, or malformed | READY after human fix, or discarded with reason | Integration owner |
| TERMINAL_NOT_COMPLETED | Provider reports declined, expired, or voided | None; may start a compensating workflow | Business process owner |
| TERMINAL_CONFLICT | Payload hash mismatch or target no longer in expected state | None; human decision | Business and engineering owners |
| TERMINAL_FAILED | Non-retryable rejection by the target | None | Integration owner |
Rules that keep the model honest
- An unknown result means completion could not be confirmed. It is not success and it is not verified failure. Do not display it as either.
- Never blindly retry an ambiguous timeout on a consequential action. Reconcile first by reading authoritative state on the target. Stripe's guidance on advanced error handling takes the same position for its own API: treat a 500 as indeterminate, and retrieve the object and use webhook events to reconcile before starting another operation. Our guide to e-signature API timeouts and unknown outcomes expands on this.
- Uncertain input is quarantined, not interpreted. An unrecognized event type, an unmapped provider account, or a missing required field goes to QUARANTINED with the raw record retained under your retention rules. Do not map unknowns to a default.
- Terminal states need a reason code. A declined or expired signature is a legitimate business outcome. It should drive a defined path, such as notifying the owner, rather than raising a generic error.
- Distinguish legitimate later operations. A corrected or amended agreement produces a new signing request and a new business revision, hence a new operation key. It must not be swallowed as a duplicate of the earlier one, and a late event from a superseded request must not trigger an effect.
For webhook authenticity and integrity checks at Gate 1, see our enterprise architect's guide to e-signature webhook security. If your provider offers no verification mechanism for events, treat every event as an unauthenticated hint and let Gate 3's authoritative fetch carry the trust.
Tenant-Safe Identity, Privacy Ownership, and Trade-Offs
Key takeaway: Every uniqueness rule must include the tenant. Every identifier must be assumed sensitive until proven otherwise. Every table needs a named owner and a retention rule.
Building the operation key
A workable key concatenates opaque internal identifiers: tenant ID, business object ID, action type, signing request ID, and business revision. Then encode or hash it. Include the tenant in every unique index, as in the schema above. If one provider account serves several tenants, map events to tenants through your own authoritative table, never through a field inside the event body that a sender controls.
Avoid signer emails, names, and document titles in keys, logs, and metrics labels. Stripe's documentation advises avoiding sensitive data such as email addresses or personal identifiers as idempotency keys. The advice generalizes: an identifier that can single out a person is personal data in many legal regimes, and the key will propagate into places your data governance does not reach.
Hashes are not automatically safe either. A hash of a low-entropy value, such as an email address, can often be reversed by guessing, so it can still be personal data. If you must derive a reference from such a value, use a keyed hash with a per-tenant secret, and treat the output as sensitive anyway.
What belongs in the ledger
| Keep | Avoid |
|---|---|
| Tenant ID, operation key, state, timestamps, attempt count | Signer names, emails, phone numbers |
| Provider event ID and signing request ID | Full webhook bodies unless retention rules and access controls are defined |
| Payload hash and signed artifact hash | Document content or form field values |
| Reason codes and human resolution notes without personal data | Free-text notes that copy contract terms or personal details |
Privacy ownership
Name an owner for each store: the ledger, the quarantine area, raw event retention, and the signed records. The ledger owner is usually the integration team. The signed record owner is usually the business function that is legally accountable for the agreement. They have different retention clocks. A request to erase personal data may apply to some stores and not others, and your retention duties may require keeping certain records. Which applies to you is a legal determination for your counsel. Design so that the ledger can be minimized or expired without destroying the signed record or the evidence trail.
Trade-offs to accept openly
- Latency. Work happens after acknowledgment, so effects appear seconds or minutes later. Tell product teams.
- Operational surface. The ledger becomes a critical system with dashboards, alerts, and runbooks.
- Cost and complexity. This is real engineering effort. It pays back where effects are consequential, and it is overkill for low-stakes actions, such as posting a chat notification, where a duplicate is harmless.
- When this advice does not apply. If your integration only displays status to a user and takes no business action, an authoritative fetch on demand may be enough.
Go/No-Go Controls, a Staged Rollout, and Where eSignly Fits
Key takeaway: All ten controls must pass before a consequential action goes live. There is no score. A failed control is a no-go until fixed or formally accepted by a named owner.
Mandatory go/no-go controls
These are all-required checks. Passing them is a minimum bar for launch. It is not certification, and it does not replace your own security review, legal review, or failure testing.
| # | Control | Evidence to collect |
|---|---|---|
| 1 | Tenant is resolved from an authoritative mapping, and unmapped events are quarantined | Test with an unmapped provider account |
| 2 | Event authenticity is verified as the provider documents, or events are treated as unauthenticated hints | Test with a tampered event |
| 3 | 2xx is returned only after event, operation, and scheduled work commit together | Kill the process mid-receive and confirm no event is lost or half-recorded |
| 4 | Completion is confirmed by an authoritative fetch before any effect | Test with an event whose fetched state disagrees |
| 5 | Operation key is tenant-scoped and built from non-sensitive IDs; payload hash is write-once; changed-payload reuse is rejected | Test same key with a different payload |
| 6 | Work is claimed atomically across concurrent workers | Run two workers on one operation and confirm one effect |
| 7 | The target uses conditional mutation, or the serialization limit is documented and accepted | Design review record with owner sign-off |
| 8 | Ambiguous timeouts go to UNKNOWN and reconcile first, with no blind retry | Inject a timeout after the target applied the effect |
| 9 | Every terminal state has an owner, an alert, and a runbook | Walk through declined, expired, voided, conflict, and quarantined cases |
| 10 | Ledger minimization, retention, and erasure ownership are named | Written data map with owners |
A lower-risk rollout path
- Shadow mode. Record events and run Gates 1 to 4 with no effects. Compare what the ledger would have done against what happens today.
- One low-blast-radius action. Choose an action that is easy to compensate, and turn on Gates 5 and 6 for it.
- Failure injection. Duplicate deliveries, delayed events, lease expiry, target timeouts, and tenant mix-ups. Our failure injection plan for backend teams lists scenarios to adapt.
- Daily reconcile report. Count UNKNOWN, QUARANTINED, and CONFLICT by age. Treat a growing backlog as an incident signal.
- Expand by blast radius. Add consequential actions one at a time, each with its own go/no-go review.
For the receiving side of webhook failure recovery, including dead-letter replay, see e-signature webhook failure handling. This article focuses on what happens once an event is accepted and a business effect is at stake.
Where eSignly fits, and how to verify it
eSignly is an eSignature SaaS and API provider, with API and on-premises deployment options described on its API page. Its security page and compliance page are the primary sources for its certification and compliance statements. These are vendor statements. Request current attestation documents through procurement, check their scope against the services you will use, and remember that a vendor's certifications support your compliance program without making your integration compliant. Your obligations depend on your industry, jurisdiction, and use case. The design in this article is vendor-neutral, so check each gate against the documented eSignly behavior for events, authentication, retries, and status retrieval before you rely on it. The pricing page lists a free API plan if you want to test these gates against a sandbox-sized workload.
2026 Update
As of this writing in 2026, one concrete illustration of why your ledger must outlive provider-side protection is Stripe's published difference between API versions. Its v1 idempotency keys are retained for at least 24 hours, while its v2 API describes a 30-day replay window and retries failed work toward completion. Provider windows differ, change over time, and eventually expire. The durable principle is that your own tenant-scoped operation record, not a provider's retention window, should be the long-term source of truth for whether an effect happened. That statement stays true regardless of which vendor or API version you use.
Conclusion: Five Actions Before You Let a Signature Trigger Anything
A completed signature should start a controlled process, not fire a reflex. Use these steps to move from reading to doing:
- Inventory your completion triggers. List every downstream effect a completed signature causes today, and classify each as harmless, correctable, or consequential.
- Split acknowledgment from processing. Change the receiver so a 2xx means durably recorded, with the event, operation, and scheduled work committed in one transaction.
- Define operation identity. Write down the tenant-scoped key, the payload you will hash, and the rule that separates a retry from a legitimate later operation.
- Add an UNKNOWN state with an owner. Route ambiguous timeouts and expired leases there, and require reconciliation before any retry on consequential actions.
- Run the ten go/no-go controls and the failure injection tests. Launch only when every control passes or a named owner has formally accepted a documented limitation.
About eSignly and this review
eSignly has provided online eSignature SaaS and API services since 2014. Per its own security and compliance pages, it states ISO 27001 and SOC 2 Type II certification and describes support for HIPAA, GDPR, 21 CFR Part 11, and PCI DSS requirements. Scope and applicability to your use case should be validated against those pages and the underlying documentation. This article was reviewed by the eSignly Expert Team. It is general technical guidance, not legal advice.
Frequently Asked Questions
Can I trigger business actions directly from the 'completed' webhook alone?
It is risky for consequential actions. Treat the webhook as a hint that a state change may have occurred. Record it durably, verify authenticity as your provider documents, and fetch the authoritative status before acting. That adds one call but removes dependence on a message that may be duplicated, delayed, or stale.
Does returning a 2xx response mean the event was processed?
It should not. A 2xx should mean the event, the operation record, and its scheduled work were committed together. Processing happens afterward and is tracked through states such as CLAIMED, APPLIED, and UNKNOWN. Confirm in your provider's documentation how it treats non-2xx responses and retries.
How do I handle duplicate completion events?
- Deduplicate on the provider event ID, scoped by tenant, at receipt.
- Deduplicate again on the operation key, because different event IDs can describe the same business action.
- Make the target change conditional so a duplicate that slips through cannot apply twice.
What should I do when the downstream system times out?
Do not blindly retry a consequential action. Mark the operation UNKNOWN, read the authoritative state on the target, and then decide: confirm the effect as applied, or retry with the same operation identity if the target shows it did not happen. If you cannot establish what happened, escalate to a human owner.
How should idempotency keys work in a multi-tenant system?
Scope every uniqueness constraint by tenant, and build keys from opaque internal IDs such as tenant, business object, action, signing request, and revision. Avoid signer emails and document names. Bind each key to a write-once hash of the approved payload, and reject reuse with a different payload.
Do I need to store the signed document in my own system?
It depends on your retention obligations, your records policy, and your contract with the provider. Many teams retrieve the signed artifact and its evidence record and store a hash for integrity checks. Your counsel should confirm what applies in your jurisdiction and industry. See also the ESIGN Act text at 15 U.S.C. 7001 for the United States baseline.
Is this design too heavy for simple integrations?
Possibly. If the downstream effect is harmless to repeat, such as a notification, an inline handler with basic deduplication may be enough. Use the full ledger when a mistaken or duplicated effect would affect money, access, regulated records, or customer commitments.
Does the design depend on specific eSignly endpoints?
No. It is vendor-neutral and intentionally avoids assuming particular endpoint names or event schemas. Check the current documentation on the eSignly API page for the events, authentication, and retrieval calls available, and map each gate to them.
Is your 'completed' handler acting on a hint or on evidence?
Test the six gates against a real signing workflow before a duplicate, a late event, or a timeout tests them for you.
Start with eSignly's API plans and build your completion handoff on a sandbox-sized workload.
Free TrialResource Esignature Api Guide
This article is most relevant for CTOs and developers who need to roll out a practical signing workflow. Use the related eSignly path to compare plans, API options, compliance fit, and implementation next steps.
Reviewed for electronic signature decision makers
This guide is reviewed for clarity, legal and operational relevance, service alignment, and practical conversion path before being connected to an eSignly plan or API workflow.
For regulated, high-volume, or customer-facing workflows, validate legal duties, plan assumptions, and integration requirements with your internal stakeholders before rollout.
