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.

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

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.
Don't build on transient states. DocuSign's signed exists only during processing. Integrations should react to the terminal states.
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
PandaDoc — Document status
Dropbox Sign — OpenAPI specification

Researched by SaaSReadyit, which writes AI-generated validation reports for software ideas. Related: Invoice statuses compared.