--- title: "E-Signature Statuses Compared: DocuSign vs PandaDoc vs Dropbox Sign" short_title: "E-Signature Statuses: DocuSign vs PandaDoc vs Dropbox Sign" description: "DocuSign has 11 envelope statuses, PandaDoc 14 document statuses, and Dropbox Sign none at all — just three booleans. What each means, including DocuSign's misleading 'delivered'." date: 2026-09-24 products: DocuSign=https://www.docusign.com; PandaDoc=https://www.pandadoc.com; Dropbox Sign=https://sign.dropbox.com faq: What are the DocuSign envelope statuses?=completed, correct, created, declined, deleted, delivered, sent, signed, template, timedout and voided. deleted and timedout are legacy statuses that are no longer used. || What does delivered mean in DocuSign?=All recipients have viewed the documents in the envelope through the DocuSign signing website. It does not mean the email was delivered. || What are PandaDoc document statuses?=document.uploaded, document.error, document.draft, document.sent, document.viewed, document.waiting_approval, document.rejected, document.approved, document.waiting_pay, document.paid, document.completed, document.voided, document.declined and document.external_review. || Does Dropbox Sign have a signature request status?=No single status field. A signature request has three booleans — is_complete, is_declined and has_error — and each signer has a status_code such as awaiting_signature, signed or declined. --- # E-Signature Statuses Compared: DocuSign vs PandaDoc vs Dropbox Sign

Researched and verified against each product's API documentation on 2026-09-24.

:::tldr **Short answer:** DocuSign envelopes have eleven statuses (two of them legacy). PandaDoc documents have fourteen, because PandaDoc also handles approvals and payments. Dropbox Sign has **no status field** on a signature request — just three true/false flags — and puts the status on each signer instead. And DocuSign's `delivered` doesn't mean what it sounds like. ::: ## The statuses side by side | Stage | DocuSign (envelope) | PandaDoc (document) | Dropbox Sign | |---|---|---|---| | Being prepared | `created` | `document.uploaded` → `document.draft` | — | | Internal approval | — | `document.waiting_approval` / `approved` / `rejected` | — | | Sent | `sent` | `document.sent` | signer: `awaiting_signature` | | Opened | `delivered` (all recipients) | `document.viewed` | signer: `last_viewed_at` | | Everyone signed | `signed` (briefly) → `completed` | `document.completed` | `is_complete: true` | | Payment | — | `document.waiting_pay` / `document.paid` | — | | Declined | `declined` | `document.declined` | `is_declined: true` | | Cancelled or expired | `voided` | `document.voided` | — (`expires_at`) | | Sender editing after send | `correct` | — | — | ## DocuSign: read the definitions carefully DocuSign's status table has eleven entries. Three of them don't mean what their names suggest. **`delivered` is about viewing, not email.** It means "All recipients have viewed the document(s) in an envelope through the Docusign signing website. This does not indicate an email delivery of the documents in an envelope." **`sent` lasts until everyone has looked.** "An email notification with a link to the envelope has been sent to at least one recipient. The envelope remains in this state until all recipients have viewed it at a minimum." **`signed` is almost never what you'll see.** "The envelope has been signed by all the recipients. This is a temporary state during processing, after which the envelope is automatically moved to completed status." If your integration waits for `signed`, it may miss it; wait for `completed`. The rest: `created` ("in a draft state and has not been sent for signing"), `completed`, `declined` ("declined for signing by one of the recipients"), `voided` ("voided by the sender or has expired. The void reason indicates whether the envelope was manually voided or expired"), `correct` ("opened by the sender for correction. The signing process is stopped"), and `template`. Two — `deleted` and `timedout` — are described as "a legacy status and is no longer used." Note that expiry isn't its own status in DocuSign: an expired envelope is `voided`, and you tell the two apart by the void reason. ## PandaDoc: a document that can be approved and paid PandaDoc's fourteen statuses cover more ground because its documents do more than collect signatures. Two are about creation: `document.uploaded` ("in processing and will be in document.draft state soon") and `document.error`, where "The document creation has failed. This status is terminal, you should stop polling after getting it." Three are an internal **approval** workflow: `document.waiting_approval`, `document.approved` and `document.rejected`, each defined for documents with "an automatic approval workflow." Two are **payment**: `document.waiting_pay` ("has a Stripe payment option and is awaiting payment") and `document.paid`. The signing path itself is `draft` → `sent` → `viewed` → `completed`. `document.sent` is the lock-in point: "The document has been "sealed" and optionally sent. No further document edits can occur except for document recipient(s) filling out or signing the document." Two PandaDoc definitions differ from DocuSign's. `document.voided` means "The document expired and is no longer available for completion or signature." And `document.declined` means "The document was manually marked as "Declined"." ## Dropbox Sign: flags, not a status Dropbox Sign's API has no status field on a signature request. It has three booleans: - `is_complete` — "Whether or not the SignatureRequest has been fully executed by all signers." - `is_declined` — "Whether or not the SignatureRequest has been declined by a signer." - `has_error` — "Whether or not an error occurred (either during the creation of the SignatureRequest or during one of the signings)." The status lives on each **signer** instead: `status_code` is "The current status of the signature. eg: awaiting_signature, signed, declined," alongside `signed_at`, `last_viewed_at` and a `decline_reason`. That model is honest about what a multi-signer request is: several independent people, each at their own stage. The cost is that "where is this request?" has to be worked out from flags and per-signer states rather than read from a single field. ## What to take from this 1. **Name statuses for what they measure.** DocuSign's `delivered` is a well-known source of confusion. If your status means "viewed", call it viewed — as PandaDoc does. 2. **Don't build on transient states.** DocuSign's `signed` exists only during processing. Integrations should react to the terminal states. 3. **Multi-party documents need per-party status.** Dropbox Sign puts it on each signer, DocuSign has separate recipient statuses, and PandaDoc tracks the document as a whole. If your product involves several signers or approvers, decide early which one you're tracking. ## Method and limits DocuSign's statuses are from its eSignature REST API "Envelope status codes" page; PandaDoc's from its API reference on document status; Dropbox Sign's from its official OpenAPI specification on GitHub (`hellosign/hellosign-openapi`). All read on 2026-09-24. DocuSign also has separate recipient status codes, which we didn't cover here. We have no affiliation with any of the three. ## Sources - DocuSign — [Envelope status codes](https://developers.docusign.com/docs/esign-rest-api/esign101/concepts/envelopes/status-codes/) - PandaDoc — [Document status](https://developers.pandadoc.com/reference/document-status) - Dropbox Sign — [OpenAPI specification](https://github.com/hellosign/hellosign-openapi/blob/main/openapi.yaml) --- *Researched by [SaaSReadyit](https://saasreadyit.com), which writes AI-generated validation reports for software ideas. Related: [Invoice statuses compared](https://saasreadyit.com/blog/invoice-statuses-stripe-xero-quickbooks.html).*