Firma.dev API v1.6, v1.7, and v1.8: Split PDFs, Hand-Drawn Signatures, and Custom Email Templates

Three API releases have shipped since v1.5, and all three are non-breaking, drop-in upgrades. Here's what's new and how to use it.

v1.6.0: Split PDF Downloads and Field Type Cleanup

Released February 12, 2026

The most requested feature in v1.6 is split PDF downloads. Previously, when a signing request completed, you got a single combined PDF that included both the signed document and the audit trail certificate. Now you can download them separately.

Two new fields are available on completed signing requests:

{
  "document_only_download_url": "https://storage.example.com/document.pdf",
  "certificate_only_download_url": "https://storage.example.com/certificate.pdf"
}

{
  "document_only_download_url": "https://storage.example.com/document.pdf",
  "certificate_only_download_url": "https://storage.example.com/certificate.pdf"
}

{
  "document_only_download_url": "https://storage.example.com/document.pdf",
  "certificate_only_download_url": "https://storage.example.com/certificate.pdf"
}

Both URLs are pre-signed and expire after 1 hour. If you need a fresh link, just fetch the signing request again. This is particularly useful if you need to store the signed document in one system and the audit trail in another, or if your end users only need the clean signed PDF without the certificate pages appended.

v1.6 also cleaned up field type naming. The API now accepts both initials and initial, as well as textarea and text_area, and normalizes them automatically. If your integration was already using the original names, nothing breaks. If you prefer the normalized forms, those work too.

Full v1.6 changelog

v1.7.0: Hand-Drawn Signatures

Released February 27, 2026

Some workflows require signers to physically draw their signature rather than selecting a typed or font-generated option. v1.7 introduces the hand_drawn_only setting to enforce exactly that.

Add it to your signing request settings:

{
  "settings": {
    "hand_drawn_only": true,
    "use_signing_order": false,
    "allow_download": true
  }
}

{
  "settings": {
    "hand_drawn_only": true,
    "use_signing_order": false,
    "allow_download": true
  }
}

{
  "settings": {
    "hand_drawn_only": true,
    "use_signing_order": false,
    "allow_download": true
  }
}

When enabled, the signing interface removes typed and font-based signature options entirely. Signers must draw their signature by hand. This is useful for compliance-heavy industries like healthcare and financial services where regulators or auditors expect handwritten signatures specifically.

The setting defaults to false, so existing signing requests are unaffected.

This release also added backward-compatible legacy settings fields to the SigningRequest schema. These are integer-based (0/1) versions of the boolean settings, designed for older integrations that expect that format. If you're building new, stick with the settings object. The legacy fields are there for teams migrating from older systems.

Full v1.7 changelog

v1.8.0: Email Templates API and Language Support

Released March 3, 2026

v1.8 is the biggest of the three. The headline feature is the Email Templates API, which gives you full control over the notification emails Firma.dev sends during the signing process.

You can customize templates for five email types: signing_invite, next_signer, signing_expired, signing_cancelled, and signing_declined. Templates support HTML bodies with placeholders like {{signer_name}}, {{document_name}}, and {{signing_link}}.

Here's a quick example:

PUT /workspace/{workspace_id}/email-templates/signing_invite
{
  "subject": "Please sign: {{document_name}}",
  "body": "<p>Hi {{signer_name}},</p><p>Please review and sign using this link: {{signing_link}}</p>"
}

PUT /workspace/{workspace_id}/email-templates/signing_invite
{
  "subject": "Please sign: {{document_name}}",
  "body": "<p>Hi {{signer_name}},</p><p>Please review and sign using this link: {{signing_link}}</p>"
}

PUT /workspace/{workspace_id}/email-templates/signing_invite
{
  "subject": "Please sign: {{document_name}}",
  "body": "<p>Hi {{signer_name}},</p><p>Please review and sign using this link: {{signing_link}}</p>"
}

Templates follow a hierarchy: workspace-level templates override company-level templates, which override the built-in defaults. This means you can set a company-wide template and then customize it per Customer Workspace for white-label scenarios where each of your customers needs their own branded emails.

Alongside custom templates, v1.8 adds a language field to both Company and WorkspaceSettings. Set it to one of seven supported languages (en, es, it, pt, fr, de, el) and Firma.dev's built-in email templates will use that language automatically. Combined with workspace-level overrides, you can serve international markets without managing seperate email infrastructure.

Schema Improvements

v1.8 also shipped several schema improvements worth knowing about:

The Template schema now includes inline recipients, fields, settings, page_count, and expiration_hours when you fetch a single template. That means fewer API calls to get the full picture of a template's configuration.

Signing request responses have been split into endpoint-specific shapes (SigningRequestListItem, SigningRequestCreateResponse, SigningRequestDetail) with inline data and standardized timestamp fields. This makes the responses more predictable and easier to type in your codebase.

Webhooks gained three new fields: description, consecutive_failures, and auto_disabled_at. The failure tracking fields are particularly handy for monitoring. If a webhook starts failing, you can now see how many consecutive failures have occurred and whether Firma.dev auto-disabled it.

Note that v1.8 also corrected several field names in the OpenAPI spec to match the actual API responses. If your integration already handles the real response fields (which it almost certainly does), no changes are needed.

Full v1.8 changelog

Upgrading

All three releases are fully backward compatible. No breaking changes, no migration steps required. You can upgrade your API version from v1.5 straight to v1.8 and everything will continue working as before, with the new features available immediately.

For the full changelog with every schema change and migration note, check the API Changelog in the docs. If you're just getting started with Firma.dev, you can get your API key for free and start building today.

Previous release notes: v1.5 | v1.3 and v1.4