Flowgrammer

Dropbox Sign E-Signature Automation

Verify Dropbox Sign callbacks with the exact Hello API Event Received ack, event_hash HMAC-SHA256, and downloadable timing.

— Craig Major

You can acknowledge a Dropbox Sign callback with HTTP 200 and the exact body Hello API Event Received, verify event_hash as HMAC-SHA256 over event_time plus event_type, then queue the rest. The published E-Signature Automation guide owns the shared Signing Control Plane. This page is the Dropbox Sign adapter: signature_request_id, account or app callbacks, multipart json, and downloadable timing. The Dropbox Sign Callback Verification Pack gives you fiction fixtures for those checks.

Start from the Signing Workflow Requirements Workbook if you still need the shared field list. If you already run DocuSign Connect, keep the published DocuSign E-Signature Automation page for that HMAC. The algorithms are not interchangeable. If the missing job is a named approve, reject, or request-changes decision on a Dropbox file, use the published Dropbox document approval workflow. A completed signature request is not that decision.

Who this is for

Use this when documents already go out through Dropbox Sign and the missing piece is a verified callback listener. You need a named sender, one document family, and a place to keep SignatureEvidence. Confirm an HTTPS callback URL and an API key before you promise a listener to a team.

You do not need this page if you are still choosing a first workflow. Start with Document Processing Automation. You also do not need it if Dropbox holds an internal approval file. That job stays on the published Dropbox approval page.

The download includes:

  • HMAC-SHA256 hex vectors for event_hash
  • Exact ack-string tests for Hello API Event Received
  • Multipart json parse failures
  • Account versus app callback scope
  • signature_request_all_signed versus signature_request_downloadable
  • Fast ACK with queued work
  • SX01 through SX12 plus SX-DBX-01 through SX-DBX-06
  • A forbidden-downstream sheet

Canadian Keyword Planner reports brand search for Dropbox Sign as navigational. It does not prove workflow demand. Automation phrases for Dropbox Sign workflow, document, contract, approval, generation, and template sit outside reported volume. This page survives on callback depth, not invented demand. Dropbox Sign alternatives is 10-100 and stays in a later FAQ. HelloSign is a FAQ alias, not a second title.

What this adapter owns

The hub already defined send, remind, void, decline, complete, and download. It already named SignatureEvidence. It already blocked payment, bank-detail change, final accounting, auto-renew, and auto-terminate.

This page adds the Dropbox Sign surfaces:

  • signature_request_id as signature_request_id
  • A composite event identity from event_time, event_type, and signature_request_id
  • HMAC-SHA256 event_hash over event_time plus event_type
  • HTTP 200 plus exact ack text
  • multipart/form-data field json
  • Account callbacks versus app callbacks
  • signature_request_downloadable as artifact_ready

Do not clone the hub and swap the product name. Do not reuse the DocuSign raw-body Base64 check. If a field is shared, keep the hub name. If a field is Dropbox Sign-only, say so.

Callback acknowledgement

Official Events Walkthrough guidance, accessed 9 September 2026, is specific:

  1. Dropbox Sign POSTs the event to your HTTPS callback URL.
  2. Your listener returns HTTP 200.
  3. The response body must contain the exact string Hello API Event Received.
  4. If that check fails, Dropbox Sign treats the delivery as a failed callback and sends it again later.

An empty 200 is not enough. A JSON {"ok":true} is not enough. A typo is not enough. The Node sample on the Walkthrough page sets text/plain and sends that string. Match the string first. Confirm content-type in your tenant if your stack is picky.

Official Failures and Retries, accessed the same day: up to six retries with increasing delays of about 5 minutes, 15 minutes, 45 minutes, 2 hours 15 minutes, 6 hours 45 minutes, and 20 hours 15 minutes. The table is an approximation. Requests time out after 30 seconds. After ten consecutive failures the callback URL is cleared and you have to set it again.

ACK is not the SignatureEvidence write. Return the string quickly. Queue verification, storage, and download.

You can fire a test event from the callback URL field in the Dropbox Sign web UI. That proves the server answers. It does not prove your production hash check.

event_hash

Every event payload includes event.event_hash. Official Walkthrough and MIT EventCallbackHelper code, accessed 9 September 2026, compute it this way:

  1. Read event.event_time and event.event_type.
  2. Concatenate those two strings with no separator.
  3. Compute HMAC-SHA256 using your API key as the secret.
  4. Hex-encode the digest.
  5. Compare it to event.event_hash with a constant-time compare.

That is not a DocuSign Connect check. DocuSign HMAC covers the exact raw POST body and then Base64-encodes the digest against X-Docusign-Signature-N. If you bring that habit here, verification fails.

Wrong key fails. Swapping time and type fails. Inserting a + or a colon fails. Hashing the whole JSON body fails.

The API key is the HMAC secret. It is shown in the API settings page. Do not put a production key in this test pack. Fiction vectors use FICTION-CQ-SIGN-API-KEY.

User-Agent Dropbox Sign API is a supporting signal. It is not enough by itself.

Multipart json

Default callback POSTs are multipart/form-data. The event lives in a field named json. Official SDKs parse that field, then run EventCallbackHelper. If your framework treats the request as raw JSON, you will hash the wrong bytes or miss the event.

The test pack stores the json field as LF text and derives a multipart wrapper in memory. Real HTTP multipart uses CRLF. Parse the field your stack actually receives.

SX-DBX-05 records missing_json_field when that field is absent or not JSON. Do not write SignatureEvidence from a guess.

Account callbacks and app callbacks

Account callbacks notify one URL when an event involves your account. App callbacks notify the URL on a specific API app when the request includes that app's client_id. One account can have more than one app.

Event metadata may include reported_for_app_id. Official helpers treat an empty value as account_callback and a set value as app_callback. Design for both. The same signature request can be visible in more than one listener if you configure both scopes. Idempotency still applies. downstream_write_count stays 0 or 1.

HTTPS is required. Official Walkthrough warning, accessed 9 September 2026: non-HTTPS callback URLs stopped receiving events on 1 December 2024.

all_signed is not downloadable

Official Events Overview, accessed 9 September 2026, keeps these names separate:

  • signature_request_signed means one signer finished required fields
  • signature_request_all_signed means all required signers finished
  • signature_request_downloadable means an updated signed PDF is available

If you plan to call /signature_request/files, wait for downloadable. Filing the final PDF on all_signed is how teams store an incomplete file.

SX07 keeps status waiting_for_downloadable. SX-DBX-04 walks all_signed, then downloadable, then one file write.

Content-Sha256 and other filters

The Walkthrough documents a Content-Sha256 header: Base64 HMAC-SHA256 of the request JSON payload using the API key. Treat it as defense in depth. It is not a substitute for event_hash. This draft does not claim the header is present on every delivery. Confirm what your listener actually receives.

The same page mentions a downloadable IP list. Do not invent that list here. Refresh it from the current official file if you use network allowlisting.

Embedded signing, OAuth app approval, SMS, eID, and premium branding can be plan-gated or admin-gated. Cite the category. Confirm the screens you see. No seat prices appear here.

API rate limits exist. Do not invent a numeric quota.

Forbidden downstream

These writes stay blocked after a verified downloadable complete:

  • payment
  • supplier bank-detail change
  • final accounting post
  • auto-renew
  • auto-terminate
  • legal interpretation as an automation outcome
  • claiming jurisdiction-wide legal validity

Allowed after verified event_hash, downloadable status, artifact_ready, and a named human gate: notify, and file the completed artifacts once. If money is the real job, use invoice processing automation. If renewal is the real job, use the contract tracker. If the file still needs extraction, use intelligent document processing. If the org still needs a named decision on a Dropbox file, use Dropbox document approval workflow or the parent Document Approval Workflow.

Worked example

Fictional Cedar & Quay Fabrication Ltd sends supplier agreement DOC-CQ-SIGN-014 version 1.0. Jordan Hale is the named sender. Morgan Reid signs as Supplier_Signer. Avery Chen holds the human gate for any post-sign notify or file action.

Jordan captures signature request id sr:FICTION-CQ-SIGN-014, template tmpl:cq-sign-014 version v1.0, and a document bind before send. The listener stores UTC receive time, returns Hello API Event Received, and verifies event_hash before it treats the event as real.

A verified downloadable event writes one SignatureEvidence row. artifact_ready is yes. downstream_action is notify. downstream_write_count is 1. Nothing pays a supplier and nothing renews the agreement.

The paired pack walks that request through SX01–SX12 and the six Dropbox Sign extras. Samples stay fictional. There is no live tenant in the pack.

The Dropbox Sign workflow

  1. Name the document family, sender, signer roles, and routing policy.
  2. Confirm the HTTPS callback URL, account or app scope, and API key in the tenant.
  3. If an org decision is required before send, open the Document Approval Workflow or the Dropbox document approval workflow.
  4. Capture template id, template version, and document bind. Refuse send on a stale version.
  5. Send. Record signature_request_id.
  6. ACK the callback quickly with Hello API Event Received. Queue verification, storage, and download.
  7. Parse the multipart json field. Verify event_hash on event_time plus event_type.
  8. Ignore a replayed event identity.
  9. Wait for signature_request_downloadable before filing the final PDF.
  10. After verified complete plus artifact_ready, a named person may notify or file once.

What can run automatically, and what cannot

Event Automatic Review Human only
ACK Hello API Event Received Yes, quickly Slow handlers Treating ACK as a completed write
Verify event_hash Yes, constant-time compare Failed or missing hash Turning a failed check into a complete
Parse multipart json Yes Missing field Hashing a raw body like DocuSign
Classify account vs app scope Yes, from reported_for_app_id Dual-scope overlap Second downstream write
Ignore a duplicate event id Yes First-write dispute Second file write
Queue document download Yes, after ACK Missing artifact Filing the PDF on all_signed
Post-sign notify or file After verified downloadable plus named gate Destination path Payment, bank change, accounting, renew, terminate
Org approval before send Open the approval path Vendor signing labels Treating Dropbox Sign as DecisionEvidence

Human decisions

A named sender confirms the bound document and template version before send. A named person confirms the HTTPS callback URL, scope, and API key before those surfaces are promised. A named person reviews failed event_hash, missing json, wrong ack, unauthorized sender, stale template, decline, cancel, expiry, and a missing downloadable file. A named person decides any post-sign notify or file. Automation may ACK and queue. It may not invent legal validity or org approval.

Failure paths

  • Missing signature_request_id or event identity. Stay in sent. Write count 0.
  • Missing or incorrect event_hash. event_hash_invalid. Alert. Write count 0.
  • HMAC computed on the raw body, as Base64, or with a separator. Reject.
  • Missing multipart json field. missing_json_field.
  • Empty 200, JSON ack, or typo. ack_failed. Risk retries, then a cleared URL.
  • Listener work that is not queued. Risk missing the documented 30-second window.
  • Duplicate event identity. Keep the first downstream_ref.
  • Decline stored as a signed PDF. Status declined.
  • Cancel after a partial sign treated as complete. Status voided.
  • Event cites template v0.9 after send on v1.0. stale_template_version.
  • signature_request_all_signed treated as file-ready. waiting_for_downloadable.
  • Sender not in the named matrix. unauthorized_sender.
  • Listener tries to pay or change bank details. Policy block.
  • Listener tries to auto-renew or auto-terminate. Policy block.
  • Dropbox Sign completion treated as Dropbox Document Approval. Open the approval wall instead.

Test cases

The pack uses fictional Cedar & Quay request ids. Expected control outcomes:

Case Input Wrong outcome Expected control
SX01 verified complete event_hash pass, downloadable Payment or renew write One row; notify; write count 1
SX02 duplicate event Same identity replayed Second file write Ignore; write count 1
SX03 failed verification Bad event_hash Event log write Alert; write count 0
SX04 decline Signer declines Signed PDF filed Status declined
SX05 cancel after partial Sender cancels Silent complete Status voided
SX06 stale template Version v0.9 after v1.0 bind Send proceeds Exception or send blocked
SX07 all_signed only Complete event, artifact_ready no Final PDF filed Wait
SX08 unauthorized sender Riley sends Event log write Exception
SX09 auto-pay Complete tries to pay Payment write Blocked
SX10 auto-renew Complete tries to renew Contract update Blocked
SX11 approval before send Org decision still open Sign treated as SoR Link Dropbox approval
SX12 routing mismatch Policy sequential, observed parallel Surprise routing Exception
SX-DBX-01 Empty or JSON ack Treated as live ack_failed
SX-DBX-02 reported_for_app_id set Account scope assumed app_callback
SX-DBX-03 Swapped time and type Verify anyway event_hash_invalid
SX-DBX-04 all_signed then downloadable File on all_signed Wait, then file
SX-DBX-05 Missing multipart json Parse raw body missing_json_field
SX-DBX-06 Content-Sha256 mismatch Ignore header Defense-in-depth alert

What to measure

Record requests sent, share of callbacks verified before write, duplicate events suppressed, ACK times over the documented window, declines and cancels that did not file a signed PDF, waits for downloadable artifacts, missing-json count, and completes that have a notify or file ref. Keep those as definitions. Do not invent a benchmark, accuracy rate, or ROI figure.

There is no live production callback metric here, and no Flowgrammer customer signing case.

How to use the test pack

Download the Dropbox Sign Callback Verification Pack. It is an original fixture pack, not a Marketplace listing and not a hosted listener.

  1. Read README.md, then markdown/setup.md.
  2. Walk csv/event-hash-vectors.csv and csv/ack-string-tests.csv.
  3. Confirm HV01 passes and HV04 fails when time and type are swapped.
  4. Confirm ACK01 contains Hello API Event Received and ACK03 fails.
  5. Confirm SX07 waits and SX-DBX-04 files only after downloadable.
  6. Walk SX01 through SX12, then the six Dropbox Sign extras.
  7. Keep markdown/forbidden-downstream.md next to any post-sign handoff.

The useful rules also sit on this page so the download is not the only answer.

Realistic limitations

  • This page designs Dropbox Sign signing control. It does not certify legal validity in any jurisdiction.
  • Callback URL, API key, Embedded or OAuth app approval, SMS, and eID can be plan-gated or admin-gated. Confirm the current official tables in your tenant.
  • The official glossary mentions a shorter timeout than the Walkthrough. This page uses the Walkthrough 30-second figure. Recheck both pages at publish time.
  • Retry delays are approximate.
  • Content-Sha256 presence and the current IP allowlist are not published as complete inventories here.
  • JSON field names can vary by API version. Map the event identity you actually receive.
  • This system does not approve a Dropbox file for the organization, extract fields, pay anyone, or change supplier bank details.
  • This guide does not rank vendors and is not a pricing page.
  • The published Adobe Acrobat Sign Automation and PandaDoc E-Signature Automation adapters are live.
  • This page is operational guidance, not legal advice and not a compliance certification.

Next step

Download the Dropbox Sign Callback Verification Pack for event_hash vectors, ack-string tests, and the eighteen cases.

Keep the published E-Signature Automation hub nearby for the shared model. Keep the Dropbox Approval Folder / Decision Log Template nearby when an org decision is required on a Dropbox file.

If callback enablement, API keys, or the event log are still unclear, start with an AI Success Audit. If those pieces are already named, book a fit call to scope an AI Automation Systems build.

Sources

Frequently asked questions

What is Dropbox Sign workflow automation on this page?

It is a named send, exact callback ack, `event_hash` check, ACK-then-queue path, downloadable timing, and a SignatureEvidence write after a verified event. It is not a generic document-processing pillar.

Is a Dropbox Sign completion the same as Dropbox document approval?

No. This page covers the eSignature callback adapter. Recipient signing and vendor-hosted actions may implement a vendor gate. The live [Dropbox document approval workflow](/insights/dropbox-document-approval-workflow) owns file SoR and DecisionEvidence. Those surfaces do not automatically become Flowgrammer Document Approval DecisionEvidence. Use the published [Document Approval Workflow](/insights/document-approval-workflow) when the org needs a named approve, reject, or request-changes decision.

Is HelloSign a different product?

No. HelloSign is the legacy name. Official developer docs still live on developers.hellosign.com. This page does not create a separate HelloSign H1.

How do you validate event_hash?

Use the API key, concatenate `event_time` and `event_type` with no separator, compute HMAC-SHA256, and compare the hex digest. Do not hash the raw body. Do not Base64-encode the digest the way DocuSign Connect does.

Why can a DocuSign HMAC helper fail here?

DocuSign Connect HMAC covers the exact raw POST body and then Base64. Dropbox Sign `event_hash` covers two event fields and then hex. Keep the published [DocuSign E-Signature Automation](/insights/docusign-e-signature-automation) page for that adapter.

Why is the payload in a multipart json field?

Official Walkthrough guidance says default POSTs are `multipart/form-data` with event details in `json`. Parse that field before you read `event_type`.

How fast should the listener ACK?

Official Walkthrough guidance says requests time out after 30 seconds. Return `Hello API Event Received` quickly and queue the rest. ACK is not a completed SignatureEvidence write.

Does envelope completion renew a contract or pay a supplier?

No. Those writes stay blocked. Use the [contract tracker](/insights/contract-tracker) or [invoice processing automation](/insights/invoice-processing-automation).

Do brand search volumes prove automation demand?

No. Brand Dropbox Sign volume is navigational. Automation phrases used here have no reported Planner volume. `Dropbox Sign alternatives` is 10-100 and is not this H1.