Sign a document in your provider

Before you start

Put the signature boxes in the template, so every document has them in the same place. The Signatures widget (SignatureBlock) prints a box per signatory with their name and role, bound to a list in your data, and never splits across pages; the Service agreement with phases template has one per party. Publish the template, then create the document from the app or the API as usual.

A document is frozen once made. Sign the version you mean to sign: if the terms change, make a new version first (see when the terms change).

1. Get the PDF

• From the app: open the report and choose Download PDF. The file is named after the report's title.
• From your system: fetch the PDF with your API key once the report is ready (status: "ready", or the report.ready webhook). GET /api/v1/reports/{id}/pdf answers the bytes; pdf_url in the report body is the same file behind the report's access policy.

GET /api/v1/reports/rpt_01ja7c2kd/pdf
Authorization: Bearer pf_live_7f3a…

HTTP/1.1 200 OK
Content-Type: application/pdf
Content-Disposition: attachment; filename="Service agreement SA-2026-014.pdf"

%PDF-1.7 …

2. Send it with your provider

Upload the PDF to your provider, or pass the bytes to its API: most signing providers take a PDF file as the document of a signature request. Add the signers, then place each signer's field over their box. Many providers can place fields by text found in the document, such as the signatory's name printed under the box, which saves placing them by hand for every agreement.

Your provider sends the invitations, collects the signatures, and records its own evidence of who signed and when. Which kind of signature fits your agreement, and what it is worth, is a question for your provider and your own legal adviser.

3. Keep the signed copy

The signed PDF comes back from your provider, not from Pressfox. Keep it where your records are: your document system, your CRM or your own storage. The Pressfox report stays as it was made, unsigned; its page and link keep working for as long as your plan keeps reports.

The signed copy is a new file. The verify page recognises the copy Pressfox issued, not the one your provider returns: to show a document is unchanged, check the issued copy; to show who signed it, your provider's evidence does.

To see at a glance which agreements are signed, add a label to the Pressfox report when your provider tells you it is done. Labels are metadata: they never change the document.

PATCH /api/v1/reports/rpt_01ja7c2kd/labels
Authorization: Bearer pf_live_7f3a…
Content-Type: application/json

{ "labels": { "signature": "signed 2026-10-20" } }

When the terms change

Before signing, a change is a new version: create a correction of the report with the new data and a reason, such as Pilot phase shortened to three months. The old link then points to the new version, and you send the new PDF for signature. After signing, a change to the terms is a new agreement for your provider to send; Pressfox makes its document the same way.

What Pressfox does not do

• Collect signatures, send signing invitations or check who signers are.
• Receive or store the signed copy.
• Give legal advice. The Service agreement with phases template is a starting point to review with your own legal adviser.
• Track dates, renewals or obligations in your agreements: your own system holds them.