Build or integrate e-signatures in your product?

A decision guide for product and engineering leads: what building PDF signing in-house involves, what an API integration involves, scenarios and a checklist.

Published Oct 3, 2026 · 7 min read

For most software vendors, integrating an existing signing engine makes more sense than building one. The visible part (a “Sign” button) is small, while the hidden part (PAdES, certificates, evidence, maintenance) is heavy and never finished. Building is mainly justified when signing is your core product or when a trust requirement demands full control. This guide lays out both options so your product and engineering team can decide with clear eyes.

If you first want the overall architecture of a signing workflow inside a SaaS product, start with our integration guide. This page focuses on the decision itself. Add document signing to your SaaS

What building it yourself really involves

A team that decides to do everything in-house takes on a list of workstreams that goes well beyond the first prototype. Here is what to plan for.

Document preparation and field placement UI

You need to render the PDF page by page, let users drop fields (signature, date, text, initials), assign them to each signer, and cope with zoom, rotated pages and malformed files. For repetitive documents such as HR contracts or CRM quotes, you also need reusable templates and, ideally, automatic detection of signing areas.

Multi-signer flows and reminders

Signing order, declines, cancellations, link expiry, reminders, email notifications, and statuses that stay consistent between your database and the document: each edge case becomes a ticket. An employment contract signed by the employee and then by management, or a quote signed by the customer and countersigned by sales, is enough to surface all of them.

PAdES signing and validation

Producing a signed PDF that readers recognize means mastering PAdES (ETSI EN 319 142): document digest, CMS structure, incremental updates, several successive signatures on one file. You then have to check the output in several PDF readers, which do not all behave the same way. PAdES: inside a signed PDF

Certificates, keys and HSMs

A signing key has to be protected, often in an HSM, with rotation, backups and logged access. In production, some customers will want their own PKI or a specific trust service provider, so your engine must be able to connect to more than one certificate source.

Timestamps, evidence and audit trail

To prove a signature existed at a given time, you call an RFC 3161 timestamp authority. You also keep an activity log and SHA-256 digests, and produce an evidence report that a lawyer or auditor can read.

Security, languages and maintenance

• Security reviews: PDF encryption at rest, signing links, access control, and the security questionnaires your larger customers send.
• Multilingual signer UI: Arabic requires a right-to-left layout, suitable fonts and mobile testing, on top of French and English.
• Ongoing maintenance: PDF readers change, standards are revised, algorithms age, and every change needs retesting.

What integrating involves

Integrating still takes work. Your team keeps a real share of responsibility, shorter and better defined.

• API mapping: link your objects (contract, quote, customer file) to a signature request, its signers and its fields.
• Webhooks: receive completion, decline and cancellation events, verify their HMAC signature and update your statuses.
• Idempotency: send a stable client reference so a retried call never creates two requests.
• Sandbox testing: validate the full journey with test keys before going live.
• Provider dependency: availability, API changes, exit terms and how you retrieve your signed PDFs.
• Data and retention: where documents are stored, for how long, who can access them, and how that matches your customer contracts.

In practice, creating a request from a CRM looks like this. The client reference makes the call idempotent, and the callback URL receives signed events.

curl -sS \
  -H "Authorization: Bearer $KHATM_API_KEY" \
  -F "document=@contrat.pdf;type=application/pdf" \
  -F 'request={
    "client_reference": "crm-quote-4821",
    "signers": [
      {"reference": "client", "name": "Client", "email": "client@example.com", "order": 1},
      {"reference": "sales", "name": "Sales", "email": "sales@example.com", "order": 2}
    ],
    "template_id": "7f331696-d933-46cd-aeff-1c08151c85c1",
    "callback_url": "https://app.example.com/webhooks/khatm"
  }' \
  "$KHATM_BASE_URL/v1/signature-requests"

Comparing the two options

Three typical scenarios

Early-stage SaaS

Your priority is proving product value. An in-house signing module would tie up your team on a peripheral topic. Recommendation: integrate an API, validate the journey in the sandbox, and keep your effort on your core product.

Established vendor with strict UX and brand needs

Your HR software or customer portal has a strong identity, and signers should never feel they have switched tools. Recommendation: integrate an engine that lets your application own the interface and the brand, instead of a suite that brings its own. Building remains an option if you already run a PKI team. White-label document signing

Regulated customers requiring a specific trust provider

A bank or public body mandates its own certificate, HSM or trust service provider. Recommendation: choose an engine that can connect to that infrastructure. Building does not remove the need for that provider; you would simply have to wire it up alone.

Decision checklist

1. Is signing central to your value proposition, or one expected feature among others?
2. Do you have in-house skills in PDF, cryptography and key management, and can you retain them over time?
3. Do your signers need an interface in Arabic, French and English?
4. Do your customers require a particular certificate, HSM or trust service provider?
5. What retention and data location rules do your contracts set?
6. Can you test the full journey in a sandbox before committing?
7. How would you retrieve your signed PDFs and evidence if you changed provider?

The middle path with Khatm

Khatm is built for vendors who want to keep their product and delegate the engine. You keep your interface and business logic; Khatm handles PDFs, signers, fields, PAdES signing, the PDF evidence report and JSON evidence. The signer journey works natively in Arabic (right-to-left), French and English.

• The public demo, with no account, lets you sign a real PDF with a self-signed test certificate.
• The API v1 sandbox is self-serve: test keys, signed webhooks, field detection, reminders.
• Production is prepared with Khatm: adapting the flow and brand, connecting your signers’ identity, the certificate from your PKI, HSM or trust service provider, RFC 3161 timestamps when that provider supplies them, and retention defined with you.

PDF signing built into your software, under your brand, in Arabic, French and English. Test in the sandbox; we guide you all the way to production. Start with the demo or a sandbox key, read the docs, then prepare production with us. Try the demo Get a sandbox key Documentation Implementation

General information, not legal advice. Confirm the requirements for your transaction with the appropriate adviser or receiving authority.