On this page0
Unfamiliar word? See Glossary: words used in these docs. Looking for the tasks in order? Begin at Start Here.
Reference
Included in: Team and Advanced. Which Plan Includes What
Zonitix Sign (E-Signatures)
Zonitix Sign is the electronic-signature engine built into your instance. Offer letters are signed on a page your own instance serves, so no document leaves it to be signed and there is no separate e-signature account to set up. It is the default signer for offer letters.
What You Configure
The steps for the two things this page depends on are in the guides Set up email and Hire someone.
What you configure
Only outgoing email. Zonitix Sign needs no API keys and no external URLs. On the first signature your instance generates its own signing key and certificate automatically. The private signing link, and the executed copy afterwards, reach the candidate by email, and your administrator sets that up once under Security & Compliance → Security Settings → Email / SMTP. Until email is set up the offer is still recorded as sent, but the candidate is sent nothing and no screen shows you the signing link. Set up email, withdraw the offer and send it again; or have the offer signed on paper and use Mark as signed manually on the candidate.
How A Candidate Signs
When an approved offer is sent, Zonitix Sign generates the PDF contract from your template, mints a private, single-use signing link, and emails it to the candidate. The candidate opens the link, reviews the contract, ticks a consent box, and signs by typing or drawing their signature, all on a page served by your own instance, at your own domain. The link is the only key: offers are sent link-only, with no separate access code, so anyone who holds the link can open the offer — send it to an inbox only the candidate reads. The moment the candidate signs, the offer is marked accepted and zero-touch onboarding begins. On the candidate in the pipeline, recruiters see Awaiting signature, Link expired or Signed; the finer-grained events (opened, consented, signed) are kept in the audit trail and printed on the Certificate of Completion rather than shown as a live timeline.
Language. The signing page, the careers pages, the interview self-scheduling page and the candidate’s offer portal are shown in English or Spanish, following the candidate’s browser language (English for any other language). The link can also force one of the two; how is under Technical detail below. A Spanish text that is missing falls back to English.
What It Does
Documents & Fields
One Signer Per Offer
Type Or Draw
Full Lifecycle
Not in this release
Zonitix Sign does not yet do multi-signer offers or enforced signing order (sequencing), fields you place yourself, a multi-touch signing-reminder cadence, or initials/checkbox field types. These are roadmap items, not shipped features. (Candidates do get one automatic reminder about 24 hours before their offer link expires, from the recruitment layer — that is separate from the signing engine.)
Signed Copies, Erasure And Report Evidence
Getting The Signed Copy
Erasure And Export
Also Seals Report Evidence
Links Already Sent Keep Working
Security & Integrity
Zonitix Sign produces an electronic signature with a tamper-evident audit trail, aligned with the US ESIGN Act and UETA. We do not claim the eIDAS advanced tier. Signatory identity rests on the private signing link reaching the candidate’s own inbox and on the tamper-evident audit trail, rather than on a per-signer certificate (the seal uses one certificate per instance). If your own policy calls for a further identity check on the signer, verify the candidate by another route before you send.
| Control | What it means |
|---|---|
| Cryptographic seal (PAdES) | The finished PDF is digitally signed to the PAdES standard. Any later change to a single byte invalidates the signature — the document is tamper-evident, not just tamper-labelled. The signing key is created on your instance the first time it is needed, is reused for every later seal, and stays on your instance. |
| Trusted timestamp (RFC 3161) | Each seal carries an independent trusted timestamp from a public timestamp authority, proving when it was signed. Only a cryptographic hash of the document is sent to obtain it — never the document itself. |
| Hash-chained audit trail | Every event — created, sent, opened, consented, signed, completed, declined, voided — is recorded with the signer’s name, email, IP and browser, timestamped, and linked into an append-only hash chain. Re-ordering or editing the log breaks the chain. |
| Certificate of Completion | A separate certificate PDF lists every signer, their sign time and IP, and the audit-chain digest — the artifact you hand an auditor or produce in a dispute. |
| Private single-use links | Signing links use a 256-bit random token, of which only the hash is stored, and they expire with the offer. The link is the key to the document, so it should reach only the candidate. Once a document is completed it cannot be re-signed. |
What this is — and is not
- It is an electronic signature that stands up as evidence: cryptographically sealed, independently timestamped, and audit-chained.
- It is not an eIDAS Qualified signature (QES) or an Adobe-AATL “trusted” signature. The signing certificate is self-signed and unique to your instance, so a PDF reader will not show a pre-trusted green tick out of the box. Reaching QES/AATL requires a certificate-authority partnership, which is on the roadmap, not shipped.
- Where documents live: the offer PDF, the signed and sealed copy (with the signature drawn into it) and the Certificate of Completion stay on your own instance’s storage and are never sent to a third-party e-signature service. They are encrypted at the application layer (AES-256-GCM, under your instance’s encryption key) in addition to whatever your disk provides; files written before that was introduced are sealed by a sweep that runs shortly after start-up and then daily. The instance’s signing key is separate key material and is not part of that envelope. No outbound call carries the document content anywhere: the RFC-3161 timestamp request sends only a hash, the completion callback below is an internal POST to your own recruitment service, and SMTP delivers the invitation and the executed copy to the signers themselves. So the signed document is emailed to its own signers, but never handed to any outside signing service.
If something here is not working as you expect, start with When something goes wrong.
The plain explanation is above. This part is for IT and developers: the exact settings, permission names, API addresses and data fields behind it. Closed: select the heading above to open it. While it is closed, your browser’s find-on-page (Ctrl+F or Cmd+F) does not search this part.
The Signing Key
The signing key is a 3072-bit RSA key with a self-signed certificate valid for ten years. It is kept as a key file in the signature service’s own storage directory on your server, beside the signed documents, with read and write permission for the file’s owner only; that directory is mounted into the signature service and into no other service. The sealing step reads the key file and its certificate each time it signs. Report-evidence seals use a second key pair of the same kind, kept the same way.
The Signing Link
// The private link the candidate receives (your instance’s own signing address, no external site):
https://<your-instance>-sign.zonitix.com/sign/<one-time-token>
Adding ?lang=es or ?lang=en to the link forces Spanish or English, whatever the browser language.
How Completion Reaches Onboarding
When the candidate signs, Zonitix Sign posts an internal completion callback to your recruitment service, which flips the offer to accepted and starts the zero-touch run. Each callback is signed: an X-Zonitix-Signature header carries a timestamp and an HMAC-SHA256 of that timestamp and the exact request body, so a tampered or replayed call (older than five minutes) is refused. A callback that fails for a transient reason is tried up to four times in total, with back-off between tries, and a sweep every 20 minutes picks up any signed offer whose callback never arrived. The endpoint is the historical /webhooks/docuseal path, kept for backward compatibility, now driven by Zonitix Sign rather than any external service. See Webhooks for the exact contract.
// Internal completion callback (on your instance):
POST https://<your-instance>-api.zonitix.com/api/v1/recruitment/webhooks/docuseal
{
"event_type": "form.completed", // or "form.declined"
"data": { "id": "<submission-id>", "source_ref": "offer:<id>" }
}