- Signer - Reviews and signs documents
- Approver - Reviews and approves documents without signing
- Preparer - Fills in information on behalf of another party
Attributes
Show Signer
Show Signer
The unique identifier of the recipient.
The unique identifier of the envelope.
Specifies the type of recipient. Available options are
signer, preparer, and approver.For signers, the type is signer.A unique identifier you assign to each recipient in the envelope.It’s used to match recipients with the places they should interact with (like signature fields) and to identify them in events and webhook notifications.It must be unique within the envelope, contain up to 32 lowercase letters, numbers, and underscores, and start with a letter.
The name of the recipient.
The email address of the recipient.
The current status of a recipient.Available options are
pending, awaiting, sent, completed, rejected, soft_bounced, hard_bounced, failed, and replaced.The current ceremony for the recipient.
Show Ceremony
Show Ceremony
Show Email Link Authentication
Show Email Link Authentication
With link via email authentication, the recipient receives an email with a link to initiate the ceremony, sent by SignatureAPI.
Specifies the type of authentication. The available options are
email_link, email_code, and custom.For link via email authentication, this type is email_link.Show Email Code Authentication
Show Email Code Authentication
With email code authentication, the recipient receives an email from SignatureAPI containing a code. The recipient must enter this code to authenticate during the ceremony.
Specifies the type of authentication. The available options are
email_link, email_code, and custom.For email code authentication, this type is email_code.Show Custom Authentication
Show Custom Authentication
With custom authentication, your application receives a URL to share with the recipient. You can send this URL via email or embed it in a web or mobile application, enabling the recipient to initiate the ceremony.
Specifies the type of authentication. The available options are
email_link, email_code, and custom.For custom authentication, this type is custom.The name of the authentication provider, such as your company or application. This value will appear in the envelope’s audit logs.
A set of key-value pairs with metadata about the authentication, such as timestamps, session IDs, and correlation IDs. These values will be included in the audit log.
The values provided in
data must be sufficient for verifying the recipient’s authentication. For instance, an expert witness in a legal proceeding should be able to correlate these values with the authentication details in your system.When using custom authentication, you must retain all records necessary to prove the recipient’s authentication, such as session information. Please review our Terms & Conditions for more details.An HTTPS URL to redirect the recipient to after a ceremony is finished.Learn more in Redirect URL.
The type of ceremony URL returned for sharing flexibility.Available options are
short and standard. The default is standard.Use short when you need to share the URL in space-constrained channels such as SMS or push notifications.List of sources allowed to embed this ceremony (for web embedding).These sources will be used in the frame-ancestor directive of the ceremony’s HTTP Content Security Policy (CSP).Sources usually take the form of a scheme and host, like
https://app.example.com, but can also use wildcards, like https://*.example.com. For all available options, refer to the frame‑ancestors documentation.Defaults to an empty list ([]), meaning the ceremony cannot be embedded unless you explicitly allow at least one origin. To allow embedding in all origins (not recommended for production), use ["*"].To ensure compatibility, only the origin (scheme and host) is considered; paths are ignored.
The URL where recipients can access and complete the signing ceremony. This can be embedded in a web or mobile app, or shared by other means.This property will be
null in the following cases:- The recipient is expected to access the ceremony via an internal delivery method (for example, authentication via
email_link). - The ceremony is not currently active (for example, it has been completed, revoked, or declined).
How the deliverable (signed document) is delivered to the recipient.Available options are
email and none. The default is email.When setting
delivery_type to none, signed documents will not be automatically delivered to the recipient. You are responsible for distributing the signed documents through your own means and for complying with any applicable legal or contractual obligations regarding document delivery.An array that defines which signature types a recipient can use, with the first item shown as the default option during signing.Available values for the array items are
typed and drawn. The default value for this property is ["typed", "drawn"].Time at which the recipient completed (e.g., signed) the envelope, in format. This value can be
null if the recipient has not yet completed.Time at which the status was last updated, in format.
Show Deprecated Fields
Show Deprecated Fields
How the ceremony is created for the recipient.Available options are
automatic and manual. The default is automatic.This property is soft-deprecated but will continue to be supported for backwards compatibility. The recommended way to control ceremony creation is to use the
recipient.ceremony object when creating an envelope.Show Preparer
Show Preparer
The unique identifier of the recipient.
The unique identifier of the envelope.
Specifies the type of recipient. Available options are
signer, preparer, and approver.For preparers, the type is preparer.A unique identifier you assign to each recipient in the envelope.It’s used to match recipients with the places they should interact with (like signature fields) and to identify them in events and webhook notifications.It must be unique within the envelope, contain up to 32 lowercase letters, numbers, and underscores, and start with a letter.
The name of the recipient.
The email address of the recipient.
The current status of a recipient.Available options are
pending, awaiting, sent, completed, rejected, soft_bounced, hard_bounced, failed, and replaced.The current ceremony for the recipient.
Show Ceremony
Show Ceremony
Show Email Link Authentication
Show Email Link Authentication
With link via email authentication, the recipient receives an email with a link to initiate the ceremony, sent by SignatureAPI.
Specifies the type of authentication. The available options are
email_link, email_code, and custom.For link via email authentication, this type is email_link.Show Email Code Authentication
Show Email Code Authentication
With email code authentication, the recipient receives an email from SignatureAPI containing a code. The recipient must enter this code to authenticate during the ceremony.
Specifies the type of authentication. The available options are
email_link, email_code, and custom.For email code authentication, this type is email_code.Show Custom Authentication
Show Custom Authentication
With custom authentication, your application receives a URL to share with the recipient. You can send this URL via email or embed it in a web or mobile application, enabling the recipient to initiate the ceremony.
Specifies the type of authentication. The available options are
email_link, email_code, and custom.For custom authentication, this type is custom.The name of the authentication provider, such as your company or application. This value will appear in the envelope’s audit logs.
A set of key-value pairs with metadata about the authentication, such as timestamps, session IDs, and correlation IDs. These values will be included in the audit log.
The values provided in
data must be sufficient for verifying the recipient’s authentication. For instance, an expert witness in a legal proceeding should be able to correlate these values with the authentication details in your system.When using custom authentication, you must retain all records necessary to prove the recipient’s authentication, such as session information. Please review our Terms & Conditions for more details.An HTTPS URL to redirect the recipient to after a ceremony is finished.Learn more in Redirect URL.
The type of ceremony URL returned for sharing flexibility.Available options are
short and standard. The default is standard.Use short when you need to share the URL in space-constrained channels such as SMS or push notifications.List of sources allowed to embed this ceremony (for web embedding).These sources will be used in the frame-ancestor directive of the ceremony’s HTTP Content Security Policy (CSP).Sources usually take the form of a scheme and host, like
https://app.example.com, but can also use wildcards, like https://*.example.com. For all available options, refer to the frame‑ancestors documentation.Defaults to an empty list ([]), meaning the ceremony cannot be embedded unless you explicitly allow at least one origin. To allow embedding in all origins (not recommended for production), use ["*"].To ensure compatibility, only the origin (scheme and host) is considered; paths are ignored.
The URL where recipients can access and complete the signing ceremony. This can be embedded in a web or mobile app, or shared by other means.This property will be
null in the following cases:- The recipient is expected to access the ceremony via an internal delivery method (for example, authentication via
email_link). - The ceremony is not currently active (for example, it has been completed, revoked, or declined).
How the deliverable (signed document) is delivered to the recipient.Available options are
email and none. The default is none for approvers and preparers.Time at which the recipient completed (e.g., signed) the envelope, in format. This value can be
null if the recipient has not yet completed.Time at which the status was last updated, in format.
Show Deprecated Fields
Show Deprecated Fields
How the ceremony is created for the recipient.Available options are
automatic and manual. The default is automatic.This property is soft-deprecated but will continue to be supported for backwards compatibility. The recommended way to control ceremony creation is to use the
recipient.ceremony object when creating an envelope.Show Approver
Show Approver
The unique identifier of the recipient.
The unique identifier of the envelope.
Specifies the type of recipient. Available options are
signer, preparer, and approver.For approvers, the type is approver.A unique identifier you assign to each recipient in the envelope.It’s used to match recipients with the places they should interact with (like signature fields) and to identify them in events and webhook notifications.It must be unique within the envelope, contain up to 32 lowercase letters, numbers, and underscores, and start with a letter.
The name of the recipient.
The email address of the recipient.
The current status of a recipient.Available options are
pending, awaiting, sent, completed, rejected, soft_bounced, hard_bounced, failed, and replaced.The current ceremony for the recipient.
Show Ceremony
Show Ceremony
Show Email Link Authentication
Show Email Link Authentication
With link via email authentication, the recipient receives an email with a link to initiate the ceremony, sent by SignatureAPI.
Specifies the type of authentication. The available options are
email_link, email_code, and custom.For link via email authentication, this type is email_link.Show Email Code Authentication
Show Email Code Authentication
With email code authentication, the recipient receives an email from SignatureAPI containing a code. The recipient must enter this code to authenticate during the ceremony.
Specifies the type of authentication. The available options are
email_link, email_code, and custom.For email code authentication, this type is email_code.Show Custom Authentication
Show Custom Authentication
With custom authentication, your application receives a URL to share with the recipient. You can send this URL via email or embed it in a web or mobile application, enabling the recipient to initiate the ceremony.
Specifies the type of authentication. The available options are
email_link, email_code, and custom.For custom authentication, this type is custom.The name of the authentication provider, such as your company or application. This value will appear in the envelope’s audit logs.
A set of key-value pairs with metadata about the authentication, such as timestamps, session IDs, and correlation IDs. These values will be included in the audit log.
The values provided in
data must be sufficient for verifying the recipient’s authentication. For instance, an expert witness in a legal proceeding should be able to correlate these values with the authentication details in your system.When using custom authentication, you must retain all records necessary to prove the recipient’s authentication, such as session information. Please review our Terms & Conditions for more details.An HTTPS URL to redirect the recipient to after a ceremony is finished.Learn more in Redirect URL.
The type of ceremony URL returned for sharing flexibility.Available options are
short and standard. The default is standard.Use short when you need to share the URL in space-constrained channels such as SMS or push notifications.List of sources allowed to embed this ceremony (for web embedding).These sources will be used in the frame-ancestor directive of the ceremony’s HTTP Content Security Policy (CSP).Sources usually take the form of a scheme and host, like
https://app.example.com, but can also use wildcards, like https://*.example.com. For all available options, refer to the frame‑ancestors documentation.Defaults to an empty list ([]), meaning the ceremony cannot be embedded unless you explicitly allow at least one origin. To allow embedding in all origins (not recommended for production), use ["*"].To ensure compatibility, only the origin (scheme and host) is considered; paths are ignored.
The URL where recipients can access and complete the signing ceremony. This can be embedded in a web or mobile app, or shared by other means.This property will be
null in the following cases:- The recipient is expected to access the ceremony via an internal delivery method (for example, authentication via
email_link). - The ceremony is not currently active (for example, it has been completed, revoked, or declined).
How the deliverable (signed document) is delivered to the recipient.Available options are
email and none. The default is none for approvers and preparers.Time at which the recipient completed (e.g., signed) the envelope, in format. This value can be
null if the recipient has not yet completed.Time at which the status was last updated, in format.
Show Deprecated Fields
Show Deprecated Fields
How the ceremony is created for the recipient.Available options are
automatic and manual. The default is automatic.This property is soft-deprecated but will continue to be supported for backwards compatibility. The recommended way to control ceremony creation is to use the
recipient.ceremony object when creating an envelope.Copy
Ask AI
{
"id": "re_26w2VVV5JVm4j459TY5BNM",
"envelope_id": "52872f0e-b919-4d69-89cd-e7e56af00548",
"type": "signer",
"key": "provider",
"name": "Emily Johnson",
"email": "emily@example.com",
"status": "completed",
"ceremony": {
"authentication": [
{
"type": "email_link"
}
],
"embeddable_in": [],
"redirect_url": null,
"url": null,
"url_variant": "standard"
},
"delivery_type": "email",
"signature_options": ["typed", "drawn"],
"completed_at": "2025-12-31T15:00:00.000Z",
"status_updated_at": "2025-12-31T15:00:00.000Z"
}