Organization Seals: Automate Your Company's Countersignature with an Electronic Seal

Organization Seals are new in Firma.dev. They apply your company's electronic seal to a document automatically, as a participant in the signing order, so nobody on your side has to countersign NDAs, offer letters or vendor agreements by hand. The feature shipped in API v1.37.0 on September 14, 2026, and the October releases (v1.39.0 and v1.39.1) added seal ordering and seals that carry over from templates.

Seals are available on every plan at no extra charge. One credit per send covers the recipient signatures and any seal participants on the request, so a sealed envelope still costs €0.049 (~5¢ USD).

The countersignature that waits on one person

A candidate signs the offer, a supplier signs the vendor agreement, a partner signs the NDA, and then the document sits there until someone with signing authority on your side remembers to add the company's signature. That person is usually busy, sometimes on holiday... and in the meantime the agreement is only half executed, so whoever is waiting on it ends up chasing.

It tends to be inconsistent too. Different people countersgin different documents, some get signed with a personal signature and some with a pasted logo, and nobody can say for sure who had authority to sign what.

Organization Seals turn the company side of the signature into a step the platform performs, with a recorded authority behind it.

What an organization seal does

An organization seal is an electronic seal applied on behalf of a legal entity, which here means your company. It places a company stamp image and its metadata on the signed document automatically, at the point in the signing order you choose.

Each seal carries three things:

• A stamp image, which you upload, type from the company name, or draw

• A display name and an optional signatory title

• An attestation, recorded when the seal is created, confirming the creator has authority to apply the seal on the company's behalf

Before a seal can be used, its creator reads and accepts an authority statement. Firma.dev records who accepted it (the dashboard user, or the API key that made the call), their IP address and user agent, the language and statement version, and a SHA-256 hash of the canonical statement text.

The docs recommend a typed company name or a logo stamp for the image. A reproduction of a real handwritten autograph on a company seal implies a person signed it... which is misleading.

Where an electronic seal stands legally

Firma.dev is compliant with the ESIGN Act, UETA, eIDAS (SES and AES) and UK eIDAS, and signatures are legally binding in 55+ countries. Seals have their own treatment under each framework, and the legal validity guide covers both. For the signature side of eIDAS, see our breakdown of what an eIDAS-compliant e-signature provider looks like.

In the EU. eIDAS defines electronic seals in Articles 35 and 36 as the equivalent of electronic signatures for legal persons such as companies. Firma.dev's organization seal is designed to meet the Advanced Electronic Seal bar under Article 36:

• Uniquely linked to the company, with a recorded attestation from an authorized representative

• Identifies the company, since the company name, seal display name and signatory title appear on the certificate of completion

• Created under the company's control, because only company owners or holders of the company's protected API key can create, replace or revoke a seal, and the stored image is hash-verified before every application

• Linked to the document, because the seal is applied as part of the PAdES digital seal on the completed PDF, so any later change is detectable

The guide puts it plainly, organization seals applied by Firma.dev are advanced electronic seals.

In the US. US law does not separate seals from signatures. ESIGN defines an electronic signature as any symbol or process adopted by a person with intent to sign, and a company is a person. ESIGN and UETA also recognise an electronic agent acting for a person, and UETA § 9 attributes its acts to that person. When your company creates the seal and accepts the authority statement, it adopts the process, and each application is the act of an agent it authorized. On company documents the seal can stand in for a countersigning officer's signature. If a specific statute or contract clause requires a personal signature, check that with your counsel.

What the certificate shows

Each seal participant gets its own row on the certificate of completion, labelled "Applied automatically", with the seal name and a timestamp:

Organization seal · Acme Corp · Applied automatically · 2026-09-14 14:32 UTC

Organization seal · Acme Corp · Applied automatically · 2026-09-14 14:32 UTC

Organization seal · Acme Corp · Applied automatically · 2026-09-14 14:32 UTC

The Identity column records how the seal was pinned to the request: Company API key, Dashboard, or Embedded integration. Since v1.39.1 the certificate also draws the applied seal's stamp, date and text fields and lists each seal participant in the signers table, in signing order. It sits alongside the rest of the audit trail.

Setting it up without a developer

Only company owners can create, replace, revoke or erase seals in the dashboard. Company seals live under Settings > Organization Seals, and workspace seals live under the same menu in each workspace's settings.

There are two scopes. A company seal can be used by any workspace in the company, and a workspace seal only by that workspace. If a workspace has a seal of its own, its default wins. Otherwise it falls back to the company default. Each scope has at most one default, and the sender can switch to another in-scope seal when creating or editing a request.

To add a seal to a document, open the Template Users panel in the template editor (or Signers in the signing request editor), click Add seal, pick the seal and drag the row into position. In the top slot the row reads Applies at send. Anywhere else it reads Applies after previous, meaning the seal goes on once everyone ahead of it has finished. Then place at least one stamp field on the document for it.

For a typical NDA you'd put the counterpatry first and the seal second. The counterparty signs, the seal applies itself... and the agreement is complete without anyone on your side touching it.

Revoking a seal stops new sends from using it (requests already sent keep the version they pinned). You can also choose to stop pending applications, which pauses every in-flight seal that hasn't applied yet, emails the sender and fires a signing_request.seal.paused webhook. A company owner can then swap the paused participant to a different seal. Revoked seals that no template or request references can be erased 90 days after revocation.

New in October: seal ordering and seals from templates

Two updates landed after launch.

One order space. As of v1.39.0, signers, approvers and seals share a single signing order (CC recipients sit outside it). Moving a participant shifts everyone between its old and new positions by one.

Seals from templates. As of v1.39.1, a signing request created from a template copies the template's seals and their fields. Put the seal on your NDA template once... every request built from it then carries the countersignature in the same position. Seal objects from the /seals endpoints also now return authority_name, the name the seal was attested for.

For SaaS teams: the seal API

If you're sealing documents at volume from your own product, everyhting above is available through the API. v1.37.0 added the /seals endpoints (create, list, get, replace, revoke, read the image, list applications, read the access log, erase), seal_participants[] on templates and signing requests, and seven webhook events: organization_seal.created, .updated, .deleted, .erased, plus signing_request.seal.applied, .paused and .swapped.

With v1.39.1, a template that already has a seal needs nothing extra in the request body. This create-and-send call inherits the template's seal because seal_participants is absent:

curl -X POST "https://api.firma.dev/functions/v1/signing-request-api/signing-requests/create-and-send" \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Mutual NDA",
    "template_id": "template-uuid",
    "recipients": [
      {
        "template_user_id": "template-user-uuid",
        "first_name": "Jane",
        "last_name": "Smith",
        "email": "jane@example.com"
      }
    ]
  }'

curl -X POST "https://api.firma.dev/functions/v1/signing-request-api/signing-requests/create-and-send" \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Mutual NDA",
    "template_id": "template-uuid",
    "recipients": [
      {
        "template_user_id": "template-user-uuid",
        "first_name": "Jane",
        "last_name": "Smith",
        "email": "jane@example.com"
      }
    ]
  }'

curl -X POST "https://api.firma.dev/functions/v1/signing-request-api/signing-requests/create-and-send" \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Mutual NDA",
    "template_id": "template-uuid",
    "recipients": [
      {
        "template_user_id": "template-user-uuid",
        "first_name": "Jane",
        "last_name": "Smith",
        "email": "jane@example.com"
      }
    ]
  }'

The seal_participants key controls the behavior. Absent or null inherits the template's seals, an array replaces them, and [] creates the request with no seal. When you create from a document, pass the seal explicitly:

{
  "seal_participants": [
    { "temp_id": "seal-1", "seal_id": "<seal-uuid>", "order": 2 }
  ]
}

{
  "seal_participants": [
    { "temp_id": "seal-1", "seal_id": "<seal-uuid>", "order": 2 }
  ]
}

{
  "seal_participants": [
    { "temp_id": "seal-1", "seal_id": "<seal-uuid>", "order": 2 }
  ]
}

Fields owned by the seal reference it with seal_participant_temp_id, and every seal needs at least one stamp field or the send returns 400 SEAL_NO_IMAGE_FIELD. Company-scope seals require the protected API key. Workspace seals accept that workspace's own key, which fits a multi-tenant setup built on customer workspaces. One migration note: since v1.39.1, a template-based create with no seal_participants key inherits the template's seals, so send [] if you want none.

Summary

Organization Seals automate the company side of a signature. You create a seal once, with an attested authority behind it, and Firma.dev applies it at the position you choose in the signing order. The docs describe it as an advanced electronic seal under eIDAS Article 36, and under ESIGN and UETA it works as the company's electronic signature applied by an authorized electronic agent. Since October, seals share one order space with signers and approvers and carry over automatically from templates. It's included on every plan, at €0.049 (~5¢ USD) per envelope with no monthly minimums and no per-seat fees.

The full setup is in the Organization Seals guide.

Get started with Firma.dev for free, no credit card required.