Workflow System Signatures
Introduction
Workflow Signing already gives you a flexible way to orchestrate one or more documents and one or more signers, decoupled over time, with a final result available as either a sealed PAdES or a compact signed Workflow Token (signed JWT).
System Signatures extends that model with a new signer: a system identity.
That means you can build flows like:
- A document is generated by Service A → routed to Service B (partner, ERP, fulfillment, finance) → Service B signs as a system → workflow completes → you retrieve the sealed PAdES or Workflow Token for storage, audit, and downstream automation.
In other words: the same Workflow API foundation, now supporting headless approvals where the “signer” is a controlled, permissioned integration — not a person using an eID.
Plausible use cases
B2B document exchange (classic “two systems agree”)
- Purchase orders, order confirmations, delivery confirmations, supplier agreements.
- One organization’s system creates the workflow; the counterparty’s system signs when it accepts terms.
Policy-driven “auto-approval” with an audit trail
- “If credit check passes, stock is available, and risk score < threshold → system signs.”
- Turns business rules into a single, verifiable event.
Back-office countersignature / attestation
- A human signs with eID, then an internal system signs to attest: “checks completed, archived, journalized, and posted.”
- Useful when downstream automation needs a cryptographic checkpoint.
Multi-service workflows inside one org
- CRM generates contract → Legal service signs approval → Billing signs acceptance → workflow completes.
- Helpful when “who approved what” must be provable across microservices.
High-volume, low-friction signing
- Monthly statements, standardized terms, platform-generated confirmations where a human click would be pure ceremony.
Workflow API for system signatures
The technical integration is an extension to the Workflow API, utilizing the “Workflow API System Signature” endpoints found in the API documentation.
The relevant privileges required to setup and create workflows (for your API client) are:
| Privilege | Description |
|---|---|
| Workflow: API, read | Allowed for read endpoints in the Workflow API |
| Workflow: API, write | Allowed for write endpoints in the Workflow API |
The relevant privileges required for a system signature signing system integration (the party that receives a signtext_id and needs to sign):
| Privilege | Description |
|---|---|
| Workflow: API client organization signature, read | Allowed for read endpoints in the Workflow API for system signatures |
| Workflow: API client organization signature, sign | Allowed to create system signature via the Workflow API for system signatures |
Add system signature to Workflow as part of creation
When setting up a new Workflow, you can have your own system signature as part of the new flow by setting up the relevant system signature parameters for the creation request. Your API client needs the “Workflow: API, write” privilege for creating the workflow and the “Workflow: API client organization signature, sign” privilege in order to be allowed for setting the system signature as part of the creation.
System signature flow (API)
- Create Workflow
- Retrieve signtext ID for system signature, bind to target organization (CVR, i.e. DK01234567)
- Send signtext ID to target signee system
- Target system uses their API client with “Workflow: API client organization signature, read” privilege to fetch metadata, digests, document for signature
- Target system uses their API client with “Workflow: API client organization signature, sign” privilege to create system signature
Demo
The demo utilizes the system signature on create mechanics, which allows for insight into the look-and-feel on the generated PAdES documents and the relevant signer claims for such signatures.
Support
If you are interested in this feature, reach out to Signaturgruppen for more information and ways to utilize, integrate and test the system signature functionality.