Panora

Open-source integration platform, honestly reviewed. The short version: don’t build on this.

TL;DR

• What it was: Open-source (AGPL-3.0) unified API platform — one endpoint to connect dozens of CRM, ATS, HRIS, and accounting tools instead of building each integration separately [1].
• Who it was for: Developers building B2B SaaS products who needed to offer customers native integrations (think: “connect your HubSpot”) without building each connector from scratch.
• Current status: The OSS product has been explicitly sunset. The GitHub README now reads: “The OSS Product was sunset. Visit Panora to see what’s new” [1]. The company pivoted to an entirely different product — AI-powered purchase order automation for distributors and wholesalers [2].
• Key weakness (the only one that matters): Dead. Do not build on this.
• What to use instead: Nango, Airbyte, or Merge.dev depending on your use case.

---

What is Panora

Panora started as a developer-facing open-source platform that solved a specific and genuinely painful problem: B2B SaaS products routinely need to integrate with dozens of CRMs (HubSpot, Salesforce, Pipedrive), HR tools (BambooHR, Workday, Gusto), ATS systems (Greenhouse, Lever), and accounting platforms (QuickBooks, Xero). Building each integration individually means months of maintenance work every time an upstream API changes.

The promise was a unified API layer — one set of endpoints, normalized data schemas, and webhook handling that abstracted away the differences between all these third-party systems. The positioning was direct competition with Merge.dev, which charges several hundred dollars per month for the same concept as a closed SaaS.

The AGPL-3.0 license meant you could self-host the engine for the cost of a VPS, rather than paying Merge’s per-seat SaaS fees [1]. At 1,026 GitHub stars before the sunset, it had traction in the developer community — enough to suggest the concept resonated.

That company no longer exists in this form. The team at Panora made a pivot so sharp it barely shares a product category with the original. The current website at getpanora.com describes an AI assistant that reads purchase order emails and enters them into ERPs for distributors and manufacturers [2]. The FAQ on the new site asks “What is Panora and how does it help my warehouse?” — a question no one running developer infrastructure would ever ask [2].

This is not a soft pivot or a feature expansion. The open-source integration engine is gone.

---

Why people chose it (historical context)

Before the sunset, the case for Panora over alternatives came down to cost and licensing.

Versus Merge.dev. Merge is the market leader in the unified API category. It works well and has deep integration coverage, but pricing is opaque and starts high — typically $650–$1,500+/month for production use depending on connectors and volume. Self-hosting Panora eliminated that bill entirely [1]. Developers who had explored Merge and bounced off the pricing were exactly the audience Panora targeted.

Versus building in-house. Maintaining even five CRM integrations (HubSpot, Salesforce, Pipedrive, Zoho, Copper) is a 6–12 month engineering project that never actually ends because APIs change, rate limits shift, and authentication flows break. Panora’s pitch was to compress that into a single self-hosted deployment [1].

Versus Airbyte. Airbyte is a data pipeline tool, not a real-time API proxy — it’s built for batch ETL, not live read/write integrations in a product flow. Different problem.

The AGPL license was a meaningful differentiator, though also a constraint: AGPL requires open-sourcing your own code if you deploy a modified version over a network. For pure internal use or standard deployment, this is fine. For building a hosted product on top of Panora and keeping your modifications private, AGPL creates legal friction [1].

None of this matters now, but the underlying problem Panora was solving — affordable, self-hosted unified integrations — is still real and still unsolved by open-source tools.

---

Features

This section is primarily historical, since the OSS product is no longer maintained.

What the platform offered [1]:

• Unified API endpoints for CRM, ATS, HRIS, accounting, and ticketing categories
• Normalized data models across providers (one schema for “Contact” regardless of whether it’s HubSpot or Salesforce)
• Managed OAuth flows — the platform handled the auth handshake with third-party services
• Webhook normalization — third-party webhooks got translated into a consistent event format
• Connection management UI — end-users could connect and disconnect their own accounts
• Self-hostable via Docker, AGPL-3.0 licensed

What the current product offers [2]:

• AI email parsing for purchase orders and RFQs
• ERP data entry automation (writing POs into existing ERP systems)
• Item matching against inventory catalogs
• Duplicate detection and part number validation
• A dashboard for reviewing flagged orders

These two products share a company name, a domain redirect, and nothing else technically.

---

Pricing: SaaS vs self-hosted math

For the original OSS product, the economics made sense on paper:

• Software: $0 (AGPL-3.0) [1]
• VPS to run it: $10–20/month
• Your engineering time to maintain it: real cost, hard to quantify

Versus Merge.dev at $650–$1,500+/month: the break-even was obvious if your team had the ops capacity.

For the current PO automation product at getpanora.com, pricing is not published publicly [2]. The website says “Let’s talk” on every CTA — enterprise sales model, pricing on request.

Neither pricing scenario is relevant to developers who found this review looking for a self-hosted integration layer. That product no longer exists to purchase, self-host, or evaluate.

---

Deployment reality check

At launch, Panora deployed via Docker Compose with a PostgreSQL backend — standard setup for a Node.js + TypeScript backend, straightforward for anyone comfortable with containers [1].

The current reality: the repository’s README now redirects visitors away from the OSS codebase [1]. Even if you cloned the last committed version and deployed it, you’d be running unsupported software with no upstream security patches, no bug fixes, and no integration updates when third-party APIs change.

Deploying abandoned open-source software for production use is not a risk trade-off, it’s a liability. HubSpot’s API will change. OAuth token formats will rotate. Webhook schemas will shift. Without active maintenance, the deployment degrades on its own timeline.

Do not self-host the old Panora codebase. The risk profile is the same as deploying any software where the maintainer has explicitly said “this is over.”

---

Pros and cons

Pros (historical)

• Addressed a real and expensive problem. The unified API category is genuinely valuable, and Merge.dev’s pricing leaves a gap that open-source tools should fill [1].
• Clean architecture. AGPL-3.0, Docker-deployable, TypeScript stack — technically sound choices for the problem domain [1].
• Cost story was compelling. $10/month of VPS versus $650+/month of Merge.dev is a meaningful savings for an early-stage B2B SaaS team.

Cons

• Sunset. The definitive con. The OSS product is explicitly discontinued by its own creators [1].
• No alternatives built on top of it. Because it was sunsetted before it matured, there’s no ecosystem of connectors, no community forks with maintained integrations, no migration guides — just a redirect in a README.
• AGPL was restrictive for the primary use case. Building a SaaS on top of an AGPL dependency creates legal exposure. Most companies in this position either needed a commercial license (unavailable) or needed to open-source their own code (undesirable) [1].
• The pivot signals product-market fit failure, not strategic evolution. When a company moves from “developer API infrastructure” to “warehouse PO automation,” it indicates the original market wasn’t working — not that the founders found something bigger and adjacent [2].
• Third-party reviews of the developer product are essentially nonexistent. The lack of coverage suggests adoption didn’t reach the point where users were writing about their experience.

---

Who should use this / who shouldn’t

Don’t use the old Panora OSS if:

• You need something production-stable. You can’t build production infrastructure on sunset software.
• You’re evaluating unified API tools for a B2B SaaS product. Look at Nango or Airbyte depending on the use case.
• You’re a non-technical founder who read “self-hosted Merge.dev” and got excited. That version of the product no longer exists.

Consider the current getpanora.com product if:

• You run a distribution or wholesale business with a team doing manual PO data entry into an ERP.
• You’re spending more than 10 hours per week per employee on PO processing [2].
• You’re comfortable with enterprise sales processes (no self-serve pricing, contact-for-demo model) [2].

These are completely separate audiences. If you’re reading a self-hosted tool review, you’re probably in the first group.

---

Alternatives worth considering

For the original use case — self-hosted or affordable unified API platform for B2B SaaS integrations:

Nango — The closest direct replacement. Open-source, actively maintained, built specifically for the “unified API” problem. OAuth handling, 200+ pre-built integrations, TypeScript SDK. More mature than Panora was at sunset. Self-hostable. Start here.

Airbyte — Strong open-source data pipeline tool. Not a real-time API proxy (it’s batch ETL), but if your use case is syncing data between systems rather than live read/write in a product flow, it’s better maintained and has a large connector library.

Merge.dev — The SaaS incumbent. Expensive ($650–$1,500+/month) but production-grade, well-supported, and the integration coverage is extensive. If you can afford it, it works.

Apideck — Another SaaS unified API provider. Similar pricing tier to Merge.dev, focused on CRM/ATS/HRIS categories. No self-hosting option.

Build it yourself — Still the answer for companies with unusual integration requirements or those whose volume justifies full control. Painful, but at least it’s yours.

For the current getpanora.com use case (PO automation for distributors):

Conexiom — Market leader in PO automation for B2B commerce. Enterprise pricing, enterprise functionality.

Orderful — EDI and order automation for distributors and manufacturers.

---

Bottom line

Panora the open-source integration platform is dead. The GitHub repository says so directly [1]. What’s left is a different company, a different product, and a different customer — AI PO entry for warehouses, priced through enterprise sales, with no public pricing and no self-hosting option [2].

For anyone who found this review looking for a Merge.dev alternative they could self-host: the honest answer is that Panora was the most promising option in this space and it didn’t make it. Look at Nango instead. The underlying problem (affordable, self-hosted unified B2B integrations) remains unsolved by a mature open-source tool, which is a gap in the ecosystem worth knowing about.

If you’re a distributor drowning in purchase order emails and you don’t care about open source: getpanora.com might be worth a demo call. But that’s a different product for a different audience than anything this site usually covers.

---

Sources

1. Panora GitHub Repository — panoratech/panora (README: “The OSS Product was sunset”). https://github.com/panoratech/panora
2. Panora Official Website — AI Purchase Order Automation for Distributors. https://getpanora.com