PDFPipe

App builders / Bubble

Generate a PDF from Bubble

A visual application builder with its own database and workflow engine, where an external call is configured in the API Connector rather than written.

Making the request

The API Connector, where a call is defined once with its URL, headers and body, and then used as an action in a workflow. Body parameters can be marked dynamic so a workflow supplies them at run time.

What it does with the response

The API Connector can be told that a call returns a file rather than data. When it is, Bubble saves the response into its own file storage and gives you a URL to it, which can then be written to a field on a record. That is convenient and it is also the source of this platform's one significant gotcha, which is what happens to that URL afterwards.

Where the document can go afterwards

This is the part that differs most between platforms, and it is usually the reason one platform was chosen over another in the first place.

  • a file field on a database record, as the stored URL
  • an email, by referencing the stored file in a send-email action
  • a download link in the interface, which is just the URL
  • an external service, through a second API Connector call that passes the URL

The limit that bites in production

Two things. Workflow actions consume workload units, so a render inside a loop over a list is a cost that scales with the list rather than a fixed one. And files saved by Bubble get a URL that is reachable by anyone who has it unless file privacy is deliberately applied.

The shape that works

Define the call as returning a file, save the URL to the record it belongs to, and then immediately think about who can reach that URL. For an invoice or a payslip, apply privacy rules to the file rather than relying on the URL being hard to guess.

json
// API Connector call definition. Set the return type to File so
// Bubble stores the response and hands back a URL.
{
  "name": "Render invoice",
  "method": "POST",
  "url": "https://api.pdfpipe.xyz/v1/pdf",
  "headers": {
    "Authorization": "Bearer <PDFPIPE_KEY>",
    "Content-Type": "application/json"
  },
  "body": {
    "html": "<invoice_html>",
    "options": { "format": "A4", "margin": "16mm" }
  },
  "dataType": "File"
}

// In the workflow: "Render invoice", then "Make changes to a thing"
// setting the invoice's file field to the returned file.
// Then, and this is the step people skip, set the file's privacy so
// it is not readable by anyone holding the URL.

The mistake people make

Saving a generated invoice or payslip to a file field and shipping it. Bubble's file URLs are not secret by default, and a URL that reaches a customer by email is a URL that can be forwarded, logged by a mail gateway and indexed if it ever appears on a page. Apply file privacy rules for anything containing personal or financial data, and treat the default as unsuitable for those documents rather than as a starting point.

Frequently asked

Can Bubble handle the PDF bytes directly?

The API Connector can be told that a call returns a file rather than data. When it is, Bubble saves the response into its own file storage and gives you a URL to it, which can then be written to a field on a record. That is convenient and it is also the source of this platform's one significant gotcha, which is what happens to that URL afterwards.

Should I store the document or pass the bytes through?

It depends on what the platform does with a large value. On a platform that serialises everything passing between steps, pushing several megabytes through the workflow is slow and sometimes capped, so storing the document and passing a URL is better. On a platform that hands you a file object natively, passing it straight to its destination is simpler and avoids a second fetch. The page above says which of those this platform is.

Where does the API key live?

In the platform's own secret or environment storage, never in a step body where it is visible in an execution log. Every platform on this list has somewhere to put it, and the execution logs of an automation platform are seen by more people than a codebase is.

Other platforms

Platforms of the same kind, and one from each of the other kinds.

100 free documents a month, and a playground that runs a real render without a key, which is the fastest way to get an HTML sample worth wiring up.