Sign
Legally binding e-signatures in your product, embedded or by email.
coss.sign asks people to sign PDFs. They sign inside your app (an embedded signing page) or from
a link coss.com emails them, and once everyone has signed you get a sealed PDF with a certificate
of completion and a hash-chained audit trail. It uses the same API key, webhooks,
logs and sandbox environments as everything else.
const { : } = await ...({
: "Services agreement",
: [{ : "agreement.pdf", : }],
: [
{
: "Ada Lovelace",
: "ada@example.com",
: [{ : "signature", : "{{signature:signer_1}}" }],
},
],
});Signatures are simple electronic signatures under the US ESIGN Act and UETA and the EU's eIDAS: each signer agrees to sign electronically, signs with a deliberate act, and is identified by the link they opened or by your app; the audit trail records each step, and the completed PDF is sealed, so any later change shows.
How a request goes
- Create it with documents (uploaded or inline PDFs) and signers, each with their fields
placed by position or by a text anchor in the PDF. It is
sentat once, or adraftwithsend: false. - Signers sign.
delivery: "email"(the default) signers get an email with their link;"embedded"signers sign in your app, in an iframe you open for them (embedded signing). Before they see a document, each one agrees to sign electronically. - It completes. When the last signer signs, coss.com seals the completed document and sends
sign_request.completed. Download it withcoss.sign.requests.signedDocument(id).
What's in it
Signing sessions, mountSigning and the events your page gets.
Invitations, reminders, expiry and signed copies, from your own address.
Placing fields by position or text anchor, and what each type does.
Reusable documents with roles and merge fields, and the embedded builder.
The sealed PDF, the certificate and the hash chain.
Sandbox requests and what they don't do.
On This Page