DEV Community: Zero Lopp Labs

SWIFT Is Killing MT940 — Here's How to Future-Proof Your Bank Statement Pipeline

Zero Lopp Labs — Mon, 23 Mar 2026 17:06:11 +0000

On November 22, 2025, SWIFT pulled the plug on legacy MT payment messages. Cross-border payments now run exclusively on ISO 20022's MX format.

MT940 — the bank account statement format your reconciliation pipeline probably depends on — wasn't part of that first wave. It's a reporting message, not a payment message. But it's next. SWIFT has formally deprecated MT940, stopped maintaining it, and announced that disincentives for continued usage are coming.

If your application parses bank statements, you need a migration plan. Here's what's actually happening, what the formats look like under the hood, and how to build a pipeline that handles both.

What MT940 Actually Looks Like

Before we talk about replacing MT940, let's look at what we're replacing. Here's a real MT940 statement:

:20:STMT2603230001
:25:NL91ABNA0417164300
:28C:15/1
:60F:C260322EUR1234,56
:61:2603220322D45,00NTRFNONREF//ACME-INV-2026-042
:86:999~00SEPA OVERBOEKING~20KENMERK: ACME-INV-2026-042
~21Acme Corp Ltd~22PAYMENT FOR SERVICES~23March 2026
~30DEUTDEDB~31DE89370400440532013000~32Acme Corp Ltd
~33Frankfurt
:62F:C260322EUR1189,56

If you've never parsed this, here's a field-by-field breakdown:

Tag	Name	What's in it
`:20:`	Transaction Reference	Message identifier (max 16 chars)
`:25:`	Account ID	Your IBAN or account number (max 35 chars)
`:28C:`	Statement Number	Sequence number (`15/1` = statement 15, page 1)
`:60F:`	Opening Balance	`C` = Credit, `260322` = 22 Mar 2026, `EUR`, `1234,56`
`:61:`	Statement Line	Date + D/C + amount + type code + reference (max 80 chars)
`:86:`	Information	Free-text transaction details (up to 6 lines × 65 chars)
`:62F:`	Closing Balance	Same format as opening balance

The :86: field is where the real pain lives. Banks cram debtor names, payment references, creditor IBANs, and remittance information into a single text block. There is no universal standard for how this data is structured.

The ~ delimiters you see above? That's one bank's convention (common in SEPA countries). Other banks use / prefixes, ? codes, or just dump everything as plain text. You end up writing bank-specific regex patterns to extract structured data — and they break every time the bank changes their layout.

What CAMT.053 Looks Like Instead

Here's the same transaction in CAMT.053:

<Ntry>
  <Amt Ccy="EUR">45.00</Amt>
  <CdtDbtInd>DBIT</CdtDbtInd>
  <BkgDt><Dt>2026-03-22</Dt></BkgDt>
  <VlDt><Dt>2026-03-22</Dt></VlDt>
  <AcctSvcrRef>ACME-INV-2026-042</AcctSvcrRef>
  <NtryDtls>
    <TxDtls>
      <Refs>
        <EndToEndId>ACME-INV-2026-042</EndToEndId>
      </Refs>
      <RltdPties>
        <Cdtr>
          <Nm>Acme Corp Ltd</Nm>
          <PstlAdr>
            <TwnNm>Frankfurt</TwnNm>
          </PstlAdr>
        </Cdtr>
        <CdtrAcct>
          <Id><IBAN>DE89370400440532013000</IBAN></Id>
        </CdtrAcct>
      </RltdPties>
      <RltdAgts>
        <CdtrAgt>
          <FinInstnId>
            <BIC>DEUTDEDB</BIC>
          </FinInstnId>
        </CdtrAgt>
      </RltdAgts>
      <RmtInf>
        <Ustrd>PAYMENT FOR SERVICES March 2026</Ustrd>
      </RmtInf>
    </TxDtls>
  </NtryDtls>
</Ntry>

No regex. No bank-specific parsing rules. The creditor name is in <Cdtr><Nm>. The IBAN is in <CdtrAcct><Id><IBAN>. The BIC is in <CdtrAgt><FinInstnId><BIC>. The remittance info has its own dedicated <RmtInf> element — with support for both unstructured text and structured sub-fields.

The full CAMT.053 document wraps everything in a clear hierarchy:

Document
  └─ BkToCstmrStmt (Bank-to-Customer Statement)
      ├─ GrpHdr       → Message ID, creation timestamp
      └─ Stmt         → One per account
          ├─ Acct      → IBAN, BIC, account name
          ├─ Bal[]     → OPBD, CLBD, CLAV, FWAV (all timestamped)
          └─ Ntry[]    → One per transaction
              └─ NtryDtls
                  └─ TxDtls → Refs, parties, agents, remittance

Here's the technical comparison side-by-side:

Feature	MT940	CAMT.053
Format	Proprietary text (SWIFT FIN)	XML (ISO 20022, XSD-validated)
Transaction details	Packed into `:61:` (80 chars) + `:86:` (6×65 chars)	Dedicated elements: `Refs`, `RltdPties`, `RltdAgts`, `RmtInf`
Remittance info	Crammed into `:86:`, bank-specific delimiters	Structured `<RmtInf>` with `<Strd>` sub-fields, unlimited length
Balance types	Opening (`:60F:`) and Closing (`:62F:`) only	OPBD, CLBD, CLAV, PRCD, FWAV — all with timestamps
Currency	Single currency per statement	Multi-currency with exchange rate details per transaction
Character set	SWIFT X charset (A-Z, 0-9, basic punctuation — no accents)	Full UTF-8 / Unicode
Date format	`YYMMDD` (ambiguous century)	ISO 8601: `YYYY-MM-DD`
Validation	Manual — hope the parser handles edge cases	XSD schema validation built-in

The Migration Timeline — What's Actually Happening

There's a lot of confusion around "SWIFT is killing MT940" because the migration is happening in waves. Here's the accurate picture:

What already happened (November 22, 2025):
SWIFT ended the MT/ISO 20022 coexistence period for payment messages. MT103 (credit transfers) and MT202 (institution transfers) are formally retired. All cross-border payments now use ISO 20022 MX format exclusively via the FINplus service.

What's happening now (2026):
MT940 and other reporting messages are deprecated and no longer maintained by SWIFT — but they haven't been withdrawn yet. J.P. Morgan's ISO 20022 FAQ puts it clearly: "Reporting and statement messages will not be immediately withdrawn from the FIN service. Although these message types are deprecated and no longer maintained by SWIFT, disincentives for their use will be introduced at a later date."

Banks are transitioning on their own timelines. J.P. Morgan has been accepting CAMT.052/053/054 since Q4 2024. Bank of America completed its Fedwire ISO 20022 implementation in July 2025. 44% of banks are behind schedule on their November 2026 milestones.

What's coming (2027+):
SWIFT's roadmap targets full MT message retirement, including enquiry and investigation messages (MT199/MT299 → camt.110/camt.111) by November 2027. The reporting messages (MT940 → CAMT.053) will follow.

The bottom line: MT940 still works today, but no one is maintaining or improving it. New features, new validation rules, new regulatory requirements — all of that goes into CAMT.053. Building on MT940 now is building on a dead-end.

Your Options as a Developer

Option 1: Build It Yourself

There are open-source libraries for individual formats:

mt940-rs (Rust) — MT940 parser
pycamt / camt_parser (Python) — CAMT.053 parsers
ofxstatement (Python) — OFX converter
Cmxl (Ruby) — MT940 parser with extensible design

The problem: you need multiple libraries plus glue code to normalize outputs into a common model. You need to handle bank-specific :86: field variations, character encoding edge cases (MT940's SWIFT X charset vs. UTF-8), date format conversions (YYMMDD → YYYY-MM-DD), and amount parsing (comma vs. dot decimal separators).

For a single-format, single-bank integration, this works. For anything multi-bank or multi-format, you're signing up for ongoing maintenance as banks change their implementations.

Option 2: Enterprise Aggregators

Plaid (12,000+ institutions), Finicity (Mastercard), and Wise offer bank data APIs. But they solve a different problem — they connect to live bank accounts via OAuth. If you already have statement files (SFTP drops, email attachments, file exports), these platforms are overkill. They're also expensive and come with heavy onboarding.

Option 3: A Dedicated Conversion API

This is the gap. You have files in format A, you need them in format B. No bank connections, no OAuth flows, no aggregation. Just conversion — stateless, fast, spec-compliant.

That's what we're building.

Introducing FinConvert

FinConvert is a REST API that converts bank statement files between financial formats. One endpoint, any supported format in, any supported format out.

The core architecture uses a Universal Transaction Model: every input format is parsed and normalized into a single internal representation, then serialized to the requested output format. This means adding new formats requires N+M adapters, not N×M conversion paths.

Currently supported:

Direction	Formats
Input	MT940, CAMT.053 (OFX, BAI2, QIF coming soon)
Output	CAMT.053, CSV, JSON, OFX (MT940 output coming soon)

Design principles:

Privacy-first — No files are stored. Conversion is stateless. Your financial data is processed in memory and discarded.
Spec-compliant — Output is validated against official SWIFT and ISO 20022 XSD schemas.
Fast — Sub-200ms average conversion time. Pure computation, no I/O bottleneck.
London-hosted — EU data residency for compliance-conscious teams.

Show Me the Code

Convert an MT940 file to structured JSON:

curl:

curl -X POST https://api.finconvert.dev/v1/convert \
  -H "Authorization: Bearer fc_your_api_key" \
  -F "file=@statement.mt940" \
  -F "output_format=json" \
  -o converted.json

TypeScript:

async function convertStatement(file: File): Promise<ConvertedStatement> {
  const formData = new FormData();
  formData.append("file", file);
  formData.append("output_format", "json");

  const response = await fetch("https://api.finconvert.dev/v1/convert", {
    method: "POST",
    headers: {
      Authorization: "Bearer fc_your_api_key",
    },
    body: formData,
  });

  if (!response.ok) {
    throw new Error(`Conversion failed: ${response.status}`);
  }

  return response.json();
}

What you get back — structured, typed, no regex required:

{
  "statement": {
    "account": "NL91ABNA0417164300",
    "currency": "EUR",
    "opening_balance": 1234.56,
    "closing_balance": 1189.56,
    "statement_number": "15/1",
    "date": "2026-03-22"
  },
  "transactions": [
    {
      "date": "2026-03-22",
      "amount": -45.00,
      "currency": "EUR",
      "type": "DEBIT",
      "reference": "ACME-INV-2026-042",
      "description": "PAYMENT FOR SERVICES March 2026",
      "creditor": {
        "name": "Acme Corp Ltd",
        "iban": "DE89370400440532013000",
        "bic": "DEUTDEDB"
      }
    }
  ],
  "transaction_count": 1,
  "format_source": "MT940",
  "format_output": "JSON"
}

That MT940 :86: field with bank-specific ~ delimiters? Parsed into clean, typed JSON. The creditor IBAN that was buried in ~31? Extracted into creditor.iban. No bank-specific logic on your end.

Pricing

Usage-based — you pay for what you convert:

Plan	Price	Conversions/month
Free	$0	100
Pro	$49/mo	5,000
Business	$149/mo	50,000
Enterprise	Custom	Custom

The free tier is enough for testing and low-volume integrations. No credit card required.

What's Next

FinConvert is currently in early access. We're onboarding developers from the waitlist and expanding format support based on demand.

On the roadmap:

OFX, BAI2, and QIF input support
MT940 output (for systems that still require it during the transition)
Auto-format detection — upload any file, we figure out what it is
Batch conversion endpoint for bulk processing
Bank-specific :86: field profiles for higher extraction accuracy

If you're building anything that touches bank statement data — accounting software, reconciliation tools, fintech integrations, ERP connectors — the MT940 deprecation is real. It still works today, but the writing is on the wall: SWIFT has stopped maintaining it, banks are migrating, and every new feature goes into CAMT.053.

Join the waitlist at finconvert.dev to get early access and lock in free-tier usage during beta.

Built by Zero Loop Labs — the same team behind SealTrail (tamper-proof audit trails) and PDFForge (document generation API).

How to Generate PDFs from FileMaker Data Using Python

Zero Lopp Labs — Mon, 23 Mar 2026 10:48:23 +0000

You already use python-fmrest to pull data from FileMaker. Now what?

Maybe you're exporting records for a report. Maybe you're building invoices at month-end. Maybe you just need to turn FileMaker data into something you can email to a client without sending them a .fmp12 file.

This tutorial shows you how to build a clean pipeline: python-fmrest to fetch your FileMaker data, PDFForge to turn it into professional PDFs. No wkhtmltopdf. No Puppeteer. No LaTeX. Just Python, JSON, and an API call.

What you'll need

Python 3.6+ (python-fmrest requirement)
A FileMaker Server with the Data API enabled (FileMaker Server 17+ or Claris FileMaker Server)
A PDFForge account — free tier gives you 25 documents/month, no credit card required
A PDF or DOCX template uploaded to your PDFForge dashboard

Install the dependencies:

pip install python-fmrest requests

Step 1: Connect to FileMaker with python-fmrest

If you've used python-fmrest before, this is familiar. If not — it's a clean Python wrapper around the FileMaker Data API that handles authentication, sessions, and response parsing for you.

import fmrest

# Connect to your FileMaker Server
fms = fmrest.Server(
    url="https://your-filemaker-server.com",
    user="api_user",
    password="your_password",
    database="Invoicing",
    layout="Invoices",
    api_version="v1",
    verify_ssl=True
)

# Log in — python-fmrest handles the token for you
fms.login()

A few things worth noting:

api_version="v1" works for FileMaker Server 17-19. For FileMaker Server 2023+, use "vLatest".
verify_ssl=True is the default and you should keep it. If you're hitting self-signed certs in development, pass verify_ssl=False temporarily — but fix that before production.
The session token is managed automatically. python-fmrest requests a token on login() and includes it in subsequent requests. It also handles token expiry.

Step 2: Fetch the records you need

Let's say you want to generate invoices for all unpaid orders. python-fmrest's find() method maps directly to the FileMaker Data API's find endpoint:

# Find all unpaid invoices
find_query = [{"Status": "Unpaid"}]
unpaid_invoices = fms.find(query=find_query)

print(f"Found {len(unpaid_invoices)} unpaid invoices")

The result is an iterable of Record objects. Each record gives you attribute-style access to your FileMaker fields:

for invoice in unpaid_invoices:
    print(f"Invoice #{invoice.InvoiceNumber} — {invoice.CustomerName} — ${invoice.Total}")

Getting related records (line items)

For invoices, you typically need data from a related table — line items, for example. python-fmrest supports portals:

# Get a specific invoice with portal data
# Make sure your layout includes a portal to InvoiceLines
record = fms.get_record(42, portals=[{"name": "InvoiceLines"}])

# Access portal records — python-fmrest stores portals as record attributes
# with a "portal_" prefix: record.portal_<PortalName>
# Convert to list since Foundset is a lazy iterator
line_items = list(record.portal_InvoiceLines)
for line in line_items:
    print(f"  {line['InvoiceLines::Description']} — qty {line['InvoiceLines::Quantity']}")

Portal field names follow FileMaker's convention: TableOccurrence::FieldName.

Step 3: Generate a PDF with PDFForge

Now the interesting part. You have your FileMaker data in Python objects. Let's turn it into a PDF.

PDFForge works with templates — you upload a PDF form, a DOCX file with placeholders, or an HTML template to your dashboard, and then fill it with data via the API. For this tutorial, we'll use a DOCX invoice template.

Upload a template (one-time setup)

In your PDFForge dashboard, upload a DOCX file with {placeholder} tags:

INVOICE #{invoice_number}
Date: {date}
Due: {due_date}

Bill to:
{customer_name}
{customer_address}

{items_table}

Subtotal: {subtotal}
VAT ({tax_rate}%): {tax_amount}
Total: {total} {currency}

After uploading, you'll get a template_id (like tpl_abc123). Save that — you'll need it in the code.

Make the API call

import requests

PDFFORGE_API_KEY = "pk_live_your_api_key_here"  # Use env vars in production
TEMPLATE_ID = "tpl_your_template_id"

def generate_invoice_pdf(invoice, line_items):
    """Generate a PDF from a FileMaker invoice record."""

    # Build the data payload from the FileMaker record
    payload = {
        "template_id": TEMPLATE_ID,
        "data": {
            "invoice_number": str(invoice.InvoiceNumber),
            "date": str(invoice.InvoiceDate),
            "due_date": str(invoice.DueDate),
            "customer_name": invoice.CustomerName,
            "customer_address": invoice.CustomerAddress,
            "items": [
                {
                    "description": item["InvoiceLines::Description"],
                    "quantity": item["InvoiceLines::Quantity"],
                    "unit_price": item["InvoiceLines::UnitPrice"],
                    "amount": item["InvoiceLines::LineTotal"]
                }
                for item in line_items
            ],
            "subtotal": invoice.Subtotal,
            "tax_rate": invoice.TaxRate,
            "tax_amount": invoice.TaxAmount,
            "total": invoice.GrandTotal,
            "currency": invoice.Currency
        }
    }

    # Call PDFForge API
    response = requests.post(
        "https://api.pdfforge.dev/v1/documents/fill",
        headers={
            "Authorization": f"Bearer {PDFFORGE_API_KEY}",
            "Content-Type": "application/json"
        },
        json=payload,
        timeout=30
    )
    response.raise_for_status()

    result = response.json()
    return result

The response includes a download_url where you can fetch the generated document:

result = generate_invoice_pdf(invoice, line_items)

# Download the PDF
pdf_response = requests.get(result["download_url"])
with open(f"Invoice_{invoice.InvoiceNumber}.pdf", "wb") as f:
    f.write(pdf_response.content)

print(f"Saved Invoice_{invoice.InvoiceNumber}.pdf")

Step 4: Put it all together

Here's the complete pipeline — connect, fetch, generate, save:

import fmrest
import requests
import os

# -- Configuration --
FM_SERVER = "https://your-filemaker-server.com"
FM_USER = "api_user"
FM_PASSWORD = os.environ["FM_PASSWORD"]  # Never hardcode passwords
FM_DATABASE = "Invoicing"

PDFFORGE_API_KEY = os.environ["PDFFORGE_API_KEY"]
TEMPLATE_ID = "tpl_your_template_id"
OUTPUT_DIR = "./invoices"

def main():
    # Connect to FileMaker
    fms = fmrest.Server(
        url=FM_SERVER,
        user=FM_USER,
        password=FM_PASSWORD,
        database=FM_DATABASE,
        layout="InvoicesWithPortal",
        api_version="v1"
    )
    fms.login()

    # Find unpaid invoices
    unpaid = fms.find(query=[{"Status": "Unpaid"}])
    print(f"Found {len(unpaid)} unpaid invoices")

    os.makedirs(OUTPUT_DIR, exist_ok=True)
    generated = 0
    errors = 0

    for invoice in unpaid:
        try:
            # Get portal data for line items
            record = fms.get_record(
                invoice.record_id,
                portals=[{"name": "InvoiceLines"}]
            )
            line_items = list(record.portal_InvoiceLines)

            if not line_items:
                print(f"  Skipping Invoice #{invoice.InvoiceNumber} — no line items")
                continue

            # Generate PDF
            result = generate_invoice_pdf(record, line_items)

            # Download and save
            pdf_response = requests.get(result["download_url"])
            filepath = os.path.join(OUTPUT_DIR, f"Invoice_{invoice.InvoiceNumber}.pdf")
            with open(filepath, "wb") as f:
                f.write(pdf_response.content)

            print(f"  Generated: {filepath}")
            generated += 1

        except requests.exceptions.HTTPError as e:
            print(f"  ERROR Invoice #{invoice.InvoiceNumber}: {e}")
            errors += 1
        except Exception as e:
            print(f"  ERROR Invoice #{invoice.InvoiceNumber}: {e}")
            errors += 1

    # Clean up FileMaker session
    fms.logout()

    print(f"\nDone. Generated: {generated}, Errors: {errors}")


def generate_invoice_pdf(invoice, line_items):
    """Generate a PDF from a FileMaker invoice record."""
    payload = {
        "template_id": TEMPLATE_ID,
        "data": {
            "invoice_number": str(invoice.InvoiceNumber),
            "date": str(invoice.InvoiceDate),
            "due_date": str(invoice.DueDate),
            "customer_name": invoice.CustomerName,
            "customer_address": invoice.CustomerAddress,
            "items": [
                {
                    "description": item["InvoiceLines::Description"],
                    "quantity": item["InvoiceLines::Quantity"],
                    "unit_price": item["InvoiceLines::UnitPrice"],
                    "amount": item["InvoiceLines::LineTotal"]
                }
                for item in line_items
            ],
            "subtotal": invoice.Subtotal,
            "tax_rate": invoice.TaxRate,
            "tax_amount": invoice.TaxAmount,
            "total": invoice.GrandTotal,
            "currency": invoice.Currency
        }
    }

    response = requests.post(
        "https://api.pdfforge.dev/v1/documents/fill",
        headers={
            "Authorization": f"Bearer {PDFFORGE_API_KEY}",
            "Content-Type": "application/json"
        },
        json=payload,
        timeout=30
    )
    response.raise_for_status()
    return response.json()


if __name__ == "__main__":
    main()

Run it:

export FM_PASSWORD="your_fm_password"
export PDFFORGE_API_KEY="pk_live_your_api_key"
python generate_invoices.py

Found 12 unpaid invoices
  Generated: ./invoices/Invoice_2026-0031.pdf
  Generated: ./invoices/Invoice_2026-0032.pdf
  Skipping Invoice #2026-0033 — no line items
  Generated: ./invoices/Invoice_2026-0034.pdf
  ...
Done. Generated: 11, Errors: 0

Beyond invoices: other template types

The same pattern works for any document type. Only the template and data shape change.

HTML templates (for complex layouts)

If your documents need advanced formatting — tables that span pages, conditional sections, dynamic charts — use an HTML template with Handlebars syntax. Upload it via the API or dashboard, then call /v1/documents/generate instead of /fill:

# For HTML templates, use the /generate endpoint
response = requests.post(
    "https://api.pdfforge.dev/v1/documents/generate",
    headers={
        "Authorization": f"Bearer {PDFFORGE_API_KEY}",
        "Content-Type": "application/json"
    },
    json={
        "template_id": "tpl_html_report_template",
        "data": {
            "title": "Monthly Sales Report",
            "period": "March 2026",
            "records": [
                {"product": record.ProductName, "revenue": record.Revenue}
                for record in sales_records
            ]
        }
    },
    timeout=30
)

PDF form filling

Got existing PDF forms with AcroForm fields? Upload the PDF, and PDFForge maps your JSON keys to the form field names:

# Fill a PDF form — same /fill endpoint, different template
response = requests.post(
    "https://api.pdfforge.dev/v1/documents/fill",
    headers={
        "Authorization": f"Bearer {PDFFORGE_API_KEY}",
        "Content-Type": "application/json"
    },
    json={
        "template_id": "tpl_application_form",
        "data": {
            "applicant_name": record.FullName,
            "date_of_birth": str(record.DOB),
            "address": record.Address,
            "signature_date": "2026-03-23"
        }
    },
    timeout=30
)

What this costs

python-fmrest is open source and free.

PDFForge has a free tier at 25 documents/month — enough to build and test your pipeline. If you need more:

Plan	Price	Documents/month
Free	$0	25
Starter	$29/mo	500
Pro	$79/mo	2,500
Business	$199/mo	10,000

For a typical FileMaker solution generating monthly invoices, the free tier or Starter plan covers most scenarios. Compare that to per-seat plugin licenses that can run $200+ per developer.

Current pricing is always at pdfforge.dev.

The honest trade-offs

No tool is perfect. Here's what you should consider:

Network dependency. Every PDF generation requires an API call. If your environment has no internet access, this approach won't work.
Latency. An API call adds 1-3 seconds per document compared to local generation. For batch jobs running overnight, this doesn't matter. For real-time, click-and-wait UX, it's noticeable.
Data leaves your server. Your document data is sent to PDFForge's servers for rendering. PDFForge retains documents temporarily (7 days on free tier) then deletes them. If your data is highly sensitive, review their security practices or consider whether this fits your compliance requirements.
FileMaker Data API limits. The Data API has its own rate limits and concurrent session caps. If you're processing thousands of records, you may need to batch your find() calls.

Next steps

Install the dependencies: pip install python-fmrest requests
Test your FileMaker connection with a simple find() call
Sign up at pdfforge.dev and upload a template
Start with one document type — get it working end-to-end before expanding
Use environment variables for all credentials (never hardcode API keys or passwords)

The pipeline is simple by design: fetch data, shape it as JSON, send it to an API, get back a document. Once you have this pattern, you can extend it to any document your FileMaker solution needs — contracts, reports, shipping labels, compliance forms.

If you're already using python-fmrest, you're one pip install requests away from professional PDF generation.

PDFForge is a REST API for document generation. python-fmrest is an open-source Python wrapper for the FileMaker Data API by David Hamann.

How to Generate PDFs from FileMaker with a REST API

Zero Lopp Labs — Sun, 22 Mar 2026 17:02:44 +0000

FileMaker's built-in PDF generation works — until it doesn't.

You build a layout. You use "Save Records as PDF." It looks fine on your machine. Then a client opens the same file on Windows and the fonts are wrong, the margins shifted, and that carefully aligned logo is now floating somewhere in the header wilderness.

Sound familiar? Let's fix it.

The problem with FileMaker's native PDF generation

FileMaker's "Save Records as PDF" script step is layout-based. That means your PDF output is a screenshot of a layout, not a document built from structured data. This creates a cascade of problems:

Layout dependency. Every PDF format requires its own layout. Need an invoice, a quote, and a packing slip? That's three layouts to maintain, each with pixel-perfect alignment that breaks when you change a field.

Cross-platform inconsistency. FileMaker renders layouts differently on Mac vs. Windows vs. Server. Font substitution, line height differences, and margin calculations vary between platforms. What looks perfect on your MacBook might be a mess on a client's Windows server running a scheduled script.

No batch processing. Want to generate 200 invoices at once? You'll need a loop script that navigates to each record, switches to the right layout, saves the PDF, and moves on. It's slow, fragile, and ties up the FileMaker client while running.

Limited formatting. Conditional formatting exists, but try building a multi-page document with dynamic tables, page breaks at logical points, and different headers per section. You'll spend more time fighting the layout engine than building your solution.

Server-side limitations. FileMaker Server can run "Save Records as PDF," but only with layouts that use server-compatible fonts. Get a font wrong and you get blank pages — with no useful error message.

The API approach: send JSON, get PDF

What if PDF generation worked like this instead?

Your FileMaker script collects the data (customer name, line items, totals — whatever you need)
It sends that data as JSON to an API endpoint
It gets back a ready-to-use PDF file

No layouts to maintain. No platform inconsistencies. The same JSON payload produces the exact same PDF whether you send it from Mac, Windows, FileMaker Server, or a scheduled script.

This is what a REST API for PDF generation does. The template lives on the API side. Your FileMaker solution just provides the data.

Native PDF vs Plugin vs REST API

Before we dive into the tutorial, here's an honest comparison of the three main approaches:

	Native "Save as PDF"	FileMaker Plugin	REST API (PDFForge)
Setup	Built-in, zero setup	Install plugin on every client + server	API key, no install
Template control	Layout-based	Varies by plugin	HTML/CSS or DOCX templates
Cross-platform	Inconsistent rendering	Plugin must support each OS	Identical output everywhere
Batch generation	Loop script, slow	Depends on plugin	Parallel API calls
Server compatibility	Font limitations	Plugin must be server-compatible	No server-side install needed
Cost	Free (included)	$50-500+ license per seat	Free tier, then usage-based
Maintenance	Layouts break with schema changes	Plugin updates, version locks	API versioned, no client updates
Network dependency	None	None	Requires internet connection
Learning curve	Familiar	Plugin-specific API	Standard REST/JSON

The honest trade-off: The API approach adds a network dependency. If your FileMaker solution runs in an environment with no internet access, this won't work. For everything else — which is most modern deployments — the flexibility and consistency gains are significant.

Step-by-step: calling PDFForge from a FileMaker script

Let's build a complete FileMaker script that generates a PDF invoice. We'll use PDFForge, a REST API designed specifically for document generation.

Prerequisites

A PDFForge account (free tier available at pdfforge.dev)
Your API key (found in your dashboard after signup)
FileMaker Pro 16+ or Claris Pro (for Insert from URL with cURL options)

Step 1: Store your API key

Create a table called AppSettings (if you don't have one already) with a field for PDFForge_API_Key. Store your API key there. Never hardcode API keys in scripts.

// In your AppSettings table:
PDFForge_API_Key = "your_api_key_here"

Step 2: Build the JSON payload

FileMaker's JSONSetElement function is your best friend here. Create a script called "Generate Invoice PDF" and start building the payload:

# ============================================
# Script: Generate Invoice PDF
# Purpose: Collect invoice data, call PDFForge API, save PDF
# ============================================

# -- Step 1: Build the JSON payload from current record --

Set Variable [ $json ; Value: "{}" ]

# Company details
Set Variable [ $json ; Value:
  JSONSetElement ( $json ;
    [ "template_id" ; "tpl_YOUR_TEMPLATE_ID" ; JSONString ] ;
        [ "data.company.name" ; AppSettings::CompanyName ; JSONString ] ;
    [ "data.company.address" ; AppSettings::CompanyAddress ; JSONString ] ;
    [ "data.company.email" ; AppSettings::CompanyEmail ; JSONString ] ;
    [ "data.company.phone" ; AppSettings::CompanyPhone ; JSONString ] ;
    [ "data.company.logo_url" ; AppSettings::LogoURL ; JSONString ]
  )
]

# Customer details
Set Variable [ $json ; Value:
  JSONSetElement ( $json ;
    [ "data.customer.name" ; Invoices::CustomerName ; JSONString ] ;
    [ "data.customer.address" ; Invoices::CustomerAddress ; JSONString ] ;
    [ "data.customer.email" ; Invoices::CustomerEmail ; JSONString ]
  )
]

# Invoice metadata
Set Variable [ $json ; Value:
  JSONSetElement ( $json ;
    [ "data.invoice.number" ; Invoices::InvoiceNumber ; JSONString ] ;
    [ "data.invoice.date" ; GetAsText ( Invoices::InvoiceDate ) ; JSONString ] ;
    [ "data.invoice.due_date" ; GetAsText ( Invoices::DueDate ) ; JSONString ] ;
    [ "data.invoice.currency" ; Invoices::Currency ; JSONString ]
  )
]

Step 3: Add line items from a related table

Line items need to be built as a JSON array. Here's how to loop through a portal or related records:

# -- Step 2: Build line items array --

Set Variable [ $items ; Value: "[]" ]
Set Variable [ $i ; Value: 0 ]

Go to Related Record [ From table: "InvoiceLines" ; Using layout: "InvoiceLines" ]

Loop
  Set Variable [ $item ; Value:
    JSONSetElement ( "{}" ;
      [ "description" ; InvoiceLines::Description ; JSONString ] ;
      [ "quantity" ; InvoiceLines::Quantity ; JSONNumber ] ;
      [ "unit_price" ; InvoiceLines::UnitPrice ; JSONNumber ] ;
      [ "amount" ; InvoiceLines::LineTotal ; JSONNumber ]
    )
  ]

  Set Variable [ $items ; Value:
    JSONSetElement ( $items ; $i ; $item ; JSONObject )
  ]

  Set Variable [ $i ; Value: $i + 1 ]

  Go to Record/Request/Page [ Next ; Exit after last ]
End Loop

# Navigate back to invoice layout
Go to Layout [ "Invoices" ; Animation: None ]

# Add line items and totals to payload
Set Variable [ $json ; Value:
  JSONSetElement ( $json ;
    [ "data.items" ; $items ; JSONArray ] ;
    [ "data.totals.subtotal" ; Invoices::Subtotal ; JSONNumber ] ;
    [ "data.totals.tax_rate" ; Invoices::TaxRate ; JSONNumber ] ;
    [ "data.totals.tax_amount" ; Invoices::TaxAmount ; JSONNumber ] ;
    [ "data.totals.total" ; Invoices::GrandTotal ; JSONNumber ]
  )
]

Step 4: Call the API with Insert from URL

Now the actual API call. FileMaker's Insert from URL script step supports cURL options, which gives you full control over the HTTP request:

# -- Step 3: Call PDFForge API --

Set Variable [ $api_key ; Value: AppSettings::PDFForge_API_Key ]

Set Variable [ $curl_options ; Value:
  "--request POST" &
  " --header \"Content-Type: application/json\"" &
  " --header \"Authorization: Bearer pk_live_" & $api_key & "\"" &
  " --data @$json"
]

Set Variable [ $url ; Value: "https://api.pdfforge.dev/v1/documents/generate" ]

Insert from URL [ Select ; With dialog: Off ;
  Target: $pdf_result ;
  URL: $url ;
  cURL options: $curl_options
]

Step 5: Handle the response

The API returns a JSON response containing a download_url. You'll need to parse the JSON, then fetch the PDF from that URL:

# -- Step 4: Handle the response --

Set Variable [ $http_code ; Value: Get ( LastExternalErrorDetail ) ]

If [ $http_code = 0 ]

  # Parse the JSON response to get the download URL
  Set Variable [ $download_url ; Value:
    JSONGetElement ( $pdf_result ; "download_url" )
  ]
  Set Variable [ $doc_id ; Value:
    JSONGetElement ( $pdf_result ; "id" )
  ]

  # Download the actual PDF file
  Insert from URL [ Select ; With dialog: Off ;
    Target: $pdf_binary ;
    URL: $download_url
  ]

  # Save PDF to container field
  Set Field [ Invoices::PDF_Document ; $pdf_binary ]

  # Optionally export to disk
  Set Variable [ $filename ; Value:
    "Invoice_" & Invoices::InvoiceNumber & ".pdf"
  ]
  Set Variable [ $filepath ; Value:
    Get ( DocumentsPath ) & $filename
  ]
  Export Field Contents [ Invoices::PDF_Document ; "$filepath" ]

  Show Custom Dialog [ "Success" ;
    "PDF generated: " & $filename
  ]

Else

  # Error handling
  Show Custom Dialog [ "Error" ;
    "PDF generation failed. HTTP status: " & $http_code &
    "¶Response: " & $pdf_result
  ]

End If

The complete cURL equivalent

If you want to test outside FileMaker first (or you're integrating from another platform), here's the equivalent cURL command:

curl -X POST https://api.pdfforge.dev/v1/documents/generate \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer pk_live_YOUR_API_KEY" \
  -d '{
    "template_id": "tpl_YOUR_TEMPLATE_ID",
    "data": {
      "company": {
        "name": "Acme Corp",
        "address": "123 Business Street, London EC1A 1BB",
        "email": "billing@acme.example.com"
      },
      "customer": {
        "name": "Jane Smith",
        "address": "456 Client Road, Manchester M1 1AA",
        "email": "jane@example.com"
      },
      "invoice": {
        "number": "INV-2026-0042",
        "date": "2026-03-22",
        "due_date": "2026-04-21",
        "currency": "GBP"
      },
      "items": [
        {
          "description": "FileMaker Development - Phase 1",
          "quantity": 40,
          "unit_price": 95.00,
          "amount": 3800.00
        },
        {
          "description": "PDF Template Design",
          "quantity": 1,
          "unit_price": 500.00,
          "amount": 500.00
        }
      ],
      "totals": {
        "subtotal": 4300.00,
        "tax_rate": 20,
        "tax_amount": 860.00,
        "total": 5160.00
      }
    }
  }' \
  }' | jq .

The API returns a JSON response with a download_url — fetch that URL to get the actual PDF file:

# Download the generated PDF
curl -o invoice.pdf "$(curl -s -X POST https://api.pdfforge.dev/v1/documents/fill \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer pk_live_YOUR_API_KEY" \
  -d '...' | jq -r '.download_url')"

Same data, same template, same result, every time.

Error handling and resilience

Production scripts need more than a happy path. Here are the patterns that matter:

Timeout handling

FileMaker's Insert from URL has a default timeout. For large documents, set it explicitly:

Set Variable [ $curl_options ; Value:
  $curl_options & " --max-time 30"
]

Retry logic

Network requests can fail transiently. A simple retry loop helps:

Set Variable [ $max_retries ; Value: 3 ]
Set Variable [ $attempt ; Value: 1 ]

Loop
  Insert from URL [ Select ; With dialog: Off ;
    Target: $pdf_result ;
    URL: $url ;
    cURL options: $curl_options
  ]

  Exit Loop If [ Get ( LastExternalErrorDetail ) = 0 or $attempt >= $max_retries ]

  Set Variable [ $attempt ; Value: $attempt + 1 ]

  # Brief pause before retry
  Pause/Resume Script [ Duration (seconds): 2 ]
End Loop

Validate before sending

Don't waste API calls on incomplete data:

# Pre-flight checks
If [ IsEmpty ( Invoices::CustomerName ) or IsEmpty ( Invoices::InvoiceNumber ) ]
  Show Custom Dialog [ "Missing Data" ;
    "Customer name and invoice number are required."
  ]
  Exit Script [ Text Result: "error" ]
End If

Going further

Once you have the basic pattern working, there's a lot more you can do.

Custom templates

PDFForge supports three template types, each uploaded via the dashboard or API (POST /v1/templates):

PDF Forms — AcroForms with fillable fields (text, checkboxes, dropdowns). Use endpoint /v1/documents/fill.
DOCX Files — Word documents with {placeholder} tags, including image support. Use endpoint /v1/documents/fill.
HTML Templates — Handlebars syntax, rendered to PDF via Chromium. Use endpoint /v1/documents/generate.

Your FileMaker solution sends the same JSON structure — only the template_id changes:

# Switch template by changing the template_id
Set Variable [ $json ; Value:
  JSONSetElement ( $json ;
    [ "template_id" ; "tpl_YOUR_OTHER_TEMPLATE" ; JSONString ]
  )
]

DOCX templates

Need to generate editable Word documents? Upload a DOCX template with {placeholder} tags in the dashboard, then call /v1/documents/fill with your data. PDFForge merges the data into the template and returns the filled document. This is useful when clients need to edit documents before sending.

Batch processing

Need to generate 200 invoices at month-end? Instead of looping through layouts, loop through records and make API calls. Each call is independent — no layout switching, no render context to maintain:

# Batch generation script
Go to Record/Request/Page [ First ]

Loop
  Perform Script [ "Generate Invoice PDF" ]
  Go to Record/Request/Page [ Next ; Exit after last ]
End Loop

Because the API is stateless, you could even run multiple FileMaker scripts in parallel (using Perform Script on Server calls) for faster batch processing.

Email delivery

Combine PDF generation with an email API (like Resend or SendGrid) to generate and send invoices in one automated workflow. Your FileMaker script becomes: collect data, generate PDF, attach to email, send. All without a user clicking through layouts.

What this costs

PDFForge has a free tier (25 documents/month, no credit card required) that's enough to test and build your integration. Paid plans start at $29/month with higher document quotas and extended retention. For most FileMaker solutions, that's a fraction of what you'd pay for a per-seat plugin license.

Check current pricing at pdfforge.dev.

Next steps

Sign up at pdfforge.dev and grab your API key
Test with cURL first — paste the command above into your terminal to see the output
Build the FileMaker script — start with the code in this article and adapt it to your schema
Customize a template — upload your own HTML/CSS or DOCX template in the dashboard
Automate — add the script to your existing workflows (record creation, month-end batch, email triggers)

If you hit any issues or want to share what you've built, find us at pdfforge.dev. We're building this for developers who actually ship FileMaker solutions — your feedback shapes the product.

Why your INSERT INTO audit_log proves nothing

Zero Lopp Labs — Fri, 13 Mar 2026 11:11:08 +0000

You've seen this pattern. You might have written it yourself. I know I did.

CREATE TABLE audit_log (
  id         SERIAL PRIMARY KEY,
  user_id    TEXT NOT NULL,
  action     TEXT NOT NULL,
  resource   TEXT,
  metadata   JSONB,
  created_at TIMESTAMPTZ DEFAULT now()
);

Every time something important happens — a user signs a contract, an admin changes permissions, a payment goes through — you INSERT INTO audit_log. Job done. You have an audit trail.

Except you don't.

The problem nobody talks about

That audit_log table sits in the same database as everything else. Anyone with write access can do this:

-- Oops. Never happened.
UPDATE audit_log SET action = 'invoice.viewed' WHERE action = 'invoice.deleted';

-- Or just make it disappear entirely
DELETE FROM audit_log WHERE user_id = 'admin_42' AND action = 'permission.escalated';

No trace. No alert. No way to know it ever happened.

This isn't a theoretical attack. It's the default state of every audit log built on a regular database table. Your DBA can do it. A compromised admin account can do it. A SQL injection exploit can do it. And nobody will ever know.

"But we have backups"

Sure. But backups tell you what the data was, not whether it was tampered with between now and then. If someone edits a row on Monday and you check the backup on Friday, you're comparing against a backup that might already include the edit.

"We use triggers and permissions"

Better. But triggers can be disabled by superusers. ALTER TABLE ... DISABLE TRIGGER ALL is one command. And PostgreSQL SECURITY DEFINER functions can bypass row-level security.

The fundamental issue isn't about access control. It's about provability. Can you prove — cryptographically, not just organizationally — that a log entry hasn't been modified since it was written?

With a regular INSERT? No. You can't.

What auditors actually want

When a compliance auditor asks "show me the audit trail for this transaction," they're not asking for a database dump. They want to know:

Completeness — Are all events present? Can you prove nothing was deleted?
Integrity — Can you prove nothing was modified after the fact?
Ordering — Can you prove the sequence of events hasn't been rearranged?

A plain audit_log table answers none of these questions with certainty.

SOC 2, HIPAA, PCI-DSS Requirement 10, GDPR Article 32 — they all expect or require audit records with demonstrable integrity. "We have a database table" doesn't cut it.

Hash chains: the fix

The solution has existed since the 1990s (Haber & Stornetta, the paper that later inspired Bitcoin's blockchain). The idea is simple:

Each log entry includes a cryptographic hash of itself and the previous entry.

Event 1: hash("payload_1" + GENESIS_HASH)        → hash_1
Event 2: hash("payload_2" + hash_1)               → hash_2
Event 3: hash("payload_3" + hash_2)               → hash_3

Now if someone modifies Event 2, hash_2 changes. But Event 3 was computed using the original hash_2. The chain breaks. The tampering is immediately detectable.

You can't silently edit a single row without invalidating every subsequent hash in the chain.

What this looks like in practice

Here's a concrete example. You're logging invoice events in a SaaS app:

import { SealTrail } from "sealtrail";

const st = new SealTrail({ apiKey: process.env.SEALTRAIL_API_KEY });

// Log an event — hash chain is built automatically
const event = await st.events.log({
  actor: "finance_user_42",
  action: "invoice.approved",
  resource: "inv_12345",
  context: { amount: 5000, currency: "USD" }
});

console.log(event.hash);            // "a1b2c3d4e5f6..."
console.log(event.chain.position);  // 42

Each event gets a SHA-256 hash computed from the canonicalized event payload (actor, action, resource, context), the previous event's hash, and the event timestamp.

The hash and chain position are returned with every event. They're not just metadata — they're cryptographic proof.

Verification: the part that matters

Logging isn't enough. The whole point is that you — or an auditor, or an automated compliance check — can verify that nothing was touched:

const result = await st.events.verify("evt_abc123");

if (result.valid) {
  console.log("Event integrity verified");
  console.log("Chain intact:", result.chainIntact);
} else {
  console.error("TAMPER DETECTED");
  console.error("Expected:", result.computedHash);
  console.error("Got:", result.eventHash);
}

Verification recomputes the hash from scratch. If the stored hash doesn't match the computed one, someone changed the data. If chainIntact is false, someone broke the link between events — meaning an event was inserted, deleted, or reordered.

This isn't trust. It's math.

The DIY trap

At this point you might be thinking: "I can build this myself. SHA-256, a previous_hash column, done."

I thought the same thing. Here's what I ran into:

Concurrent writes. Two events arrive at the same millisecond. Both read the same previous_hash. Both compute their hash against it. You now have a forked chain. Fix: atomic transactions with unique constraints on chain position. Retry on conflict.

Canonical serialization. JSON.stringify({ a: 1, b: 2 }) and JSON.stringify({ b: 2, a: 1 }) produce different strings, therefore different hashes. You need deterministic JSON canonicalization, or your verification breaks when key order varies.

Chain partitioning. One global chain becomes a bottleneck. You need per-resource or per-tenant chains. But then you need to manage chain creation, head tracking, and cross-chain references.

Pagination at scale. Offset-based pagination breaks when events are being inserted. You need cursor-based pagination with stable sort keys.

Retry logic. Rate limits, network failures, concurrent conflicts — your client needs exponential backoff with jitter, and it needs to handle 409 Conflict responses specifically for chain contention.

It's solvable. But it's a week of work to build, and a lifetime of maintenance to keep secure. And if you get the canonicalization wrong, your entire chain is silently invalid.

Stop building underpants

There's a term in engineering for components that every team rebuilds from scratch despite it not being their core business: underpants (as in, everyone needs them, nobody should be hand-stitching them).

Your audit trail is underpants. It needs to work. It needs to be tamper-proof. But it's not what your users are paying you for.

I built SealTrail because I needed this for my own SaaS products and got tired of reimplementing it. It's an API — npm install sealtrail, log events, verify integrity. Hash chains, cursor pagination, isolated chains per resource or tenant, and cryptographic verification are handled for you.

// Your entire audit trail integration
import { SealTrail } from "sealtrail";

const st = new SealTrail({ apiKey: process.env.SEALTRAIL_API_KEY });

// Log (events are chained per chain — default or custom)
await st.events.log({
  actor: userId,
  action: "document.signed",
  resource: documentId,
  context: { ip: request.ip },
  chain: "documents"  // optional — isolates chains per resource type
});

// Verify
const proof = await st.events.verify(eventId);
// proof.valid === true | false

Three lines to log. One line to verify. Hash chain built automatically.

TL;DR

	`INSERT INTO audit_log`	Hash chain audit trail
Can admin silently edit?	Yes	No — hash changes, chain breaks
Can rows be deleted?	Yes	Detectable — position gaps
Can order be changed?	Yes	No — each hash includes previous
Cryptographic proof?	No	SHA-256 chain verification
Compliance-ready?	Questionable	Verifiable record

If your audit log is a regular database table, it proves nothing. It's a convenience log, not an audit trail.

If that's fine for your use case, carry on. But if you're handling financial data, healthcare records, legal documents, or anything where "we can prove this wasn't tampered with" matters — you need hash chains.

I'm Sylvain, solo founder at Zero Loop Labs. I build developer tools. SealTrail is my latest — a tamper-proof audit trail API for developers. Try it free.

How I Built a Document Generation API with Bun, Hono & Playwright

Zero Lopp Labs — Fri, 06 Mar 2026 21:55:52 +0000

Every developer has dealt with PDF generation at some point. Whether it's invoices, contracts, reports, or government forms — the moment a client says "we need this as a PDF," you know you're in for a ride.

I've been through the usual suspects:

Puppeteer with headless Chromium — powerful, but managing memory leaks and container sizing in production is a full-time job
wkhtmltopdf — reliable for years, but unmaintained and stuck with a 2015-era WebKit engine
Low-level libraries like pdfkit or jsPDF — great control, but you're positioning text at pixel coordinates
Expensive SaaS solutions — they work, but pricing per page adds up fast

After re-solving this problem on multiple projects, I decided to build it once and expose it as an API. The result is PDFForge — a REST API that handles three document operations:

HTML to PDF — design templates in HTML/CSS, render to pixel-perfect PDF
Fill PDF forms — send JSON data to fill AcroForm fields
Fill Word documents — .docx templates with placeholder tags

The Stack

Layer	Choice	Why
Runtime	Bun	Fast startup, native crypto & file I/O, built-in test runner
Framework	Hono	Lightweight, middleware-friendly, great TypeScript support
PDF Rendering	Playwright	Chromium-based, reliable CSS rendering
PDF Form Filling	pdf-lib	Pure JS, no native deps, handles AcroForms well
Word Documents	docxtemplater	Mature, handles loops/conditionals/images in .docx
Templating	Handlebars	Simple syntax, custom helpers for formatting
Database	Drizzle + PostgreSQL	Type-safe ORM, great migration story
Storage	S3-compatible (Tigris)	Signed URLs for document delivery
Hosting	Fly.io	Edge deployment, machine suspend for cost control

How It Works

Upload a template

Templates are HTML files with Handlebars syntax. You use variables like clientName, loops with each items, and conditionals. Standard HTML/CSS — no proprietary syntax to learn.

Upload it once via the API or the dashboard.

Generate a document

curl -X POST https://api.pdfforge.dev/v1/documents/generate \

  -H "Authorization: Bearer pk_live_xxx" \

  -H "Content-Type: application/json" \

  -d '{

    "templateId": "tpl_abc123",

    "data": {

      "invoiceNumber": "INV-2026-042",

      "clientName": "Acme Corp",

      "items": [

        {"description": "API Integration", "amount": "$2,500"},

        {"description": "Support Plan", "amount": "$500"}

      ],

      "total": "$3,000"

    }

  }'

Get your PDF

The API returns a signed download URL — no auth needed to download, URL expires automatically based on your plan's retention policy.

Interesting Technical Challenges

Chromium Concurrency

The biggest challenge was managing concurrent Playwright instances. Each PDF render spins up a browser context with Chromium, which is memory-hungry. I built a priority semaphore that queues render jobs based on the user's plan tier — paid users get priority over free tier.

Bun + Playwright in Docker

Playwright's bundled Chromium doesn't play well with Bun in Docker. The fix: install Google Chrome Stable separately and point Playwright to it via PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH. Counterintuitive, but it works reliably.

Signed URLs vs Streaming

I initially considered streaming PDFs directly in the API response. But signed URLs turned out to be better:

Clients can retry failed downloads without re-generating
URLs can be shared (temporarily) with end users
Decouples generation from delivery

Testing with Bun

Bun's test runner is fast, but mock.module() has a gotcha: if two test files mock the same module differently, the first mock wins globally. The solution was mocking at the lib/ level to isolate dependencies properly.

What's Next

PDFForge is currently in public beta with a free tier (50 documents/month). I'm actively looking for feedback from developers who deal with document generation regularly.

If you've ever struggled with PDF generation in your projects, I'd love to hear about your use case — it helps me prioritize what to build next.