Why Per-Connector Integration Pricing Is Broken (And What Replaces It in the Age of AI)

The integration platform market has a pricing problem. For years, vendors have charged SaaS companies per connector, per connection, or per "active integration." The logic seemed reasonable: more integrations means more value, so you should pay more. But this model fundamentally misaligns incentives. It punishes growth, discourages breadth, and forces engineering teams into awkward conversations with finance about whether adding a seventh CRM connector is "worth it."

In the age of AI agents, where products need to connect to dozens of systems of record to deliver intelligent, context-rich experiences, per-connector pricing has become a growth tax. Every new connector your customers need is another line item on your bill, another negotiation with your vendor, another reason to delay shipping the integration your sales team has been asking for.

Usage-based pricing, specifically credit-per-action models, inverts this dynamic entirely. You pay for what you use, not for what you connect to. The number of connectors becomes irrelevant to your bill. Your integration costs scale with your actual business activity, not with the breadth of systems your customers happen to use.

This isn't a minor pricing tweak. It's a structural advantage that determines which teams can scale their integration layer without friction, and which teams get stuck in procurement cycles every time a customer asks for a new system.

The Per-Connector Pricing Trap

Let's be specific about how per-connector pricing works at most integration vendors and why it creates friction.

Merge charges a platform fee plus per-connection pricing. Every customer who connects their CRM, ERP, or HRIS through your product is a billable connection. When you have 50 customers on Salesforce, 30 on HubSpot, and 20 on Dynamics, you're paying for 100 connections, regardless of whether those customers are syncing one record per day or ten thousand. Your bill grows linearly with your customer base, not with the value you're extracting from the platform. Worse, Merge holds your customers' OAuth tokens, so switching vendors means every customer re-authenticates.

Paragon and Workato Embedded start at a five-figure annual minimum with undocumented usage charges layered on top. Their pricing gates critical features like per-customer field mappings, SSO, and RBAC behind Enterprise tiers, which can push annual contracts into six figures. The effective cost per integration climbs steeply as you need more sophisticated capabilities. And because their polling architecture shares resources across tenants, scaling creates "noisy neighbor" problems where your largest customers consume disproportionate API quota, degrading performance for everyone else.

Prismatic uses a tenant-based pricing model where you pay based on the number of active customers using integrations. This means your integration bill scales directly with customer count, regardless of how much (or how little) each customer actually uses the integration. A customer who syncs one contact per month costs the same as a customer syncing thousands of records daily. You're paying for potential, not actual value.

The common thread across all these models: your bill is a function of how many things you connect to, or how many customers connect, rather than a function of how much actual integration work gets done. This creates three specific problems.

Problem one: connector count becomes a budget constraint. Your product team wants to support NetSuite, SAP, Sage, QuickBooks, Xero, and FreshBooks. Your finance team says you can afford four. Now you're making product decisions based on vendor pricing tiers, not customer demand. This is exactly the kind of artificial constraint that slows product velocity and frustrates go-to-market teams.

Problem two: customer growth inflates costs non-linearly. Per-connection pricing means every new customer who connects their CRM adds to your bill. When you're at 50 customers, it's manageable. At 500, your integration bill has 10x'd, even if your actual data volume hasn't grown proportionally. This creates a margin compression problem where integration costs eat into your unit economics as you scale.

Problem three: pricing unpredictability kills planning. When your integration costs depend on how many customers connect, and you can't predict exactly how many customers will adopt each integration in a given quarter, budgeting becomes guesswork. Engineering leaders we've worked with describe this as "integration cost anxiety," the inability to confidently forecast what their integration layer will cost in six months.

Why the AI Era Makes Per-Connector Pricing Untenable

The per-connector pricing model was tolerable when SaaS products connected to three or four systems. In that world, paying per connector was a rounding error. But the AI era has changed the math entirely.

AI agents, AI SDRs, AI customer service bots, AI financial analysts: these products don't connect to one or two systems. They connect to everything. An AI SDR needs Salesforce, HubSpot, Outreach, LinkedIn, Gmail, Google Calendar, Outlook, and potentially a dozen more depending on the customer's stack. An AI financial agent needs NetSuite, SAP, Sage, QuickBooks, plus banking APIs, payment processors, and revenue recognition systems.

When your product needs ten connectors to deliver its core value proposition, per-connector pricing means your integration vendor takes a significant cut of every dollar you earn. This is unsustainable. Engineering leaders building AI products have told us that their integration costs were on track to exceed their infrastructure costs within 18 months if they stayed on per-connector models.

The shift is clear. Native product integrations are now table stakes, not differentiators. Every B2B SaaS product, especially those powered by AI, needs deep connectivity with its customers' systems of record. The platforms that charge you more for connecting to more systems are taxing the exact behavior that drives product value. It's like charging a database per table: technically possible, but fundamentally misaligned with how teams build products.

This is why the most forward-thinking integration infrastructure platforms have moved to usage-based models. The number of connectors you use should be unlimited. What matters is how much data actually flows through those connectors. That's the value. That's what you should pay for.

How Usage-Based (Credit-Per-Action) Pricing Works

Ampersand's pricing model is built on a simple principle: you pay for actions, not connections. An action is a discrete unit of integration work: a read, a write, a subscribe event, a proxy request. One action equals one credit. Your bill reflects the actual integration work your product performs, regardless of how many connectors or customers are involved.

Here's what this means in practice.

Unlimited connectors, same price. Whether you use 3 connectors or 30, your per-action cost doesn't change. You're not penalized for breadth. You can support every system your customers ask for without triggering a pricing tier change or a procurement conversation. This is how integration infrastructure should work: the platform scales with your usage, not your connector count.

Costs scale with actual value delivery. A customer who syncs 100 records per month uses fewer credits than one who syncs 10,000. Your bill reflects the work being done, which correlates with the value being delivered. This alignment means your integration economics improve as your product becomes more efficient, rather than degrading as your customer count grows.

Predictable, forecastable spend. Because credits map to actions, and actions correlate with your product's usage patterns, you can model your integration costs alongside your other infrastructure costs. No surprises. No "we added 50 customers and our bill doubled" moments. You know what an action costs, you know your average actions per customer, and you can forecast confidently. This also helps alignment with the cost of goods sold (COGS) to attributable customer revenue.

No feature gating based on pricing tier. Per-customer field mappings, custom objects, real-time webhooks, bulk writes: these are available on every tier. You don't hit a wall at 25 customers and discover that the features you need are Enterprise-only. The platform's capabilities are consistent; you simply pay for the volume of actions you consume.

Free tier for evaluation. You can build and test integrations without spending anything. This means your engineering team can evaluate the platform, build a proof of concept, and validate the integration architecture before committing a dollar. No 14-day trials that expire before your team has time to properly evaluate. No sales calls required to get started.

The entry point is $999/month on the Catalyst plan, which includes 2GB of data per month and supports up to 25 customers. For teams that need more, custom packages scale with your actual usage. Compare this to Paragon's five-figure annual minimum or Merge's platform fee plus per-connection charges, and the economics are stark.

The Structural Advantage: Why This Changes How Teams Build

Usage-based pricing isn't just cheaper in most scenarios. It changes how product teams think about integrations.

You ship integrations faster. When adding a new connector doesn't increase your bill, the decision to support a new system becomes purely a product and revenue expansion decision. Does the customer need it? Can we build it? Ship it. There's no "let's wait until Q3 when we have budget for another connector" conversation. This velocity matters enormously for teams in competitive markets where integration breadth is a differentiator.

You experiment without risk. Want to test whether your customers would use a Gong integration? Build it. If nobody adopts it, you've spent engineering time but your integration costs don't change. If it takes off, your costs scale proportionally with usage. This removes the financial risk from integration experimentation and lets product teams follow customer signals without budget gatekeeping.

Your customers get what they need. Enterprise customers have specific systems of record. Mid-market customers use different tools than upmarket ones. With per-connector pricing, you're forced to pick which customer segments to serve based on which connectors you can afford. With usage-based pricing, you serve everyone. A customer on NetSuite gets the same integration depth as one on QuickBooks, without either costing you more in platform fees.

Your AI agents can access everything. For teams building AI products, this is the critical unlock. An AI agent that needs to read from Salesforce, write to HubSpot, subscribe to Gong events, and proxy requests to NetSuite doesn't generate four separate line items. It generates credits based on the actions it performs. The agent can be as broad as it needs to be without per-connector math constraining its architecture. This is why teams building agent-ready integration infrastructure increasingly demand usage-based pricing.

The Comparison: Pricing Models Across Integration Platforms

The pattern is clear: usage-based pricing aligns costs with value. Per-connector and per-tenant models align costs with growth, which means they become a tax on success.

What Engineering Leaders Get Wrong About Integration Pricing

In our work with dozens of product teams evaluating integration platforms, we've seen three common mistakes in how teams think about pricing.

Mistake one: optimizing for day-one cost instead of scale economics. A unified API that charges $750/month for 750K API calls looks cheap at 10 customers. At 500 customers making 50K calls each per month, you're well past the included volume and paying significant overages. Teams that evaluate pricing at current scale instead of projected scale end up replatforming within 18 months. We've written extensively about why building integrations in-house breaks down at scale, and the same principle applies to vendor pricing: what works at 10 customers doesn't work at 500.

Mistake two: ignoring feature gates. A platform that looks affordable on the Pro tier becomes wildly expensive when you realize per-customer field mappings (which every mid-market and enterprise customer requires) are gated behind an Enterprise plan. Suddenly your "affordable" integration platform has a six-figure price tag. This bait-and-switch is common in the embedded iPaaS space, and it catches teams off guard precisely when they can least afford to switch.

Mistake three: not accounting for credential ownership. When a vendor holds your customers' OAuth tokens (as Merge, Paragon, and Prismatic all do), switching vendors means every customer re-authenticates. This isn't just inconvenient, it's a business continuity risk. The cost of vendor lock-in isn't on the pricing page, but it's real. Ampersand lets you own and export your customers' credentials. If you ever leave, your customers don't notice. This optionality has real economic value that teams consistently undervalue during evaluation. As we've explored in our piece on auth and token management, credential ownership isn't a nice-to-have, it's foundational to your integration strategy.

Why "Unlimited Connectors" Matters More Than You Think

Let's do some math. A typical B2B SaaS product selling to mid-market and enterprise customers needs to support, at minimum:

CRM systems: Salesforce, HubSpot, Microsoft Dynamics 365, Pipedrive, Zoho. That's five. ERP systems: NetSuite, SAP, Sage, QuickBooks, Xero. Another five. Communication: Gmail, Outlook, Slack, Microsoft Teams. Four more. Calendar: Google Calendar, Outlook Calendar. Two. Sales engagement: Outreach, SalesLoft, Apollo. Three. And depending on your vertical, you might need industry-specific platforms on top of all this.

That's a minimum of 15-20 connectors to serve the mid-market. Enterprise customers will push that number higher with vertical-specific systems, custom ERPs, and legacy tools.

On a per-connector model charging $500-750 per active connector, that's $7,500-15,000/month just for connector access, before you've synced a single record. On a per-connection model at $750+ per connected customer instance, 200 customers across those systems could mean $150,000+ annually in connection fees alone.

On Ampersand's usage-based model at $999/month, all of those connectors are included. Your cost scales only with the actual data flowing through them. If 200 customers are syncing modest volumes, your bill might be a fraction of what a per-connector or per-connection model would charge.

This math is why AI product companies, which need the broadest integration coverage, are overwhelmingly choosing usage-based models. When your AI agent needs to read from and write to 15+ systems to deliver its core value, per-connector pricing makes your product economically unviable at scale.

The Ampersand Pricing Philosophy

Ampersand's pricing reflects a fundamental belief: connectors are not the value. The value is in the data flowing through them, the actions being performed, the intelligence being delivered to your customers. Connectors are infrastructure, like network switches. You don't pay per switch; you pay for bandwidth.

This philosophy extends to how Ampersand structures its entire offering:

250+ open-source connectors, all included. Every connector in Ampersand's library is available on every plan. NetSuite, Salesforce, HubSpot, SAP, Sage, Gong, Outreach, and hundreds more. You don't pay extra for "premium" connectors or "enterprise" systems. A NetSuite connector costs the same credits as a HubSpot connector: zero for the connector itself, credits only for the actions you perform through it.

Per-customer field mappings on every tier. Unlike competitors who gate this behind Enterprise plans, Ampersand includes per-customer field mapping on all tiers. This matters because every enterprise customer configures their CRM differently. If you can't map custom fields per customer without upgrading to a six-figure plan, you can't serve the mid-market. This isn't a feature, it's table stakes, and Ampersand treats it as such.

Credential ownership and portability. You own your customers' OAuth tokens. You can import credentials from another platform (migrating without forcing re-auth) and export them if you leave. This eliminates vendor lock-in at the credential layer, which is where most integration platforms create switching costs. Your integration infrastructure should serve your business, not hold it hostage.

Sub-second real-time sync included. Ampersand's Subscribe Actions deliver webhook events in under one second. This isn't an Enterprise add-on or a premium tier feature. It's how the platform works. For AI products that need real-time CRM context (as 11x demonstrated, cutting their AI phone agent's response time from 60 seconds to 5), real-time isn't optional. It's the baseline.

Transparent, modelable costs. One read action equals one credit. One write action equals one credit. One subscribe event equals one credit. You can calculate your projected costs with a spreadsheet. No hidden fees, no undocumented usage charges, no "contact sales to find out what it actually costs." As Hatch CTO John Pena put it: "Ampersand lets our team focus on building product instead of maintaining integrations." Part of that focus comes from not having to constantly renegotiate integration costs as you grow.

FAQ: Integration Pricing for Growing SaaS Teams

Q: We're early-stage with 10 customers. Does pricing model really matter yet?

A: It matters more than you think, even more so because you're early. The platform you choose now is the platform you'll likely scale on. Replatforming integrations at 200 customers is brutal: credential migrations, data format changes, downtime risk. Choose a pricing model that won't punish your growth. At 10 customers, per-connection pricing looks cheap. At 200, it's a significant cost center. Usage-based pricing stays proportional regardless of scale.

Q: How do I estimate my action/credit usage before committing?

A: Map your integration patterns. How many objects do you sync per customer? How frequently? A customer syncing 5 objects every 15 minutes generates roughly 480 read actions per day. Multiply by your customer count, add writes, and you have your monthly action volume. Ampersand's free tier lets you build and test before committing, so you can measure actual usage rather than estimating.

Q: What happens if we have a usage spike (like a large backfill)?

A: Backfills generate actions, so they consume credits. But because credits are usage-based, you only pay for the actual work done. Compare this to per-connector models where a backfill doesn't change your bill (because you're already paying the connector fee) but might hit rate limits that degrade service for other customers. With usage-based pricing, you can backfill as aggressively as you need without worrying about shared resource contention.

Q: Our finance team wants predictable costs. Isn't usage-based pricing inherently unpredictable?

A: Usage-based doesn't mean unpredictable. Your product has consistent usage patterns per customer. Once you know your average actions per customer per month (which stabilizes quickly after launch), you can forecast as reliably as any other infrastructure cost. Ampersand also offers committed-use discounts for teams that want to prepay for a known volume, giving you both the alignment of usage-based pricing and the predictability of fixed commitments.

Q: What about per-customer field mappings? Do those cost extra?

A: No. Per-customer field mappings are included on every Ampersand tier. This is a critical difference from competitors like Paragon, where per-customer mappings are gated behind Enterprise pricing (often six figures annually). Since virtually every mid-market and enterprise customer has custom fields in their CRM or ERP, this feature isn't optional for real-world deployments. Gating it behind premium tiers is a pricing trick, not a product decision.

Q: We're building an AI product that needs 15+ connectors. How does pricing work for us?

A: Identically to a product with 3 connectors. All 250+ connectors are included on every plan. Your AI agent can read from Salesforce, write to HubSpot, subscribe to Gong events, and proxy requests to NetSuite, all consuming credits based on actions performed. The connector count is irrelevant to your bill. This is specifically why AI product companies choose Ampersand: the breadth their agents need doesn't create pricing pressure.

Conclusion: Pricing That Scales With You, Not Against You

The integration platform market is consolidating around a simple truth: per-connector pricing punishes the exact behavior that drives product value. In a world where AI products need broad, deep connectivity to deliver intelligence, charging per connector is charging per feature. It's like charging a database per query type, or a CDN per domain served. It made sense in a simpler era. It doesn't anymore.

Usage-based pricing aligns your integration costs with your actual business activity. You pay for value delivered (actions performed), not for potential value (connectors available). Your costs scale smoothly and predictably as your product grows. You never have a conversation with finance about whether you can "afford" to support another system your customers are asking for.

Ampersand built its pricing model around this principle because the teams we work with, engineering leaders building multi-tenant integrations at scale, told us that per-connector pricing was the single biggest friction point in their integration strategy. Not the technology. Not the documentation. The pricing model itself was creating artificial constraints on their product roadmap.

If your team is evaluating integration platforms and wants to understand how usage-based pricing would work for your specific use case, you can see how Ampersand works, explore the documentation, or speak directly with an engineer who can model your projected costs. The connectors are unlimited. The pricing scales with you. And your customers' credentials stay yours.