Skip to main content
Organization seals are available on all plans at no extra charge. One credit per send covers both recipient signatures and any seal participants on the request.

​
What an organization seal is

An organization seal is an electronic seal applied on behalf of a legal entity (your company), not a natural person. It places a company stamp image and metadata on the signed document automatically, without requiring a human to act at signing time. Use it to automate your company’s countersignature: the platform applies the seal at the position you choose in the signing order, so no one on your side has to sign the document by hand. Each seal carries:
  • A stamp image (uploaded, typed from the company name, or drawn)
  • A display name and optional signatory title
  • An attestation recorded at creation, confirming the creator’s authority to apply the seal on the company’s behalf
The seal appears on the final PDF alongside human signatures. The certificate of completion lists it as a participant with the label “Applied automatically”, never “Signed”.

​
Who can create a seal

Only company owners (the Owner role) can create, replace, revoke, or erase organization seals in the dashboard. Company seals live under Settings > Organization Seals; workspace seals live under the workspace’s Settings > Organization Seals. On the API, a protected API key (the key of the company’s protected workspace) is required for company-scope seals. Workspace-scope seals accept that workspace’s own key or the protected key.

​
The authority statement

Every seal requires an attestation before it can be used. The creator reads and accepts a statement confirming they have the authority to bind the company. This acceptance is recorded with:
  • The attester’s identity (the dashboard user, or the API key that made the call)
  • IP address and user agent
  • Language and statement version
  • A SHA-256 hash of the canonical statement text

​
Replacing a seal

Since October 13, 2026, PATCH /seals/{id} creates a new version when you send image, typed, display_name, signatory_title, or statement. Read the seal with GET /seals/{id} first. Send statement with accepted: true, version: 1, language, text exactly equal to the returned statement_text, and signatory_name. Include statement.signatory_title if needed. Without statement, the request returns 400 SEAL_STATEMENT_REQUIRED and writes nothing. Each replacement version records its own acceptance: the replacement time (attested_at), the user or API key that made it, and the signatory supplied with the replacement (signatory_name and signatory_title_attested). The statement text, SHA-256 hash, language, statement version, and authority_name remain those of seal version 1. Requests already sent keep the seal version pinned when they were sent. Requests sent after the replacement use the new version; their certificates show the new signatory and attestation date. POST /seals creation behavior is unchanged. For a seal whose statement_language is en, send this request body to PATCH /seals/{id}. Replace the text placeholder with the exact statement_text from GET /seals/{id}. Use the seal’s stored language for language.
Seal objects returned by POST /seals, GET /seals, GET /seals/{id}, and PATCH /seals/{id} include statement_text and statement_hash. The seal object in organization_seal.created, organization_seal.updated, and organization_seal.deleted webhooks includes them too. Attester user and API key IDs, IP address, and user agent are excluded from these seal objects.

​
Scope and defaults

Seals exist at two levels: Set at most one default per scope. The sender can always switch to a different in-scope seal when creating or editing a signing request.

​
Adding a seal participant

A seal participant is a slot in the signing order that the system fills automatically. Add seal participants to templates and signing requests alongside human recipients. Recipients and seals share one order space.

​
In the editors

In the template editor open the Template Users panel in the sidebar; in the signing request editor open the Signers panel. Click Add seal, pick the seal in the row’s dropdown, and drag the row to set its position. The row reads Applies at send in the top slot and Applies after previous anywhere else. Select the seal row and place at least one stamp field on the document for it. While a seal row is selected the field palette narrows to stamp, text, and date fields.

​
Via the API

On POST /signing-requests and POST /signing-requests/create-and-send, send a seal_participants array. Each entry takes:
  • temp_id is a client-chosen id used to assign fields to the seal (seal_participant_temp_id on the field)
  • seal_id is the organization seal to apply; it must be in scope for the request’s workspace. On the create routes you can omit it to use the default seal
  • order is the position in the shared order space. Order 1 (top slot): the seal applies at send, before any recipient is invited or any credit is charged. After recipient N: the seal applies automatically once everyone with a lower order has finished
On PATCH /signing-requests/{id} and PATCH /templates/{id}, send one seal_participant object instead. Without id it adds a seal participant (seal_id, order); with the id of an existing one it moves it (order) or changes its seal (seal_id). On signing requests, id with swap_to_seal_id swaps a paused one (see Swap below). PUT /templates/{id} takes a seal_participants array and replaces the template’s whole seal set. It applies each users and deleted_users entry on its own; entries applied before a failure stay applied, so read the template again after any non-2xx response. For entries of a seal_participants array on the create routes, a seal from another company or scoped to another workspace returns 404 NOT_FOUND. A revoked, deleted, or replaced (not current) seal returns 409 SEAL_UNAVAILABLE. If you omit seal_id and there is no default seal, the create returns 400 SEAL_UNAVAILABLE. When organization seals are not enabled, a create with seals returns 503 SEALS_DISABLED. When you create, a request without a resolved seal numbers recipients in array order when use_signing_order is false or any recipient omits order. A document-based create with seals needs an order on every recipient and a contiguous order space. Seal participants own stamp fields (at least one), an optional date field, and text fields populated from display_name and signatory_title. All seal fields are server-authored and read-only; client-provided values on them are ignored. Give every seal at least one stamp field: sending a signing request whose seal has none returns 400 SEAL_NO_IMAGE_FIELD. On POST /signing-requests and POST /signing-requests/create-and-send, a seal-owned text field can use seal_attribute (display_name or signatory_title) to set which seal property the field prints. Any other non-null value returns 400 VALIDATION_ERROR; null is accepted. POST /templates does not accept seal_participants. It ignores the key and returns a warnings entry in the 201. Add seals with PATCH /templates/{id} or PUT /templates/{id}. To remove a seal participant and its fields from an unsent request, call DELETE /signing-requests/{id}/seal-participants/{participant_id}. The remaining participants are renumbered to close the gap.

​
Creating from a template

When you create with template_id, the seal_participants key decides what happens to the template’s seals:
  • Absent or null: the request inherits the template’s seals and their fields.
  • An array: the array replaces the template’s seals. The template’s seal fields are not copied.
  • []: the request is created without seals.
  • Any other type returns 400 VALIDATION_ERROR.
Body fields only override template fields, so on a template that has fields a replacement array’s seals cannot get a stamp field in that call, and sending returns 400 SEAL_NO_IMAGE_FIELD. To use your own seals with their fields, create from a document, or, on POST /signing-requests only, use a template without fields and assign body fields with seal_participant_temp_id. Otherwise inherit the template’s seals. An inherited seal uses the current version of its seal. If the seal has no current version, or that version is revoked or deleted, the create returns 409 SEAL_UNAVAILABLE and nothing is created. If at least one inherited seal is kept and organization seals are not enabled, the create returns 503 SEALS_DISABLED. An inherited seal limited to another workspace is left out with its fields, and the response lists it with dropped: true; every persisted entry has dropped: false. When at least one seal is resolved on a template-based create, the request is renumbered 1..n. Inherited seals keep their positions relative to the template’s recipients. Seals in a replacement array are placed by their order. A seal comes first on a tie. Since October 13, 2026, on POST /signing-requests and POST /signing-requests/create-and-send with template_id, if the template has no recipients of its own and seal_participants is absent or null, the inherited seals keep their template order at positions 1..k; the request’s recipients follow at k+1... Explicit replacement arrays, templates with recipients, and requests without seals retain their existing order behavior. POST /templates/{id}/duplicate attaches the stored seal version as is (a replaced, revoked, or deleted seal fails when you send) and returns no seal_participants for every company during normal operation. While multi-document editing is suspended, duplicating a template on the multi-document read-only path returns 409 MULTI_DOCUMENT_READ_ONLY. For other templates during that suspension, it copies the template’s seals the same way: current version, 409 SEAL_UNAVAILABLE, 503 SEALS_DISABLED, and seals limited to another workspace than the target workspace listed with dropped: true; it returns seal_participants.

​
Reading a template’s seals

GET /templates/{id} and PUT /templates/{id} return seal_participants, ordered by order, or [] when the template has none.

​
Changing the order

Signers, approvers, and seals share one order space; CC recipients are separate. On an unsent request, with PATCH /templates/{id} or PATCH /signing-requests/{id}:
  • Move a participant to a position in [1..n]. The participants between the old and new positions shift by one. A target above n returns 400 INVALID_SIGNING_ORDER.
  • Insert a new participant at a position in [1..n+1]. Omit order on a new recipient to append it. For a new recipient, order: 0 or a position outside that range returns 400 INVALID_SIGNING_ORDER. A new seal participant needs a positive integer order: a missing or zero value returns 400 VALIDATION_ERROR, and a position outside [1..n+1] returns 400 INVALID_SIGNING_ORDER.
  • If participants change concurrently, a write can return 409 PARTICIPANTS_CHANGED. Reload and retry.
Once a signing request is sent (finished and cancelled requests included), PATCH /signing-requests/{id} returns 409 ALREADY_SENT. The one exception: a protected caller can swap a paused seal participant on a request that is not finished or cancelled (see Swap below). DELETE /signing-requests/{id}/seal-participants/{participant_id} returns 409 SEAL_MUTATION_NOT_ALLOWED on a sent request, and 409 ALREADY_FINISHED or 409 ALREADY_CANCELLED on a finished or cancelled one.

​
What the certificate shows

The certificate of completion includes one row per seal participant:
The Identity column shows one of three values: If a seal was paused and then swapped, both events appear on the certificate. No IP address is recorded for seal participants.

​
Revoke, stop pending, and swap

​
Revoke

Revoking a seal is prospective: new sends cannot use it, but already-pinned participants on sent requests continue to apply their pinned version. Revoke from the seal’s menu in the dashboard, or with DELETE /seals/{id}. Choose stop pending applications (DELETE /seals/{id}?stop_pending=true) to also pause every in-flight participant that has not yet applied. Each paused participant:
  • Triggers a signing_request.seal.paused webhook
  • Emails the sender explaining which request is affected
  • Blocks signing progress until the sender resolves it

​
Swap

A paused seal participant can be swapped to a different in-scope seal by a company owner from the request view, or via the API with a protected key:
Every swap writes an append-only tracking row. After send, the only exits for a seal participant are swap (on a paused participant) or cancel the entire request.

​
Inspecting a seal

  • GET /seals lists the seals visible in the key’s scope; GET /seals/{id} returns one
  • GET /seals/{id}/image returns the canonical PNG. Every image read is written to the seal’s access log
  • GET /seals/{id}/applications lists the signing requests the seal was applied to
  • GET /seals/{id}/access-log lists lifecycle and image-read events for the seal

​
Erase and retention

Seal versions, attestations, and access-log rows are retained as long as any sent or finished signing request (including test requests) references the version. This is the same standing as signed documents. A revoked seal lineage that is referenced by no request and no template may be erased by a company owner 90 days after revocation, in the dashboard or with DELETE /seals/{id}/erase. The response lists which templates and requests block erasure if any do. Erasure is logged append-only.

​
Webhooks

Organization seals generate seven event types:

​
Seal lifecycle events

  • organization_seal.created: a new seal was created
  • organization_seal.updated: a seal’s image was replaced (new version), it was renamed, or its default flag changed
  • organization_seal.deleted: a seal was revoked
  • organization_seal.erased: a revoked seal lineage was permanently erased

​
Signing request seal events

  • signing_request.seal.applied: a seal was applied to a document
  • signing_request.seal.paused: a seal participant was paused (revoked seal with stop pending, or integrity mismatch)
  • signing_request.seal.swapped: a paused seal participant was swapped to a different seal
Subscribe to these events through the Webhooks configuration. When creating a seal, prefer a typed company name or a company logo stamp over a reproduction of a real handwritten autograph. A handwritten image on an organization seal is misleading (it implies a person signed) and may constitute a forgery asset. The typed and drawn modes produce a clean, recognizable mark that honestly represents the company.

​
Test mode

Test API keys can create and manage live seals. Test signing requests can apply them. Every test document carries a watermark, so no test artifact is ever unmarked. The PAdES digital seal is applied to test documents where enabled in the workspace.