Skip to main content

​
Migration guide: from pdforge to pdf noodle

Migrating from pdforge to pdf noodle is designed to be smooth and low-risk. This guide explains what is changing, what remains exactly the same, and the minimal steps you can take to align your stack with the new brand and domain without breaking any existing workflows.
 Whether you are a developer, no-code builder, automation enthusiast, or SaaS founder, this article will help you migrate with confidence.

​
1. Introduction

pdf noodle is the new name and brand identity for what used to be pdforge. Under the hood, it is the same platform, the same infrastructure, and the same PDF engine you’re already using in production.
 A quick overview:
  • Your templates, variables, and payloads still work the same way
  • Your API keys, auth, and rate limits remain unchanged
  • Your integrations (n8n, Make, Zapier, Bubble, custom code) continue to run normally
  • All pdforge URLs are redirected to the new domain and will keep working until the end of 2026
This guide explains what is changing at the branding and domain level and gives you a short, practical migration path you can follow at your own pace.

​
2. What’s Changing

Here’s what is actually new with the rebrand.
  • New brand name
    • From pdforge to pdf noodle
  • New domain
    • From pdforge.com to pdfnoodle.com
  • Updated documentation and dashboard UI
    • Logo, colors, and wording now reflect the PDF Noodle brand
    • Navigation and features remain familiar
  • New endpoints (optional but recommended)
    • New base URL under api.pdfnoodle.com
    • Old api.pdforge.com URLs are redirected and remain valid until end of 2026
Nothing in your payload structure, Handlebars variables, or template conventions changes with this rebrand.

​
3. What’s Not Changing

Under the hood, pdf noodle is the same engine you already trust. The rebrand does not affect:
  • API behavior
    • Same endpoints, same request/response shape, same error codes
  • Template schemas
    • Your Handlebars variables like {{customer_name}}, {{{html_block}}}, loops, conditions, and visibility logic stay exactly the same
  • Auth tokens and API keys
    • No need to regenerate keys or rotate credentials
  • PDF generation engine
    • Same reliability, performance, and rendering behavior
  • Integrations
    • n8n, Make, Zapier, Bubble, custom scripts keep working as they are
  • Existing pdforge URLs
    • All existing endpoints and dashboard URLs under pdforge.com will keep working until the end of 2026
You can migrate gradually, on your own timeline, without risking downtime or breaking existing PDF flows.
You don’t need to do everything at once. The recommended approach is:
  1. Update your API base URLs
    • Switch from api.pdforge.com to api.pdfnoodle.com in your code and integrations
  2. Test via Debug Mode
    • Use Debug Mode (where available) to inspect rendered HTML, variables, and template schemas when testing the new domain
  3. Update environment variables
    • Centralize your base URL and keep it configurable (for staging, production, etc.)
  4. Update webhooks and callback URLs (optional but recommended)
    • If you have callbacks pointing to pdforge.com, update them to pdfnoodle.com for long-term consistency
  5. Validate template rendering
    • Trigger example runs in staging or sandbox environments
    • Make sure variables are being sent and resolved correctly
  6. Roll out to production
    • Once validated, deploy your changes and monitor as usual

​
5. Update Your API URLs

The most important technical change is the base URL. Paths and behavior remain identical. Old base URL: 
https://api.pdforge.com
New base URL: 
https://api.pdfnoodle.com
What stays the same:
  • All endpoint paths remain the same
  • No changes to request bodies or response formats
  • No changes to auth headers or token usage
  • api.pdforge.com will remain active until the end of 2026
Example: if you previously used: 
curl --location 'https://api.pdforge.com/v1/pdf/sync' \
--header 'Authorization: Bearer pdforge_api_123456789' \
--header 'Content-Type: application/json' \
--data '{
    "templateId": "check",
    "data":{
            "currentDDate": "01/12/2025",
            "user": {
                    "name":"John Doe",
                    "email": "[email protected]"
            },
            "details": [{"score":"100", "description":"high score"}]
    }
}
'
You can safely update to: 
curl --location 'https://api.pdfnoodle.com/v1/pdf/sync' \
--header 'Authorization: Bearer pdforge_api_123456789' \
--header 'Content-Type: application/json' \
--data '{
    "templateId": "check",
    "data":{
            "currentDDate": "01/12/2025",
            "user": {
                    "name":"John Doe",
                    "email": "[email protected]"
            },
            "details": [{"score":"100", "description":"high score"}]
    }
}
'
The Handlebars variables convention (e.g. {{customer_name}}, {{{html_block}}}) remains exactly the same inside your templates.

​
6. Environment Variables

If you already use environment variables for configuration, migration becomes much easier and safer. A typical setup might look like this: 
PDF_API_URL=https://api.pdforge.com
PDF_API_KEY=your-existing-key
You can update it to: 
PDF_API_URL=https://api.pdfnoodle.com
PDF_API_KEY=your-existing-key
  • No API key changes are required
  • You can switch back to the old URL at any time during testing if needed
  • This pattern keeps your staging and production environments flexible

​
8. n8n • Make.com • Zapier • Bubble Integrations

If you use pdf noodle (formerly pdforge) through no-code or automation platforms, here’s what you need to know.

​
n8n

  • The current pdforge node / package will continue to work as is
  • The underlying API will keep working through redirects until end of 2026
  • At first, we will only change the branding and description to reflect pdf noodle
  • In the future, we plan to release a new, dedicated pdf noodle package
    • When we do that, the older pdforge package will be gradually deprecated
    • You will be informed well in advance and given a clear migration path

​
Make.com

  • Existing custom modules or HTTP integrations that point to api.pdforge.com will continue to work through redirects
  • You can optionally update HTTP modules and custom integrations to use https://api.pdfnoodle.com to align with the new domain

​
Zapier

  • If you use Zapier via webhooks or custom integrations that call api.pdforge.com, no immediate change is required
  • You can update the URLs to api.pdfnoodle.com when convenient for consistency

​
Bubble and Other API Connectors

  • If you use Bubble’s API Connector (or similar tools) with https://api.pdforge.com as the base URL:
    • Update the base URL to https://api.pdfnoodle.com
    • No changes are required to the request structure or JSON payload

Overall, all existing integrations keep working. The main change is branding and base URL alignment, which you can adopt progressively.

​
9. Frequently Asked Questions

​
Do I need a new API key?

No. Your existing API keys remain valid and continue to work for both pdforge.com and pdfnoodle.com domains.

​
Are my templates affected?

No. All your templates, Handlebars variables, visibility rules, and margins continue to work exactly as they did before.

​
Do redirects affect speed?

Redirects add a minimal overhead, but for most use cases this is negligible. For optimal performance and future-proofing, we recommend updating to https://api.pdfnoodle.com when convenient.

​
Will pdforge URLs stop working immediately?

No. All pdforge URLs are expected to remain functional through the end of 2026 via permanent 301 redirects. You have plenty of time to migrate gradually.

​
Do I need to update my plan or billing?

No. Your plan, pricing, and billing setup remain exactly the same. This is a brand and domain change only, not a pricing or product reset.
If you have any questions about migration or run into any issues, feel free to reach out: 📩 [email protected]
 We’re here to help you switch over smoothly and keep your PDFs running flawlessly.