Unified APIs: Usage-Based vs Per-Connection Pricing for Integrations

March 30, 2026

Updated May 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, what trade-offs does each carry, and where do hidden costs come from?

The pricing models actually used by unified API vendors

Unified API vendors have converged on a handful of pricing structures. Each ties cost to a different variable. The four most common are clean; two more are hybrids that don't fit neatly.

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.

Pricing model used by Merge.dev and Finch.

2. Usage-based (API calls)

You pay for activity, not connections.

Cost formula: total successful API calls (plus any overages)

Whether a customer connects one integration or five doesn't matter. Cost is driven by actual data activity through the platform.

Pricing model used by 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.

Pricing model used by Apideck and Paragon (including ActionKit).

4. Per-integration (connector)

You pay for the integrations you offer, not who uses them or how heavily.

Cost formula: number of connectors enabled

Whether 10 customers or 10,000 customers use an integration, the cost remains the same.

Pricing model used by Truto.

5. Tiered base + premium-call multiplier

A relatively new model: flat tier base price plus per-call usage, with certain "premium" calls billed at a higher multiple than standard calls.

Pricing model used by Composio. Their docs describe premium tools as priced at "3x the cost of a standard tool call." Standard overages are $0.299 per 1,000 calls; premium overages are $0.897 per 1,000 calls.

6. Mixed flat-tier + per-account at scale

Flat monthly tiers at low volume, transitioning to per-integrated-account pricing at higher tiers. Lower tiers often include feature gates (sync frequency, log retention) that release at higher contract levels.

Pricing model used by Knit. Their public tiers: Launchpad Free (100 calls/month, 5 MCP servers), Individual ($29/month, 5K calls), Start Up ($499/month, 24-hour sync frequency gate, 3-day log retention), Scale Up (contact-only, faster sync intervals), Enterprise (contact-only).

7. Hybrid + opaque

Platform fee + per-account or per-customer charges, with no public pricing grid. Pricing requires sales engagement.

Pricing model used by Kombo (annual platform fee + variable per-connected-customer fee), Codat (platform fee + per-linked-account, freemium + quotation-based), Rutter (annual contracts; ~$18K median per Vendr), Hotglue (Basic / Pro / Enterprise + Startup program; "Book a demo"), Tray.io (Standard / Professional / Enterprise; sales-driven), Alloy unified API (free connections + credits at low end, sales for serious usage).

Where the major platforms fall

• Note on Finch: publicly marketed as per-connection at $65/connection/month. Earlier plans and many contracts behave effectively like per-company-per-month with bundled connections. In sales conversations, both framings show up depending on the deal shape.

This classification matters because each model creates a different cost curve as your product scales — and a different stress point where the math stops working.

What pricing looks like at real company stages

The differences between models are small early. They compound quickly.

Seed stage (10 customers, 2 integrations each)

At this scale, most models are accessible:

• Merge.dev: First 10 linked accounts included in $650/month Launch plan base; 10 additional accounts at $65 each = $1,300/month total
• Finch: 20 employer connections × $65 = $1,300/month
• Apideck: Launch tier starts at 25 consumers; 10 customers fits comfortably
• Truto: Flat per-connector regardless of customer count; ~$999/connector/year for unlimited customer connections
• Composio: $29/month tier covers light agent prototyping
• Knit: Launchpad Free or Individual ($29/month) covers prototyping
• Unified.to: Grow tier $750/month (750K API calls, all 26+ categories, unlimited customer connections, 30-day free trial)
• Nango: Starter tier from $50/month

No major pressure yet. This is why many teams don't notice the model choice early.

Series A (100 customers, 2 integrations each = 200 connections)

This is where divergence starts.

• Merge.dev: First 10 linked accounts included; 190 additional × $65 = $12,350 + $650 base = $13,000/month
• Unified.to: Still Grow tier at $750/month if activity stays under 750K calls; Scale tier $3,000+/month if activity exceeds quota
• Finch: 200 employer connections × $65 = $13,000/month
• Apideck: Falls into Scale tier (starts at 100 consumers); published as contact pricing
• Truto: Still flat per enabled connector; same as Seed if connector count is the same
• Composio: Scales with API call volume; Serious Business tier ($229/month) plus usage overages
• Knit: Start Up tier $499/month (with 24-hour sync gate)
• Nango: Growth tier from $500/month + metered overages on multiple dimensions

At Series A, Merge.dev's $13,000/month vs. Unified.to's Grow tier $750/month is roughly 17×. If activity exceeds Grow's 750K-call quota, Unified.to moves to Scale at $3,000+/month — still 4-6× cheaper than per-connection.

Series B (500 customers, 3 integrations each = 1,500 connections)

The multiplier effect becomes obvious.

• Merge.dev: First 10 included; 1,490 additional × $65 = $96,850 + $650 = $97,500/month (before volume discounts on Pro+)
• Unified.to: Likely Scale tier at $3,000+/month for 6M API calls; remains flat regardless of customer count if API activity fits the tier
• Finch: Specialist HR/payroll; not directly comparable but per-connection math runs similarly
• Apideck: Enterprise tier territory (starts at 300 consumers); contact pricing
• Truto: Flat at enabled connector count; 5 connectors × $999/year = ~$5,000/year regardless of customer count
• Composio: Scales with API call volume across customer base; depends on tool mix (standard vs premium 3x calls)
• Knit: Scale Up tier (contact-only) with flexible sync frequencies
• Nango: Enterprise tier (custom) with metered overages

This is where per-connection models can reach six-figure monthly costs while other models remain an order of magnitude lower.

The integration depth multiplier

The biggest hidden variable isn't customer count. It's integration depth.

If you expand from 2 integrations to 5 integrations per customer:

• Per-connection: increase ~2.5× instantly
• Usage-based: unchanged unless activity also increases
• Per-consumer: unchanged
• Per-integration: unchanged unless you enable new connectors
• Tiered + premium multiplier: mixed; depends on whether new integrations involve premium-tier tools
• Mixed tiers + per-account: depends on tier; per-account portion scales with new connections

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 trade-offs

Each pricing model optimizes for something different. None are neutral.

Per-connection: predictable per-unit, 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, requires architectural discipline

• Cost tied to actual activity
• Scales well across customer base sizes (cost flat if activity flat)
• Requires thoughtful API usage (batching, webhooks, caching, Database Sync for analytics workloads)

The honest trade-off: heavy polling, redundant API calls, or uncached high-frequency reads will drive cost. But the discipline isn't exotic — it's standard production engineering practice. Batched reads, webhook subscriptions where supported, and offloading high-volume reads to your own infrastructure via Database Sync keep usage aligned with product value.

Competitor framing of usage-based pricing often invokes a "bill shock" narrative — pagination forces 1,000 calls per customer per sync; webhook events drain quotas; retries burn credits in a black box. Worth checking the math: 1,000 paginated API calls at Unified.to's published rate of $0.001 per call equals $1, not a catastrophic outcome. And Unified.to publishes specific structural answers to the predictability concern (covered below in "Hidden costs to verify").

Per-consumer: smoother scaling, still customer-tied

• 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: fully flat per-connector, but bounded by catalog

• Fully predictable
• Decoupled from usage and customer count
• Pay for each connector enabled, whether or not it's heavily used

The trade-off: this model is great if you enable a small number of connectors and serve many customers across them. It becomes expensive when you need broad category coverage — 50 enabled connectors × $999/year = $49,950/year baseline before any customer uses them. Compare to Unified.to's Grow tier at $9,000/year for full 446+ integration access across 26+ categories.

Tiered + premium multiplier: tier base predictability, premium-tier variability

• Base monthly fee provides predictability for standard call patterns
• Premium-call multiplier (~3× standard rate) introduces variable cost on high-value tool usage
• Cost modeling requires categorizing tool usage by tier

This is a relatively new model and Composio is the clearest example. The trade-off is that premium tools — typically the ones agent products care most about (write operations on key vendor systems) — billed at 3× create cost surprises if usage shifts toward premium.

Mixed tiers + per-account: flat at low volume, account-tied at scale

• Free or low-cost entry tier makes prototyping accessible
• Lower tiers often include feature gates (sync frequency caps, log retention limits)
• Higher tiers shift to per-account pricing without published rates

Knit is the cleanest example. The trade-off: low-volume teams get genuine accessibility (Launchpad Free, Individual $29/month). High-volume teams need to negotiate Scale Up or Enterprise, where pricing becomes contact-only and the per-integrated-account structure kicks in. The 24-hour sync frequency gate on Start Up ($499/month) is a real production constraint for AI workloads.

Pricing models shape product decisions

Pricing isn't just financial. It changes what gets built.

How many integrations you offer

• Per-connection → limit integrations per customer
• Usage-based → expand freely
• Per-consumer → bundle aggressively
• Per-integration → cap connector count
• Tiered + premium multiplier → bias toward standard-tier integrations
• Mixed tiers + per-account → manage tier transition carefully

How frequently you sync data

• Usage-based → batch reads, use webhooks, offload analytics
• Per-connection → less pressure on call volume, more pressure on connection count
• Tiered + premium multiplier → categorize calls by tier impact
• Mixed tiers + per-account → mind the sync frequency gates at lower tiers

This directly affects data freshness and UX.

What becomes possible with AI workflows

AI-driven products often query multiple systems per action, trigger many small API calls, and operate dynamically across integrations. Per-connection pricing doesn't map cleanly to this pattern. Usage-based models align more naturally with variable workloads — provided the platform offers structural answers to the bursty workload concern (Database Sync, batched reads, webhook-driven updates).

Hidden costs to verify during evaluation

This is where most pricing comparisons fall short. The headline rate is rarely the full picture. Worth asking about:

• Premium call multipliers — Composio bills premium tools at ~3× standard call rate. Standard: $0.299/1k. Premium: $0.897/1k. Cost modeling needs to categorize anticipated tool usage by tier.
• Sync frequency gates — Knit's Start Up tier ($499/month) locks sync to 24-hour intervals. Faster requires Scale Up (contact-only pricing).
• Platform fees plus per-account — Codat, Kombo, and Rutter blend annual platform fees with per-customer or per-account rates. Total cost requires sales engagement; no public dollar grid.
• Linked-account minimums — Merge's Launch plan ($650/month) bundles 10 linked accounts; the $65/account rate is for overages beyond 10.
• Multi-dimensional metering — Nango charges across multiple dimensions (connections, requests, compute time, runs, logs, records, webhooks). Cost modeling requires understanding all dimensions, not just one.
• What counts as a "consumer" — Apideck's "Consumer" means an active customer using integrations. A customer not using integrations isn't billed. Verify the definition matches how you'd count your own.
• Bundled tools — Paragon's ActionKit is included in all Paragon tiers; pricing is on connected users/customers at the platform level, not on tools enabled.
• Webhook billing structure — Some vendors charge for every webhook event. Verify what's billable. Unified.to bills native webhooks per successful delivery only; virtual webhooks bill only on change-detected events (empty polls and provider errors are non-billable; subscriptions themselves are unlimited).
• Retry handling — Some vendors auto-retry on upstream provider 429s and bill each retry as a new call. Unified.to handles provider 429s internally as part of a single logical call (internal retries don't multiply against your quota). Upstream 429s from Unified.to to your client are pass-through — your client implements backoff and any retries you initiate are new billable calls.
• Annual commits with uplift clauses — Per-consumer and enterprise tiers often include annual minimums with year-over-year uplifts. Confirm before signing.

Unified.to in this taxonomy: usage-based with structural answers

Since Unified.to is a usage-based platform, worth being explicit about how the model works in practice:

• Grow ($750/month): 750,000 API calls. All 26+ categories. Unlimited customer connections. 30-day free trial.
• Scale ($3,000+/month): 6 million API calls. Adds SAML SSO, customer-managed secrets (BYOK via AWS Secrets Manager, Azure Key Vault, Google Cloud Secrets Manager, or HashiCorp Vault), HIPAA BAAs, multi-region MCP endpoints (US/EU/AU).
• Enterprise (custom): Single tenant, private cloud, dedicated cloud, or on-prem deployment.

Cost scales with API activity, not customer count or integration depth. Adding integrations to existing customers doesn't multiply cost. Customer growth that doesn't drive API activity doesn't compound infrastructure spend.

Structural answers to the usage-based predictability concern

The architectural-discipline trade-off is real for usage-based pricing. Three structural choices keep activity proportional to product value:

Database Sync (available on all plans). Stream normalized records to your own Postgres, MongoDB, MySQL, MSSQL, CockroachDB, or MariaDB. Use API calls for live agent access; use Database Sync for analytics workloads, RAG pipelines, and high-volume cached reads. Customer business data lives in your infrastructure, not Unified.to's, and the high-volume reads happen outside the per-call quota.

Webhook-driven incremental updates. Native webhooks bill per successful delivery, not per subscription. Virtual webhooks bill only when polling detects new data and Unified.to attempts delivery — empty polls and errors are non-billable. This makes change-driven architectures cost-aligned with actual change events.

Verified billing transparency. Successful API calls and successful event deliveries are billable. Provider errors, dispatch errors, internal retries that Unified.to performs to make one logical operation succeed, and empty virtual webhook poll runs are all non-billable. The "retries multiply costs" concern that some competitor framings invoke doesn't survive contact with the actual billing structure.

Lock-in and switching costs

Pricing is 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. Some vendors offer credential export (Unified.to does); some don't.
• SDK and schema dependency. Switching providers means rewriting integration logic.
• Contracts. Annual commitments and uplift clauses increase exit cost.

Pass-through architectures (Unified.to, Knit) avoid storing customer business data at rest, which reduces some of this friction. Sync-and-store models (Merge, Codat) create deeper dependency by maintaining canonical copies of customer data in vendor infrastructure.

Transparency varies

Not all pricing is visible.

Some providers publish full pricing pages with specific rates: Unified.to, Merge.dev (Launch tier specifics; Pro and Enterprise contract-based), Apideck (tier structure), Truto ($999/connector/year), Nango (full pricing page with metered overages), Composio (Free/$29/$229 with documented overage rates), Knit (Launchpad through Start Up explicitly priced; Scale Up and Enterprise contact-only).

Some require sales conversations for any pricing visibility: Codat, Rutter, Hotglue, Tray.io, Alloy (unified API), Kombo, Paragon, Finch above the Launch entry tier.

For buyers, transparency affects evaluation speed and predictability. Sales-driven pricing isn't inherently bad — but it requires more time and creates information asymmetry between vendors and buyers.

How to evaluate pricing without getting locked in

A simple checklist:

1. Audit your active connected accounts. Calculate average integrations per customer × projected customer count at 12 and 24 months. That's your linked-account exposure if you go per-connection.
2. Estimate your monthly API call volume. Count resources synced × average record count per customer × pagination depth × sync frequency. Include webhooks and verify what's billable.
3. Calculate total cost at each milestone using every vendor's published pricing. If a vendor doesn't publish pricing, that's a data point.
4. Ask about customization costs. Can you handle custom fields on a self-serve plan, or do you need a Professional/Enterprise upgrade?
5. Check what counts as a billable unit. Webhook deliveries? Provider errors? Internal retries? Sync attempts that find no new data?
6. Verify retry behavior on upstream 429s. Are provider rate limits absorbed into a single logical call, or does each retry become a billable event?
7. Verify whether the vendor offers a structural escape hatch for high-volume reads (database sync, cached reads, etc.) — and whether it's tier-gated.

Picking the model that rewards your growth

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 (and reward architectural discipline)
• Per-consumer models tie cost to customer count
• Per-integration models fix cost upfront but cap your catalog reach
• Tiered + premium multiplier offers base predictability with premium-tier variability
• Mixed tiers + per-account is accessible at low volume but transitions to contact-only at scale
• Hybrid + opaque requires sales engagement for any cost clarity

The right model depends on your product, your customers, your scaling pattern, and the catalog breadth your roadmap needs.

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.

→ Start your 30-day free trial

→ Book a demo