DEV Community: TommyDev

How to Generate PDF Invoices in PHP (Yii2 / Laravel) via REST API

TommyDev — Thu, 06 Aug 2026 12:43:38 +0000

Generating PDF invoices in PHP using traditional libraries like mPDF or Dompdf often leads to heavy server memory consumption, broken CSS layouts, and maintenance headaches.

By offloading the rendering engine to QuartzAPI, your PHP application only needs to perform a fast, lightweight HTTP POST request with a JSON payload containing the invoice data.

Prerequisites

PHP 7.4+ or 8.x
A QuartzAPI account and API Key
An active Template ID created in the QuartzAPI Visual Builder (e.g., tpl_invoice_v1)

Step 1: Prepare Your JSON Payload Data

Whether you are fetching invoice data from Eloquent (Laravel) or Active Record (Yii2), structure your data as a clean associative array matching your template placeholders.

$invoiceData = [
    'template_id' => 'tpl_invoice_v1',
    'data' => [
        'invoice_number' => 'INV-2026-0042',
        'date' => date('Y-m-d'),
        'customer' => [
            'name' => 'Acme Corporation',
            'vat' => 'US123456789',
            'email' => 'billing@acme.com'
        ],
        'items' => [
            ['description' => 'Web Development Services', 'quantity' => 10, 'price' => 85.00, 'total' => 850.00],
            ['description' => 'Cloud Hosting (Annual)', 'quantity' => 1, 'price' => 240.00, 'total' => 240.00]
        ],
        'subtotal' => 1090.00,
        'tax' => 239.80,
        'grand_total' => 1329.80
    ]
];

Step 2: Implementation in Laravel

In Laravel, use the built-in HTTP Client (Illuminate\Support\Facades\Http) to send the payload and handle the binary response.

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Http;

class InvoiceController extends Controller
{
    public function downloadPdf($invoiceId)
    {
        $payload = [
            'template_id' => 'tpl_invoice_v1',
            'data' => [
                'invoice_number' => 'INV-2026-0042',
                'grand_total' => 1329.80
            ]];

        $response = Http::withHeaders([
            'Authorization' => 'Bearer ' . config('services.quartzapi.key'),
            'Content-Type'  => 'application/json',
        ])->post('https://api.quartzapi.com/v1/render', $payload);

        if ($response->failed()) {
            return back()->with('error', 'Failed to generate PDF invoice.');
        }

        return response($response->body(), 200, [
            'Content-Type' => 'application/pdf',
            'Content-Disposition' => 'attachment; filename="Invoice-2026-0042.pdf"',
        ]);
    }
}

Step 3: Implementation in Yii2

In Yii2, you can use the yii\httpclient\Client component or standard cURL inside a Controller action.

namespace app\controllers;

use Yii;
use yii\web\Controller;
use yii\httpclient\Client;

class InvoiceController extends Controller
{
    public function actionDownloadPdf($id)
    {
        $payload = [
            'template_id' => 'tpl_invoice_v1',
            'data' => [
                'invoice_number' => 'INV-2026-0042',
                'grand_total' => 1329.80
            ]
        ];

        $client = new Client();
        $response = $client->createRequest()
            ->setMethod('POST')
            ->setUrl('https://api.quartzapi.com/v1/render')
            ->addHeaders([
                'Authorization' => 'Bearer ' . Yii::$app->params['quartzApiKey'],
                'Content-Type' => 'application/json',
            ])
            ->setContent(json_encode($payload))
            ->send();

        if (!$response->isOk) {
            throw new \yii\web\ServerErrorHttpException('PDF rendering service unavailable.');
        }

        return Yii::$app->response->sendContentAsFile(
            $response->content,
            'Invoice-2026-0042.pdf',
            ['mimeType' => 'application/pdf', 'inline' => true]
        );
    }
}

Key Benefits over mPDF / Dompdf

Zero RAM overhead: Server memory stays constant regardless of document size.
No CSS workarounds: Layout is maintained in the visual drag-and-drop editor.
Instant updates: Change design elements without pushing code changes or running deployments.

How do you currently manage PDF layout updates in your PHP projects? Let's discuss in the comments below!

Why PDF Generation in HTML is Painful (And How to Fix It with Visual Templates & REST APIs)

TommyDev — Thu, 06 Aug 2026 07:01:23 +0000

If you’ve ever had to build a dynamic PDF report in PHP, Node, or Python, you probably know the exact moment the nightmare begins.

It usually starts like this: "We just need a simple invoice/report PDF."

So you install a library like mPDF, wkhtmltopdf, or Dompdf. You write clean HTML and modern CSS, hit render... and everything breaks:

Flexbox and Grid aren't supported.
Page breaks split tables mid-row.
Custom fonts fail to render.
Memory usage spikes every time two users request a document simultaneously.

After spending 8 hours tweaking inline CSS and table borders, you end up with code that feels fragile and hard to maintain.

The Problem with "HTML-to-PDF" Libraries

Most legacy HTML-to-PDF converters rely on outdated browser rendering engines (often stripped-down forks from 10+ years ago).

When you build complex document structures — like multi-page financial statements, dynamic invoices with varying line items, or clean visual charts — you run into three main roadblocks:

Broken Layouts: Modern CSS specs simply don't translate correctly to print/PDF view.
Server Overhead: Rendering PDFs on your application server steals RAM and CPU cycles away from your core API logic.
Endless Code Revisions: Every time marketing or accounting wants to change a logo, color, or table header, a developer has to modify code, re-test, and deploy.

A Better Approach: Separate Design from Data

What if your backend didn't have to care about fonts, CSS, or page boundaries at all?

What if your code only did what it does best — passing JSON data — while the layout lived safely in a visual builder designed specifically for print media?

That’s the exact workflow we designed with QuartzAPI.

Here is how the architecture looks:

[ Your Backend / DB ] ---> ( Sends JSON Payload ) ---> [ QuartzAPI ] ---> ( Returns PDF / Image )

Step 1: Design the Template Visually

Instead of fighting CSS in code, you build your document template in a drag-and-drop editor.

Drag in dynamic text, tables, QR codes, images, and headers.
Bind elements to variable names (e.g., {{invoice.number}}, {{customer.name}}).
Set page break rules and repeating table headers with a single click.

Because the editor is built strictly for document layouts, what you see in the builder is exactly what gets rendered in the PDF.

Step 2: Render via a Simple REST API Call

Once your template is saved, generating a PDF from your application is just a single HTTP POST request.

Here is an example using cURL:

curl -X POST "https://api.quartzapi.com/v1/render" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"template_id": "tpl_invoice_2026",
"data": {
"invoice_number": "INV-2026-001",
"client_name": "Acme Corp",
"items": [
{ "description": "API Integration", "price": 450.00 },
{ "description": "Cloud Hosting Setup", "price": 150.00 }
],
"total": 600.00
}
}'

Or in JavaScript (Node.js / Fetch):

const response = await fetch('https://api.quartzapi.com/v1/render', {
method: 'POST',
headers: {
'Authorization': 'Bearer YOUR_API_KEY',
'Content-Type': 'application/json'
},
body: JSON.stringify({
template_id: 'tpl_invoice_2026',
data: {
invoice_number: 'INV-2026-001',
client_name: 'Acme Corp',
items: [
{ description: 'API Integration', price: 450.00 }
]
}
})
});

const pdfBuffer = await response.arrayBuffer();

Your server stays lightweight, you save server resources, and you never have to debug mPDF line height bugs again.

Key Benefits of Using a Dedicated Document API

Zero Layout Code in Backend: Your controllers remain clean and focused on business logic.
Instant Design Updates: Non-developers (or developers wanting to save time) can update the document layout in the visual builder without requiring a new software release.
Consistent Output: Built-in handling for page numbers, dynamic table pagination, and high-resolution rendering.

How do you handle PDF generation?

I’m curious to know how other developers in the community tackle this:

Are you still using libraries like mPDF, PDFKit, or Puppeteer?
Have you moved to headless Chrome or external APIs?

Let’s discuss in the comments below! If you'd like to test the visual builder workflow, feel free to check out QuartzAPI.

Stop Coding PDF Layouts: How to Build Clean Templates Visually

TommyDev — Thu, 23 Jul 2026 15:21:41 +0000

If you've ever had to build dynamic PDF documents—invoices, shipping labels, compliance reports, or receipts—you know the pain.

Usually, developers end up down one of two painful paths:

Pixel-pushing in code: Using low-level PDF libraries (like PDFKit, FPDF, or TCPDF) where adding a simple border or moving an image 10px down means tweaking coordinate arrays and re-running backend code 50 times.
HTML-to-PDF nightmares: Using headless browsers (Puppeteer, WKHTMLTOPDF) that consume gigabytes of RAM on your server and break pagination the moment a table spans across two pages.

There is a much cleaner architectural approach: separating the document design from your application logic.

The Core Concept: Visual Design + JSON Payload

When building web applications, you wouldn't mix your CSS directly into your database queries. So why mix PDF visual design into your backend controllers?

By decoupling the template design from the rendering execution, your workflow transforms into two simple steps:

Design visually: Create and tweak headers, dynamic tables, page numbers, logos, and conditional visibility in a visual drag-and-drop editor.
Trigger via REST API: Send a clean JSON payload with your dynamic data to an API endpoint that handles the heavy rendering lifting.

How the QuartzAPI Visual Builder Solves This

This design-first methodology is the core engine behind QuartzAPI.

Instead of writing lines of boilerplate code to handle page breaks, repeating table headers, or dynamic text wrapping, the QuartzAPI Visual Builder lets you construct document templates visually directly in the browser:

Drag-and-Drop Components: Place text boxes, images, dynamic data fields, and barcodes exactly where you need them.
Smart Tables: Define repeating rows for line items that automatically handle multi-page overflow and header repetition cleanly.
Dynamic Binding: Bind visual fields directly to your JSON schema variables using simple syntax.
Live Preview: Test how your template renders with real sample JSON payloads before sending a single HTTP request from your app.

What the Code Actually Looks Like

Once your template is saved in the builder, generating a complex, multi-page PDF from your backend (Node.js, PHP, Python, C#, etc.) becomes as simple as sending a standard POST request.

Here is an example payload:

{
"template_id": "tpl_invoice_v2",
"data": {
"invoice_number": "INV-2026-089",
"customer": {
"name": "Acme Corp",
"vat": "US123456789"
},
"items": [
{ "description": "Cloud API Subscription", "qty": 1, "price": 49.00 },
{ "description": "Custom Integration Support", "qty": 2, "price": 150.00 }
],
"total": 349.00
}
}

Your backend application doesn't care about page dimensions, fonts, or margin calculations. It just supplies the raw data—QuartzAPI handles the rest and returns the generated PDF.

Why Decoupling Matters for Teams

Shifting PDF generation to a visual builder + REST API architecture brings massive benefits:

Zero Server Overhead: Your application server doesn't freeze or run out of memory spawning headless browser processes.
Faster Design Iterations: Need to update the company logo, change a color scheme, or adjust footer legal text? Update the template in the visual builder without redeploying your backend code.
Clean Codebases: Keep your backend clean, focused purely on business logic and data retrieval.

Wrap Up

If your team is still spending expensive engineering hours wrestling with PDF layouts or maintaining bloated legacy reporting servers, it’s time to modernize the stack.

Check out QuartzAPI to try out the visual builder and see how effortless document generation can be.

What tools are you currently using for PDF generation in production? Let's discuss in the comments below!

How to Replace Legacy Reporting Tools with Light REST APIs (And Save Infrastructure Costs)

TommyDev — Sat, 18 Jul 2026 10:13:07 +0000

If you have ever worked on enterprise applications, ERPs, or legacy software, you probably know Crystal Reports. For decades, it was the gold standard for creating invoices, stock sheets, and financial reports. You design a .rpt file on a desktop app, link it via ODBC to your SQL Server or SAP HANA database, and let the runtime generate the PDF.

But as the world moved to modern web architectures, Docker containers, microservices, and multi-tenant SaaS platforms, this approach started to show its age.

Keeping a dedicated Windows Server VM alive just to run a legacy reporting engine—while the rest of your stack runs smoothly on Linux containers—is a major architectural headache and an unnecessary infrastructure cost.

Let’s break down why legacy reporting tools break in the cloud era and how you can replace them with a lightweight JSON-to-PDF REST API architecture.

The 3 Major Bottlenecks of Desktop-Driven Reporting

1. The Windows Server Lock-in

Crystal Reports runtime environments are tightly coupled with Windows. If your modern application is containerized with Docker and deployed on AWS ECS, Azure Kubernetes, or Linux-based cloud VMs, you are forced to spin up and maintain a separate, expensive Windows EC2 instance just for rendering PDFs. This fragments your CI/CD pipelines and jacks up your monthly cloud bill.

2. Direct Database Coupling

Legacy reports pull data by opening their own connections (ODBC/OLEDB) directly to the database to run internal queries or stored procedures. In a modern API-first or multi-tenant system, this is an architectural anti-pattern. It creates security vulnerabilities, bypasses your backend application logic, and leads to database connection exhaustion under heavy reporting loads.

3. Painful Updates and Deployment Cycles

When a customer asks to move a logo or change a tax label on an invoice, a developer has to open the desktop designer, fight with complex Crystal Syntax formulas, save the file, and manually deploy it to the server. There is no concept of version control, automated testing, or continuous delivery for these layouts.

The Modern Alternative: Decoupled Template Engines + Web APIs

The clean way to handle document generation in modern SaaS is to completely decouple the data layer from the presentation layer.

Your backend application (whether written in Node.js, PHP, Python, or .NET) handles the query, aggregates the data, and structures it into a clean, readable JSON payload. It then sends this payload via a quick HTTP POST request to a specialized cloud microservice that handles the heavy rendering work.

Here is how the workflow changes:

Feature	Legacy Desktop Reporting	Modern Cloud Document API
Infrastructure	Dedicated Windows Server, license costs	Serverless / Managed Cloud API
Integration	DB Drivers (ODBC), native runtime dependencies	Simple HTTP REST call (Universal)
Layout Design	Proprietary Desktop Designer	Cloud-based Web Editor (HTML/CSS-based)
Data Flow	Report pulls data directly from DB	Application pushes verified JSON data

From Stored Procedures to Clean JSON: A Practical Example

Instead of maintaining a visual file on a server, you design the template once using a cloud-based editor with standard placeholders (like {{customer.name}}).

When a user clicks "Print Invoice" or an automated job triggers a monthly report, your application database code doesn't need to know anything about margins, page breaks, or font layouts. It just builds a JSON dictionary and sends it out.

Here is how easy it is to generate a document using a simple cURL request:

curl -X POST https://api.quartzapi.com/v1/generate-document \
-H "Authorization: Bearer YOUR_SECRET_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"template_id": "warehouse_stock_report",
"folder_id": "monthly_reports_2026",
"data": {
"warehouse": "Eastern Logistics Hub",
"manager": "Alex Miller",
"date": "2026-07-18",
"items": [
{ "sku": "SKU-001", "name": "Electronic Component A", "stock": 1500 },
{ "sku": "SKU-002", "name": "Shielded Cable 5m", "stock": 420 }
]
}
}'

The cloud engine processes the payload, builds the multi-page PDF (automatically handling table overflow and headers across pages), archives it securely in a cloud folder, and returns a direct download URL. Your main production server experiences zero CPU load during the intensive PDF rendering process.

The Architectural Benefits for Software Houses

Switching to a stateless, API-driven documentation workflow yields immediate benefits:

Zero Infrastructure Overhead: You can instantly decommission your Windows Server VMs. Your cloud stack remains clean, containerized, and strictly Linux-based.
Safer Multi-Tenancy: You can pass tenant-specific configuration, branding assets, and isolated data dynamically inside the JSON payload using the exact same base template.
Faster Time-to-Market: Non-technical team members or support agents can tweak document layouts, update typos, or swap logos inside a web-based dashboard without bothering the backend developers or triggering a software redeploy.

Conclusion

Tools like Crystal Reports did their job wonderfully in the desktop and client-server era. However, modern SaaS environments demand lightweight, decoupled, and stateless tools. Moving your reporting to a REST API structure eliminates infrastructure debt and allows your core application to focus entirely on what it does best: handling business logic.

How are you handling high-volume PDF generation in your current cloud stacks? Let's discuss in the comments below!

Note: If you are looking for a simple way to offload document generation from your servers, I am currently building **QuartzAPI—a cloud-native JSON-to-PDF platform designed specifically to replace heavy legacy reporting systems. We just launched our free public beta. Check out the project and our deeper architectural guides at quartzapi.com.