Settings → Signature Settings¶

Everything a user signs with: their saved signature / initials / stamp library, the legacy single-image pair that predates it, and a read-only summary of which signature types they're allowed to use and how much quota remains.

One user can save many signatures

A user keeps three independent libraries — signatures, initials and stamps — each with its own default, and picks which entry goes into each field they sign. The older GET/PUT /signatures pair still exists and still returns only the single default signature/initials pair; it is kept in step with the library automatically.

Endpoint summary¶

Method	Path	Notes
GET	`/user/v1/settings/signatures/library`	The full library: signatures, initials, stamps + caps
POST	`/user/v1/settings/signatures/library`	Add one entry
PUT	`/user/v1/settings/signatures/library/{id}`	Update one entry
DELETE	`/user/v1/settings/signatures/library/{id}`	Delete one entry
PUT	`/user/v1/settings/signatures/library/{id}/default`	Make an entry its kind's default
GET	`/user/v1/settings/signatures`	Legacy: the default signature/initials pair
PUT	`/user/v1/settings/signatures`	Legacy: replace that pair
GET	`/user/v1/settings/getDigitalSignConf`	Signature capability + quota summary
GET	`/user/v1/settings/getDummyDigitalSignAppearance`	Placeholder appearance image

The library¶

Reading it¶

GET /user/v1/settings/signatures/library

{
  "signatures": [
    { "id": 41, "kind": "SIGNATURE", "image": "iVBORw0KGgo...", "source": "DRAW",
      "isDefault": true,  "createdAt": "2026-07-02T09:14:00Z", "updatedAt": "2026-07-02T09:14:00Z" },
    { "id": 55, "kind": "SIGNATURE", "image": "iVBORw0KGgo...", "source": "TEXT",
      "isDefault": false, "createdAt": "2026-07-19T11:02:00Z", "updatedAt": "2026-07-19T11:02:00Z" }
  ],
  "initials": [
    { "id": 42, "kind": "INITIALS", "image": "iVBORw0KGgo...", "source": "DRAW", "isDefault": true }
  ],
  "stamps": [
    { "id": 77, "kind": "STAMP", "image": "iVBORw0KGgo...", "source": "UPLOAD", "isDefault": true }
  ],
  "maxPerKind": 5,
  "maxSignatures": 5,
  "maxInitials": 5,
  "maxStamps": 3
}

Field	Notes
`signatures` / `initials` / `stamps`	Each list is ordered default first, then oldest to newest. Always present, possibly empty — so an empty list is distinguishable from an older backend that omits the key.
`image`	Raw base64 PNG, no `data:` prefix — the client adds `data:image/png;base64,` itself when rendering.
`source`	`DRAW`, `UPLOAD` or `TEXT`. Informational only; nothing branches on it.
`isDefault`	Exactly one entry per kind carries `true` whenever that kind has any entries at all.
`maxSignatures` / `maxInitials` / `maxStamps`	The administrator-configured cap for each list. The three can differ.
`maxPerKind`	Deprecated. Carries the `maxSignatures` value, kept only for clients written before the caps became per-kind. Read the three fields above instead.

Caps are set by an administrator (Configurations → Signature settings), constrained to 1–10, and default to 5. If the setting can't be read, the service falls back to 5 rather than failing the call — a cap is policy, and an unreadable policy must not stop someone signing.

Adding an entry¶

POST /user/v1/settings/signatures/library
Content-Type: application/json

{ "kind": "SIGNATURE", "image": "data:image/png;base64,iVBORw0KGgo...", "source": "DRAW", "makeDefault": true }

Field	Required	Notes
`kind`	yes	`SIGNATURE`, `INITIALS` or `STAMP`, case-insensitive
`image`	yes	Base64 PNG, with or without a `data:` prefix — the prefix is stripped, and whitespace/line breaks inside the payload are removed
`source`	no	`DRAW` / `UPLOAD` / `TEXT`; an unrecognized value is dropped, not rejected
`makeDefault`	no	Also promote the new entry to its kind's default

Returns the created entry (the same object shape as in the library lists).

The first entry of a kind is always the default

Regardless of makeDefault. Otherwise a user would end up with a saved signature that nothing resolves to.

Updating an entry¶

PUT /user/v1/settings/signatures/library/55
Content-Type: application/json

{ "makeDefault": true }

Only the fields you send are applied, so an entry can be promoted to default without re-sending its image. kind is ignored on update — an entry never changes library. Updating the image of the entry that is currently default also refreshes the legacy mirror (below).

Deleting an entry¶

DELETE /user/v1/settings/signatures/library/55

If the deleted entry was the default, the oldest remaining entry of that kind is promoted automatically. If it was the last one of its kind, the legacy mirror for that kind is cleared.

Setting the default¶

PUT /user/v1/settings/signatures/library/41/default

Makes that entry the sole default for its kind and mirrors its image onto the legacy column, so every older consumer follows the same choice. Returns the updated entry.

Changing the default affects documents signed from that point on; documents already signed keep the image they were signed with.

Errors¶

HTTP	Code	Condition
400	`SIGNATURE_KIND_INVALID`	`kind` missing or not one of the three values (create only)
400	`SIGNATURE_IMAGE_REQUIRED`	No usable image on create
400	`SIGNATURE_IMAGE_INVALID`	Something was sent as `image` but it isn't decodable base64
400	`SIGNATURE_IMAGE_TOO_LARGE`	Base64 payload over 8 MB (the UI caps uploads at 5 MB)
400	`SIGNATURE_LIBRARY_LIMIT_REACHED`	That kind is already at its cap — delete an entry first
404	`SIGNATURE_ASSET_NOT_FOUND`	No such entry in the caller's own library

Every endpoint is scoped to the authenticated caller: ids from another user's library resolve as 404, never as someone else's image.

Applying an entry to a field¶

The library only stores the images. Which entry landed on which field is carried by the workflow API, as signatureAssetId on the field — see Sending & Signing → Place fields and the fields/save call.

Two things follow from that split:

The image bytes still travel in the field's value exactly as before. signatureAssetId is a pure link, stored so that reopening a document shows the right entry per field even after the signer edits or renames one.
The link is returned only to the signer it belongs to. Reading fields as any other participant returns signatureAssetId: null for their fields, because library ids are per-user and would otherwise resolve against the reader's own library.

Legacy signature pair¶

Unchanged, and still what the mobile app and the v2 web app call:

GET /user/v1/settings/signatures

{
  "image": "iVBORw0KGgo...",
  "initialImage": "iVBORw0KGgo...",
  "signatureType": "SIMPLE",
  "digitalSignatures": { "source": "...", "csc": { "userName": "..." } }
}

PUT /user/v1/settings/signatures
Content-Type: application/json

{ "image": "data:image/png;base64,...", "initialImage": "data:image/png;base64,..." }

A PUT here writes the legacy pair and syncs the library: the default SIGNATURE / INITIALS entry gets the new image, or a first entry is created if that list was still empty. The sync is best-effort — if it fails, the legacy write is still committed and the call still succeeds.

The reverse direction is automatic too: whenever a library default changes, its image is mirrored back onto the legacy field. Stamps are the exception — there is no legacy column for them, so a stamp is library-only and never overwrites a user's signature.

Capability and quota¶

GET /user/v1/settings/getDigitalSignConf

{
  "isDigitalSignatureEnabled": true,
  "isSmartCardEnabled": false,
  "quotaElectronic": 50,
  "quotaAdvanced": 10,
  "quotaQualified": 0,
  "eidasEnabled": true,
  "esignConsentRequired": true
}

Quotas are consumed per signature action and enforced at the point of signing (see Sending & Signing) — this endpoint is read-only, for showing "you have N advanced-signature actions left" in the UI. Saved stamps consume no quota: a stamp is an image, not a signature.