M20

Contracts & E-Signature

A standalone e-signature module: upload a PDF, place fields on the page, send to recipients — on-platform or by email — and collect legally credible e-signatures with a full evidence trail. Parallel or sequential e-sign flows, templates, clone lineage.

API workflow reference →
The shape of it

Contract → Recipient → E-Signature.

Three concepts carry the whole module. A document gets fields placed on it, recipients get tokenized links to e-sign it, and every signing act writes an evidence record. Status is never set by hand — it derives from what the recipients have actually done.

A

Contract

The document

A PDF in blob storage plus placed fields — twelve types, each with geometry, a recipient, and required / read-only flags.

  • Templates are contracts with a flag
  • Clone records lineage back to its source
  • Status derives from its recipients
B

Recipient

The signer

A platform party, or just a name and an email — outside counsel signs without ever creating an account.

  • Sign order: parallel, sequential, or mixed
  • Tokenized link, separate from identity
  • Sent → viewed → signed → declined state
C

E-Signature

The evidence

The act of e-signing, recorded as evidence rather than form data — and kept immutable once the contract executes.

  • Drawn, typed, or uploaded mark
  • IP, user agent, consent-text version
  • SHA-256 hash of the exact signed bytes

The structural point: status rolls up, never down. Each recipient's state advances as they act; the contract reads Partially Signed at three-of-four and flips Fully Executed on the last mark — and the moment it does, every consumer watching reacts. An M19 engagement goes Active the same instant.

Create

Any PDF becomes a signable contract.

Upload the source document and the canvas lays out its pages, ready for fields. Name it, describe it, and decide whether it's a one-off or a reusable template — templates power the picker that consumers like M19 Work resolve at hire time.

  • The source PDF is stored once in blob storage; the canvas works from cached page counts
  • Flag any contract as a template and it becomes eligible for reuse; clones record their lineage back to it
  • Inactivate retires a contract from the working list without touching its history
Build

Drag twelve field types onto the page.

The builder is a drag-and-drop canvas: place a signature box, initials, dates, text areas, checkboxes — twelve field types in all — size and position them per page, and assign each one to the recipient who must fill it.

  • Every field carries required / read-only flags, tab order, and an optional format mask
  • Default values pre-fill fields from consumer data — an M19 engagement lands its terms into the contract automatically
  • Field labels are localized like everything else in the platform, so 'Scope of work' can read correctly in any language
Send

Recipients, in the order you choose.

Add recipients — a platform party, or just a name and an email for signers who have no account — then choose the order. Leave it empty and everyone signs at once; number the recipients and they unlock in sequence; share a number and those sign together.

  • Each recipient gets a tokenized signing link, separate from the record's identity, so a link can be revoked or rotated safely
  • Per-recipient state tracks sent, viewed, signed, declined — with decline reasons and expiry dates
  • Resend re-delivers the link and counts how many times it took
Sign

Signers fill exactly what's theirs.

The signing view walks a recipient through their assigned fields — and only theirs. Required fields gate the finish button; read-only fields show context without inviting edits; tab order keeps the walk linear.

  • The signing session is tokenized — no login, no account, straight from the email link to the document
  • Typed values are stored as typed data (string, date, boolean, decimal), not screenshots of a form
  • A recipient can decline with a reason, and the contract's status reflects it immediately
Execute

Adopt an e-signature. Finish. Executed.

The signer adopts an e-signature — drawn on the canvas, typed in a script face, or uploaded as an image — applies it, and finishes. The final e-signature flips the contract to Fully Executed, and every consumer watching it reacts: an M19 engagement goes Active the same moment.

  • The signing act writes evidence, not just data — signature type, IP address, user agent, and the consent-text version accepted
  • A SHA-256 hash pins exactly which bytes were signed; the executed record is immutable
  • Partially Signed is a real status — a three-of-four contract reads honestly in the list view
Field types

Twelve field types, one builder.

Everything a contract asks for is one of twelve placed boxes. Each carries its geometry, its recipient, required and read-only flags, tab order, and an optional format mask.

  • Signature
  • Initials
  • Name
  • Company Name
  • Title
  • Email
  • Phone Number
  • Address
  • Date
  • Sign Date
  • Open Text Area
  • Checkbox

Contracts turns any PDF into an e-signature document. Upload the source file, drag fields onto the page canvas — twelve field types from signature and initials down to checkboxes — assign each field to a recipient, and send. Recipients sign in parallel or in an enforced sequence; each one gets a tokenized signing link, so signers don't need a platform account. The contract's status derives from its recipients: Draft, Sent, Partially Signed, Fully Executed, with Voided and Expired kept distinct because a cancelled contract and a timed-out one are different events. The module is deliberately standalone — nothing in it depends on any consumer. M19 Work is its first: an engagement's contract is cloned from a template, pre-filled from the posting and proposal, and the engagement activates only when the contract comes back fully executed. Every signing act is evidence, not just data: e-signature type (drawn, typed, or uploaded), IP address, user agent, the exact consent text version the signer accepted, and a SHA-256 hash pinning exactly which bytes were signed. E-signatures are never deleted.

Capabilities

  • PDF-first — upload the source document once; the page canvas lays out against cached page counts without re-opening the file
  • Twelve field types — Signature, Initials, Name, Company Name, Title, Email, Phone Number, Address, Date, Sign Date, Open Text Area, Checkbox
  • Drag-and-drop field builder — place, size, and position fields per page; assign each to a recipient; mark required or read-only; set tab order and format masks
  • Pre-fill — fields can carry default values, so a consumer like M19 Work can land posting, proposal, and term data into the contract before it goes out
  • Recipients without accounts — a platform party or a bare name + email; outside counsel and a client's CFO can sign without ever registering
  • Parallel or sequential signing — leave sign order empty for simultaneous signing, number recipients to enforce a sequence, or share a number to mix both in one contract
  • Tokenized signing links — the signing-link secret is separate from the record's identity, so revoking or rotating a link never disturbs the contract
  • Send, resend, expire — per-recipient sent / viewed / signed / declined state, resend counts, expiry dates, and decline reasons
  • Status that derives from reality — Draft, Sent, Partially Signed, Fully Executed; Voided and Expired tracked as distinct outcomes
  • Templates + clone lineage — flag a contract as a template, clone it per use, and trace any executed contract back to the template it came from
  • E-signature evidence — drawn, typed, or uploaded marks with IP address, user agent, the consent-text version accepted, and a SHA-256 hash of the exact signed bytes
  • Inactivate vs delete — retire a contract from the working list without deleting it; executed signatures are evidentiary records and are never deleted

Benefits

  • Stop paying per-envelope e-signature fees for a flow your product runs every day — the module is part of the codebase you license
  • Signers outside your platform sign in one click from an email link — no account creation standing between you and an executed contract
  • The evidence trail is built for scrutiny — who signed, how, from where, against which consent text, and a hash of exactly what they signed
  • One-way dependencies keep it reusable — Work consumes Contracts; Contracts knows nothing about Work, so your next module can consume it too

Flow of work

  1. 01Upload — the source PDF lands in blob storage; the canvas lays out its pages
  2. 02Build — drag twelve field types onto the page, assign each to a recipient, mark required, set tab order
  3. 03Send — recipients get tokenized signing links; parallel, sequential, or mixed order
  4. 04Sign — each recipient fills their required fields, adopts a drawn, typed, or uploaded e-signature, and finishes
  5. 05Execute — the last e-signature flips the contract Fully Executed and notifies its consumer (an M19 engagement goes Active)

Subfeatures

  • PDF upload + page canvas
  • Twelve field types
  • Drag-and-drop field placement
  • Per-recipient field assignment
  • Required / read-only flags
  • Default values + pre-fill
  • Tab order + format masks
  • Localized field labels
  • Platform or email-only recipients
  • Parallel signing
  • Sequential signing (sign order)
  • Mixed-order signing
  • Tokenized signing links
  • Send / resend with counts
  • Per-recipient sent / viewed / signed state
  • Decline with reason
  • Contract expiry
  • Draft → Fully Executed lifecycle
  • Voided vs Expired kept distinct
  • Templates (IsTemplate)
  • Clone with lineage
  • Inactivate / reactivate
  • Typed field values
  • Drawn / typed / uploaded e-signatures
  • IP + user-agent capture
  • Consent-version record
  • SHA-256 document hash
  • Immutable e-signature records
Source surfaces (technical reference)

Internal code areas in the licensed Full-Stack codebase that back this module.

  • ApiContractContract — CRUD, clone, send, void, inactivate, download
  • ApiContractField — builder geometry, assignment, values
  • ApiContractRecipient — recipients, sign order, resend, expiry
  • ApiContractSigning — tokenized signing session, adopt + finish
  • Signature evidence writer (hash, IP, consent version)
Evidence, not just data

Built as if a lawyer will read it later.

A signature row is separate from the field values it sits beside, because it is evidence of an act, not form data. Each one records how the mark was made — drawn, typed, or uploaded — the IP address and user agent it came from, which version of the consent text the signer accepted, and a SHA-256 hash of the exact document bytes signed. There is no delete path for an executed signature, by design.

  • Voided and Expired are distinct statuses — a contract someone cancelled and one that timed out are different events with different follow-up
  • Clone lineage traces any executed contract back to the template it came from
  • The dependency runs one way: consumers reference contracts; the contract module neither knows nor cares who's consuming it
In the stack

Where it lives. What it exposes.

A quick visual of how Contracts & E-Signature participates across the CleenUI stack, alongside the named operations it adds to the API surface.

M20 · architecture
Frontend
React · TailwindCSS · 60+ components
Contract list (working + templates)PDF upload + page canvasDrag-and-drop field builderRecipient + sign-order editorSend / resend panelSigning experience (fill, adopt, finish)Status + audit timeline
API
C# Web API · production-ready · role-aware
Contract CRUD + clone + send + voidField CRUD + geometry + valuesRecipient CRUD + resendTokenized signing sessionSignature + evidence retrieval
Database
AzureSQL · 300+ tables · 700+ procedures
ContractsContractLanguagesRecipientsFieldsFieldLanguagesFieldValuesSignatures
Async Services and Batch Jobs
WebJobs & Functions · queue-backed
Signing-link delivery + resendContract expiry sweepExecution notifications to consumers (M19)Document hash verification
All four layers ship together as the Full-Stack license. M20 blocks are highlighted.
API operations

Named operations on this surface

28
Try these in Postman
  • POSTPDF upload + page canvas/contract/pdf-upload-page-canvas
  • POSTTwelve field types/contract/twelve-field-types
  • POSTDrag-and-drop field placement/contract/drag-and-drop-field-placement
  • POSTPer-recipient field assignment/contract/per-recipient-field-assignment
  • POSTRequired / read-only flags/contract/required-read-only-flags
  • POSTDefault values + pre-fill/contract/default-values-pre-fill
  • POSTTab order + format masks/contract/tab-order-format-masks
  • POSTLocalized field labels/contract/localized-field-labels
  • POSTPlatform or email-only recipients/contract/platform-or-email-only-recipients
  • POSTParallel signing/contract/parallel-signing
  • POSTSequential signing (sign order)/contract/sequential-signing-sign-order
  • POSTMixed-order signing/contract/mixed-order-signing
  • POSTTokenized signing links/contract/tokenized-signing-links
  • POSTSend / resend with counts/contract/send-resend-with-counts
  • POSTPer-recipient sent / viewed / signed state/contract/per-recipient-sent-viewed-signed-state
  • POSTDecline with reason/contract/decline-with-reason
  • POSTContract expiry/contract/expiry
  • POSTDraft → Fully Executed lifecycle/contract/draft-fully-executed-lifecycle
  • POSTVoided vs Expired kept distinct/contract/voided-vs-expired-kept-distinct
  • POSTTemplates (IsTemplate)/contract/templates-istemplate
  • POSTClone with lineage/contract/clone-with-lineage
  • POSTInactivate / reactivate/contract/inactivate-reactivate
  • POSTTyped field values/contract/typed-field-values
  • POSTDrawn / typed / uploaded e-signatures/contract/drawn-typed-uploaded-e-signatures
  • POSTIP + user-agent capture/contract/ip-user-agent-capture
  • POSTConsent-version record/contract/consent-version-record
  • POSTSHA-256 document hash/contract/sha-256-document-hash
  • POSTImmutable e-signature records/contract/immutable-e-signature-records

Each operation maps to an endpoint in the licensed C# Web API surface.