Unified APIs: Usage-Based vs Per-Connection Pricing for Integrations
March 30, 2026
Most teams evaluate unified APIs on coverage, reliability, and time to launch.
The bigger lever is pricing.
The model you choose determines how integration costs behave as you grow. At small scale, the differences are easy to ignore. By the time you reach 100–500 customers, the gap can be the difference between a manageable infrastructure cost and a six-figure line item sitting in COGS.
This breakdown focuses on one question: how does each pricing model scale in the real world?
The four pricing models (and how they actually work)
Unified API vendors have converged around four distinct pricing structures. Each ties cost to a different variable.
1. Per-connection (linked account)
You pay for every customer-to-integration connection.
Cost formula:
customers × integrations per customer × price per connection
If one customer connects two systems, that's two billable units. If 100 customers each connect two integrations, that's 200 billable connections.
This model is used by platforms like Merge.dev and Finch.
2. Usage-based (API calls)
You pay for activity, not connections.
Cost formula:
total API calls (plus any overages)
Whether a customer connects one integration or five doesn't matter. Cost is driven by how much data flows through the system.
This model is used by platforms like Unified.to and Nango.
3. Per-consumer (end customer)
You pay for each customer using integrations, regardless of how many they connect.
Cost formula:
active customers with at least one integration
One customer connecting five systems still counts as one billable unit.
This model is used by platforms like Apideck, Paragon, and Hotglue.
4. Per-integration (connector)
You pay for the integrations you offer, not who uses them.
Cost formula:
number of connectors enabled
Whether 10 customers or 10,000 customers use an integration, the cost remains the same.
This model is used by platforms like Truto.
Where the major platforms fall
The market is not ambiguous—each provider sits clearly in one of these models.
Per-connection
- Merge.dev
- Finch
- Kombo
Usage-based
- Unified.to
- Nango
Per-consumer
- Apideck
- Paragon
- Hotglue
Per-integration
- Truto
Hybrid or opaque pricing
- Alloy Automation
- Codat
- Rutter
- Tray.io
This classification matters because each model creates a different cost curve as your product scales.
What pricing looks like at real company stages
The differences between models are small early. They compound quickly.
Seed stage (10 customers)
At this stage, most models feel similar.
- Per-connection: manageable (low connection count)
- Usage-based: fixed base cost
- Per-consumer: low tier pricing
- Per-integration: flat baseline
No major pressure yet. This is why many teams don't notice the issue early.
Series A (100 customers)
This is where divergence starts.
Assume:
- 100 customers
- 2 integrations each → 200 connections
Now compare:
- Per-connection: scales directly with 200 units
- Usage-based: still tied to API activity, often unchanged
- Per-consumer: scales with 100 customers
- Per-integration: unchanged
At this point, per-connection costs can be 8–10× higher than usage-based or per-consumer models.
Series B (500+ customers)
Now the multiplier effect becomes obvious.
Assume:
- 500 customers
- 3 integrations each → 1,500 connections
- Per-connection: grows with both customers and integrations
- Usage-based: grows with activity, not structure
- Per-consumer: grows linearly with customers
- Per-integration: still flat
This is where per-connection models can reach six-figure annual costs, while other models remain an order of magnitude lower.
The integration depth multiplier (what most teams miss)
The biggest hidden variable is not customer count. It's integration depth.
If you expand from:
- 2 integrations → 5 integrations per customer
Your costs:
- Per-connection: increase ~2.5× instantly
- Usage-based: unchanged unless activity increases
- Per-consumer: unchanged
- Per-integration: unchanged
This creates a constraint:
Teams on per-connection pricing often limit how many integrations they offer—not because of engineering complexity, but because of cost.
The core tradeoff: growth tax vs usage volatility
Each pricing model optimizes for something different. None are neutral.
Per-connection: predictable, but compounds aggressively
- Easy to model
- Costs increase with customer success
- Penalizes multi-integration usage
This is where the 'growth tax' argument comes from. The more your customers adopt integrations, the more your costs multiply.
Usage-based: flexible, but requires efficiency
- Cost tied to real activity
- Scales well with large user bases
- Requires thoughtful API usage (batching, webhooks, caching)
This model aligns cost with actual usage, but teams need to design systems that avoid unnecessary API calls.
Per-consumer: smoother scaling, still tied to growth
- Eliminates per-integration penalties
- Predictable monthly costs
- Still increases directly with customer count
Costs don't multiply with integrations, but they still rise as you acquire customers.
Per-integration: fixed cost, high commitment
- Fully predictable
- Decoupled from usage and customers
- Requires committing to integrations upfront
This model works best when your integration set is stable and well-defined.
Pricing models shape product decisions
Pricing is not just financial. It changes what gets built.
1. How many integrations you offer
- Per-connection → limit integrations
- Usage-based → expand freely
- Per-consumer → bundle aggressively
When each integration adds cost, product teams become selective.
2. How frequently you sync data
- Usage-based → optimize API calls, reduce unnecessary syncs
- Per-connection → less pressure on call volume, more pressure on connection count
This directly affects data freshness and UX.
3. What becomes possible with AI workflows
AI-driven products often:
- query multiple systems per action
- trigger many small API calls
- operate dynamically across integrations
Per-connection pricing does not map cleanly to this pattern.
Usage-based models align more naturally with variable workloads.
The gross margin impact (why this becomes a board-level issue)
Unified API costs sit in COGS. They directly reduce gross margin.
Take a simple example:
- SaaS product at $100/month per customer
- 100 customers
Now compare cost per customer:
- Usage-based: ~$5–$10/month
- Per-consumer: ~$10–$15/month
- Per-connection: can exceed $100/month depending on integrations
At that point:
- 5–10% margin impact (usage-based)
- 10–15% (per-consumer)
- 25%+ or worse (per-connection)
In extreme cases, integration cost can exceed revenue per customer.
That drops a SaaS business below standard 70–80% margin benchmarks, which directly affects valuation and capital efficiency.
Lock-in and switching costs
Pricing is only part of total cost. Architecture determines how hard it is to leave.
Key factors:
Data storage vs pass-through
- Sync-and-store platforms hold customer data
- Migration requires rebuilding pipelines and re-syncing
OAuth and credential ownership
- Reconnecting every customer can take weeks
SDK and schema dependency
- Switching providers means rewriting integration logic
Contracts
- Annual commitments and uplift clauses increase exit cost
Pass-through architectures reduce some of this friction because they avoid storing data at rest. Sync-based models often create deeper dependency.
Transparency is part of the model
Not all pricing is visible.
- Some providers publish full pricing
- Others require sales conversations
This typically reflects their go-to-market:
- developer-first → transparent pricing
- enterprise sales → custom contracts
For buyers, it affects evaluation speed and predictability.
Final takeaway
Unified APIs are often evaluated as infrastructure.
In practice, they behave like a pricing decision embedded inside your product.
- Per-connection models tie cost to customer growth and integration depth
- Usage-based models tie cost to actual activity
- Per-consumer models tie cost to adoption
- Per-integration models fix cost upfront
The right model depends on your product, your customers, and your margins.
The wrong model turns integrations into a constraint—something you limit, gate, or optimize around.
The right model lets integrations scale with your product, not against it.