Sign PDF Is Not a Digital Signature: What PDF4me's Signing Endpoints Actually Do

Search PDF4me's docs for "digital signature" and you land on a page whose browser tab title reads "Sign PDF - Digital Signature API." Read past the headline and the page tells you the opposite: "This is a visual signature, not a cryptographic digital signature." That is not a typo. It is two different features sharing a search result, and if you build a contract pipeline assuming the REST endpoint gives you legal non-repudiation, you find out the hard way that it does not.

This is worth untangling before you write any integration code, because the fix is simple once you know which tool does which job. It just is not the tool the page title points you toward first.

What POST /api/v2/SignPdf actually does

The REST Sign PDF endpoint takes a PDF and a signature image, then composites the image onto the page you specify. Required fields: docContent (Base64 PDF), docName, imageFile (Base64 signature image), imageName, alignX (Left, Center, Right), alignY (Top, Middle, Bottom). Optional fields cover sizing (widthInMM/heightInMM or the pixel equivalents), margins, opacity, pages, showOnlyInPrint, isBackground, and async processing.

Here is the official Python sample, trimmed to the request itself and verified against the live sample repository:

import base64
import requests

url = "https://api.pdf4me.com/api/v2/SignPdf"

with open("contract.pdf", "rb") as f:
    pdf_base64 = base64.b64encode(f.read()).decode("utf-8")
with open("signature.png", "rb") as f:
    signature_base64 = base64.b64encode(f.read()).decode("utf-8")

payload = {
    "docContent": pdf_base64,
    "docName": "signed-output.pdf",
    "imageFile": signature_base64,
    "imageName": "signature.png",
    "alignX": "Right",
    "alignY": "Bottom",
    "widthInMM": "50",
    "heightInMM": "25",
    "marginXInMM": "20",
    "marginYInMM": "20",
    "opacity": "100",
    "isBackground": False,
    "isAsync": True
}

headers = {
    "Authorization": "Basic YOUR_API_KEY",
    "Content-Type": "application/json"
}

response = requests.post(url, json = payload, headers = headers)

One field name is worth flagging: the REST docs page's own optional-parameters table lists the async flag as async. The official sample script in the repository above sends isAsync instead, and that is the field that actually works against the live API. If you copy the parameter name straight from the docs table, use isAsync, not async.

Call this directly from your own backend in any language, no Acrobat, no browser, no human clicking a signature pad. That part is genuinely true to the pitch. What comes back is a PDF with an image glued to it at the position you specified. There is no certificate, no private key, no cryptographic hash tying the mark to the exact bytes of the document at signing time. Edit the PDF afterward and nothing in the file structure flags that the "signature" now sits on a modified document.

That is a completely legitimate feature to want for internal approval stamps or a cosmetic "reviewed" mark. The problem is only that PDF4me's own page calls it a "Digital Signature API," and that phrase means something specific and different to anyone who has dealt with e-signature compliance before.

What actual cryptographic signing looks like

A cryptographic digital signature binds a private key to the exact contents of a document at signing time, in a way a third party can independently verify and that breaks visibly if the document changes afterward. That is what eIDAS and the ESIGN Act are built around when they talk about tamper-evidence and non-repudiation. PDF4me has this capability, documented consistently across three separate integration pages as certificate-based, X.509 signing with a .pfx or .p12 certificate file and a password protecting its private key.

The parameters look different because the job is different: a Certificate File, a Certificate Password, which page to sign, plus signer metadata (Signer Name, Sign Reason, Sign Location) embedded in the signature itself, and a Visible toggle so the signature can stay cryptographically present while showing no visual mark at all. Digital Sign in Power Automate, Digital Sign PDF in Make, and Digital Sign PDF in Zapier all describe this the same way, down to the same certificate-plus-password input model.

Here is the part that matters if you were planning to call this from your own code the way "not Acrobat" implies: none of the three platforms above expose Digital Sign as a plain REST endpoint. There is no /api/v2/DigitalSignPdf in the API reference; a direct fetch of the URL pattern that would match it returns nothing, and the REST API's own Edit-category sidebar navigation, read directly off the live docs site, lists every signing-adjacent endpoint that exists and Digital Sign is not among them. n8n does not have a Digital Sign action documented at all, only the same visual Sign PDF.

If a no-code connector platform is already part of your stack, this is a non-issue. If your architecture is backend-only by design, the honest options are routing the signing step through Make, Power Automate, or Zapier as one discrete piece of an otherwise custom pipeline, or handling certificate-based signing with your own library and using PDF4me's REST API for everything upstream and downstream of that one step.

Picking the right one before you write any code

The decision comes down to one question: whether this signature needs to survive a legal challenge. If someone could dispute the document was signed, or dispute it was not altered afterward, you need certificate-based signing, not an image overlay. That rules out the REST Sign PDF endpoint regardless of how convenient it is to call directly.

If the signature is cosmetic, an internal sign-off mark, a visual cue in a workflow where the real approval already happened somewhere else, the REST Sign PDF endpoint is the right, lightweight tool, and it genuinely works the way the pitch implies: called from your own backend, no desktop software, no manual step.

Worth testing the visual endpoint interactively before writing integration code, through the Sign PDF API Tester, which, worth noting, is titled "Sign PDF Digitally" on its own page, the same naming pattern repeating a third time. Upload a sample PDF and a signature image, adjust alignment and sizing, and see the actual output before committing to code.

Sign PDF is also documented per platform if you are automating elsewhere in your stack: Sign PDF in Make, Sign PDF in Power Automate, Sign PDF in Zapier, and Sign PDF in n8n all wrap the same visual-signature endpoint described above. If this is your first REST call against PDF4me, start with the connect to the API guide.

The lesson underneath this is not really about signatures. Read the parameter table, not the page title, before building a compliance-sensitive step around a feature name. PDF4me's own documentation makes the distinction clearly once you are two paragraphs into the actual page. The title just does not warn you that you will need to.

Website: pdf4me.com
Documentation: docs.pdf4me.com
Developer portal: dev.pdf4me.com