Skip to content
  • Documentation
    • Mobile App – Signatus
    • Web App – Signatus 2 API
    • Web App – OKdokument API
    • Web App – OKdokument
  • Contact Us

Introduction to Signatus 2 API

  • Introduction to Signatus 2 API Integration

Core API Services - Signatus 2

  • Overview and conventions
  • Authorization
  • Create envelope
  • Delete envelope
  • Download envelope
  • Envelope list
  • Envelope info
  • Process info
  • Envelope info complete
  • Counters
  • Envelope & process completion callback
  • Rules
  • Document fields configuration
  • Integration Resources & API Documentation

Use Cases - Signatus 2

  • Example 1: Simple one-round signing
  • Example 2: Simple two-round signing
  • Example 3: Advanced two-round signing
  • Example 4: Advanced approving
View Categories
  • Home
  • Documentation
  • Web App - Signatus 2 API
  • Core API Services - Signatus 2
  • Overview and conventions

Overview and conventions

0:00 / 1:38
  • View as Markdown Open this page as plain Markdown (opens in a new tab)
  • Open in ChatGPT Ask questions about this page (opens in a new tab)
  • Open in Claude Ask questions about this page (opens in a new tab)
  • Open in Google AI Studio Ask questions about this page (Google account required) (opens in a new tab)

Signatus 2 API provides services for creating document envelopes, defining one or more signing or approval processes, retrieving workflow status, downloading completed data, and deleting envelopes. An envelope is the top-level container. Each item in processes[] represents a signing or approval round executed by a technical signer identifier.

Request conventions #

  • All secured API requests use the HTTP Authorization header with the Bearer scheme.
  • Create operations use multipart/form-data.
  • Envelope metadata is sent either in the multipart text field dataText or as the multipart file field data.
  • Uploaded PDF parts are linked to process documents through processes[].documents[].reference. The reference must match the multipart field name.
  • If referenceBase64 is used, the document content is supplied through the top-level base64 object instead of a multipart file part.
  • Epoch timestamps are expressed in milliseconds since 1970-01-01T00:00:00Z.

Naming conventions used in this document #

{{oauthUrl}}   OAuth server base URL
{{baseUrl}} Signatus application base URL
{{accessToken}} OAuth access token
{{envelopeId}} Envelope UUID
{{processId}}Process UUID

Envelope model and workflow concepts #

4.1 Envelope #

The envelope contains metadata, rules, one or more processes, and the documents associated with those processes. It also supports extension, product and contact data for integrator-specific metadata.

4.2 Process #

A process represents one signing or approval round. A multi-round workflow is represented by multiple objects in processes[]. Each process has a signer technical identifier, a signature type, optional extension data, and a list of documents.

4.3 Signer identifier versus signer name #

ConceptExamplePurpose
Technical signer identifiersigner1Stored in processes[].signer and used in scoped rule names.
Signer display nameJán NovákProvided through guiSignerName.signer1 when a predefined signer name is required.
Signer emailjan.novak@example.comProvided through emailTo.signer1 for a process-specific signing invitation.
Signer phone+421900123456Provided through openOtpPhone.signer1 or signOtpPhone.signer1 when applicable.
Updated on 13/10/2026
Integration Resources & API DocumentationAuthorization
Table of Contents
  • Request conventions
  • Naming conventions used in this document
  • Envelope model and workflow concepts
  • 4.1 Envelope
  • 4.2 Process
  • 4.3 Signer identifier versus signer name
  • Documentation
    • Mobile App – Signatus
    • Web App – Signatus 2 API
    • Web App – OKdokument API
    • Web App – OKdokument
  • Contact Us
Proudly powered by WordPress