sproof Sign: Choosing the Right Strategy (API)

Hello developer,

The seamless integration of electronic signatures into your existing software landscape is a decisive step in digitizing your processes. The sproof Sign API offers maximum flexibility for this – but with many options the question often arises: Which approach is the most efficient for my scenario?

The choice of the right strategy depends not only on where in the document the signature must be placed or who the acting person is. A often underestimated factor is when:

• When are the recipient data known? Do you know the signer already during PDF generation or only at the time of sending?

• When is the layout finalized? Is the document static or is it generated dynamically?

Do you want to bake the logic directly into the PDF, program coordinates, or achieve maximum flexibility by separating document and process?

This module serves as a decision aid for your API architecture. We present the four common integration patterns with which you can control signature positions and recipient logic. Based on your requirements for flexibility, document structure (static vs. dynamic) and compliance, you will find the appropriate approach here.

We distinguish four main strategies:

1. The programmatic approach: Full control over coordinates (X/Y) in code.

2. The embedded logic approach: The document controls the process through smart placeholders.

3. The combined approach (workflow): Separation of layout (document) and process logic (sproof Sign Dashboard).

4. The manual approach: A human finalizes the draft before sending.

Let’s examine the methods in detail so you can make the best choice for your system.

1. Signature position in the request body (API payload)

"The programmatic approach"

You define the exact position (X/Y coordinates and page number) directly in the JSON body of the API request when sending the document.

• How it works: The coordinates are either fixed in the code or are calculated.

• Best use: Static documents (e.g., standardized forms) where the layout is rigid and never changes.

• Advantage: The PDF document does not need to be modified; it remains "clean".

• Disadvantage: Prone to errors when the layout changes.

🔗 API documentation: POST /documents/signature

📘 Further reading:

• sproof Sign: Collecting signatures API

• sproof Fastlane: Collecting signatures API

2. Signature position via "smart" text placeholders

"The embedded logic approach"

You embed recipient data and the position directly as a specific text string in the document. sproof Sign scans the PDF, reads this string, automatically creates the recipient and replaces the text with the signature field.

• How it works: A string in a defined syntax is placed in the PDF. When calling the API (Create Signature Request) the flag usePlaceholders must be set to true.

• Syntax: {sproof{first_name, last_name, email_address, signing_order, [optional] doNotSendEmail}sproof}

• Example: {sproof{Max, Mustermann, max@beispiel.at, 1}sproof}

• Special feature: The document itself brings the "intelligence" for routing. The text is often formatted white (invisible). When such a document is opened in the sproof Sign interface, the recipients are already shown in a dialog and can be invited with one click.

• Best use: Dynamic documents from third-party systems (CRM/ERP) where recipient logic should be anchored directly in the generated PDF.

🔗 API documentation:

• Text Placeholders Overview

• POST /documents/signature

3. Signature position via workflow placeholders

"The combined approach"

With this procedure you use a strict division of labor: the position of the signature is marked in the document, while the settings of the invitation process and the recipients (e.g., signature level or signing order) are managed centrally in the workflow.

• How it works:

  • Position (in the document): The definition of where to sign is done exclusively in the PDF itself. You place a unique text string there (text anchor, e.g. {{signer1}}). The workflow in the dashboard has no information about the position.

  • Rules (in the workflow): In the sproof Dashboard you define only the logical "person placeholders" with their settings (e.g., "Must sign qualified", "Is second in order"). These placeholders are assigned an index (e.g., 1).

  • Linking (via API): When sending you "merge" these two worlds. You send the recipient (email) and tell the API: "Take the position from text anchor {{signer1}} and apply the rules from workflow index 1."

• Strategic advantage: You separate the visual layout from the compliance logic. If the layout of your contract changes and the text anchor shifts, you do not have to touch the workflow – the signature moves automatically with it. At the same time you can centrally change the signature standard (e.g., from FES to QES) in the workflow without having to edit thousands of PDF templates or your API code.

• Best use: For processes where documents are created dynamically (variable positions) but must always follow the same strict compliance requirements (static rules).

🔗 API documentation:

• POST /invite-recipients-with-workflow

• POST /invite-recipients-with-workflow-envelope

📘 Further reading: sproof Sign Requesting signatures including Workflow API

4. Signature position by the user (draft mode)

"The manual approach"

The document is uploaded and prepared via the API, but not sent immediately.

• How it works: The document appears in the user's sproof Sign dashboard as a draft. The user can be directed to the editor via an editorUrl to make final adjustments and manually place or check the signature fields by drag & drop.

• Best use: Individual cases or complex documents where automatic placement is too risky and a human review (four-eyes principle) should take place before sending.

🔗 API documentation: POST /documents/prepare

📘 Further reading: sproof Sign Preparing signature requests API

Last updated: August 18, 2026