Workflow automation / Power Automate
Generate a PDF from Power Automate
Microsoft's cloud flow automation, which sits closest to SharePoint, OneDrive, Outlook and Dataverse and is usually chosen because the documents have to land in one of them.
Making the request
The HTTP action, which takes a method, a URI, headers and a body. Note that this is the generic HTTP action rather than a connector for a specific service, and it is the one that carries a licensing condition.
What it does with the response
Good, and better than most on this list. The response body of a binary content type is available directly from the action's output and can be passed as file content to a downstream action without any conversion. Where the body has been through an intermediate step that stringified it, such as a Parse JSON or a Compose, base64ToBinary converts it back. The rule of thumb is that if the bytes go straight from the HTTP action into a file action they need no handling at all, and every conversion function you find yourself reaching for is a sign that something in between turned them into a string.
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.
- SharePoint or OneDrive, through Create file, with the HTTP body as the file content
- an Outlook email as an attachment, through Send an email V2
- Dataverse, as a file or image column on a record
- Teams, as a message with a file, which posts into the underlying SharePoint library
The limit that bites in production
The generic HTTP action is a premium connector and needs a licence that includes premium connectors. Flows built on a standard licence will fail on it, and that is a procurement conversation rather than a technical one, so it is worth confirming before the flow is designed rather than after.
The shape that works
Post the HTML, take the binary body straight out of the HTTP action, and hand it to Create file. Do not put a Parse JSON between them: it turns the body into a string and creates the conversion problem you then have to undo.
{
"HTTP": {
"type": "Http",
"inputs": {
"method": "POST",
"uri": "https://api.pdfpipe.xyz/v1/pdf",
"headers": {
"Authorization": "Bearer @{parameters('PdfPipeKey')}",
"Content-Type": "application/json"
},
"body": {
"html": "@{variables('InvoiceHtml')}",
"options": { "format": "A4", "margin": "16mm" }
}
}
},
"Create_file": {
"type": "OpenApiConnection",
"inputs": {
"parameters": {
"folderPath": "/Invoices/2026",
"name": "@{concat(variables('InvoiceNumber'), '.pdf')}",
"body": "@body('HTTP')"
}
},
"runAfter": { "HTTP": ["Succeeded"] }
}
}The mistake people make
Putting a Parse JSON action after the HTTP call out of habit. The response is a PDF, not JSON. Parse JSON either fails or coerces the body into a string, and you then spend an afternoon on base64 conversion functions to recover bytes that were already correct two actions earlier.
Frequently asked
Can Power Automate handle the PDF bytes directly?
Good, and better than most on this list. The response body of a binary content type is available directly from the action's output and can be passed as file content to a downstream action without any conversion. Where the body has been through an intermediate step that stringified it, such as a Parse JSON or a Compose, base64ToBinary converts it back. The rule of thumb is that if the bytes go straight from the HTTP action into a file action they need no handling at all, and every conversion function you find yourself reaching for is a sign that something in between turned them into a string.
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.
Generate a PDF from Pipedream
A workflow platform where the steps are real Node.js or Python, so anything the language can do the workflow can do.
Generate a PDF from Retool
An internal tool builder where the UI is assembled from components and the data comes from queries, which makes a file an awkward shape to pass around.
Generate a PDF and attach it in Airtable
A database with a spreadsheet interface, where attachments are a first-class field type and are set in a way that surprises people.
Every automation platform covered
Grouped by what kind of platform it is, with the three that have their own guide linked out.
Storing generated PDFs and fetching them later
The capability several of these integrations are built on, with the retention that applies.
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.