Stop Being Punished for Growth by Per-Connection API Pricing

B2B SaaS companies operate on a simple economic premise: build software once, sell it infinitely. The marginal cost of adding a new customer should approach zero. When you integrate a unified API platform into your stack, you expect it to behave the same way. You buy the abstraction layer to avoid building 50 custom CRM and HRIS integrations, expecting it to accelerate your roadmap.

Then the honeymoon phase ends.

A few quarters later, your finance team flags a massive spike in infrastructure spend. You look at the invoice from your unified API provider and realize the truth: your integration bill is scaling linearly with your customer acquisition. You are being taxed for your own growth.

Your unified API bill is spiking because most vendors charge for a proxy metric, not the thing you actually care about. Connection-based platforms bill every linked account. Usage-based platforms bill every sync, page, webhook, and backfill. That is not an unavoidable cost of integrations. It is a pricing choice.

This post breaks down the actual financial math behind per-connection and usage-based pricing models, the hidden costs of retreating to in-house builds, and the specific architectural differences that allow modern platforms to charge by the integration—not by the customer.

The Unified API Trap: Why Your Integration Bill Is Skyrocketing

You bought a unified API to solve a real problem: building and maintaining dozens of individual API integrations was eating your engineering bandwidth. The pitch was simple—one API, hundreds of integrations, ship fast. And it worked. For a while.

Then your product gained traction. More customers signed up. Each customer connected their CRM, their HRIS, their accounting tool. Your integration usage grew because your product was succeeding. And your unified API bill grew right alongside it—not because you needed more integrations, but because more people were using the ones you already had.

Unified API pricing is the model your vendor uses to monetize abstraction over third-party APIs. The four models you will actually see in the market are:

This is where teams get trapped. They buy a unified API to reduce engineering load, speed up roadmap delivery, and close enterprise deals faster. Then the invoice starts behaving like a penalty on product adoption. A customer connects Salesforce and HubSpot? Bill goes up. Customer success turns on more frequent syncs so onboarding works better? Bill goes up. A large tenant triggers a historical backfill across hundreds of thousands of records? Bill goes up. The platform solved the HTTP plumbing but kept the cost curve attached to the wrong variable.

The painful part is that this tax shows up exactly when the product is working. The better your activation, the deeper your customers integrate. The deeper they integrate, the more linked accounts, consumers, or requests you produce. Finance sees rising COGS. Product starts quietly rationing integrations. Engineers start discussing billing math instead of the user problem. That is bad architecture disguised as pricing.

The Math Behind Per-Connection Pricing (And Why It Fails)

Per-connection pricing charges once for every customer-to-vendor connection. It looks predictable early. It gets ugly the second one customer wants more than one connector.

Let's look at the actual numbers. Merge.dev positions itself as the premium enterprise unified API. Their pricing model is aggressive: they charge by the Linked Account. A Linked Account is industry speak for a single customer connecting to a single third-party provider. If one of your customers connects their Salesforce CRM, their Zendesk ticketing system, and their HiBob HRIS, that counts as three Linked Accounts.

According to their published pricing, the Launch plan starts at $650 per month, which includes up to 10 production Linked Accounts. After those first 10, you pay $65 for every additional Linked Account. Enterprise pricing is custom and can range $50,000+ annually.

There is another detail most buyers miss on the first pass through pricing pages. Merge's billing FAQ says production Linked Accounts in both Complete and Idle states count toward billing. Idle means credentials are still valid, but there has been no inbound request or no webhook response for two weeks. In other words, the meter can still run even when a connection is not doing anything interesting.

Let's project this out for a growing B2B SaaS company:

At 500 customers, you are paying over a million dollars annually just for an API abstraction layer. That's before you've paid a single engineer, before hosting, before your own SaaS infrastructure costs.

This creates a perverse incentive: your integration platform punishes you for offering more integrations to your customers. The very behavior that makes your product stickier—deep, multi-category integration adoption—is what blows up your cost structure. If you're building a vertical SaaS platform and want to offer integrations with accounting systems, POS systems, and payroll providers, each customer who adopts all three categories triples your linked account count.

Worse, this exorbitant base fee does not even guarantee that the integrations will work for your most important enterprise clients. When a Fortune 500 customer demands support for a heavily customized Salesforce instance with proprietary objects, you will quickly discover that custom field mapping is gated behind contract-based enterprise plans. You are forced to either upgrade to an even more expensive tier or bypass the unified schema entirely and write raw passthrough requests.

For a deeper analysis of this exact limitation, read our breakdown of Truto vs Merge.dev: The Best Alternative for Custom APIs.

API-Call Pricing: Trading One Penalty for Another

Recognizing the industry backlash against per-connection fees, other integration platforms like Apideck and Unified.to pivoted to usage-based pricing models. They charge by the API call, by compute time, or by active consumer.

On the surface, this feels equitable. You only pay for the compute you consume. In practice, API-call pricing is just as punitive—it simply penalizes a different metric. It punishes you for having highly active, successful integrations.

Unified.to's public pricing makes the model very explicit. Their Grow plan starts at $750 per month for 750,000 monthly API calls with $1 per 1,000-call overages. Pro starts at $1,250 per month for 1,250,000 calls. The same pricing page says customers and connections are unlimited.

That sounds fair until you read the FAQ. Unified.to says successful API calls are billable, native webhook deliveries are billable, and paginated list calls count one request per page. So a list-employees call that returns 100 records is one billable request, the next page is another, and every webhook that flows through the platform also hits the meter.

Consider the math for a compliance SaaS tool that polls HRIS data for audit evidence:

At that volume, API-call pricing stops being "aligned with usage" and starts being "a tax on doing your job properly."

Here is the simple formula every PM should model before signing a request-metered contract:

monthlyRequests =
  customers * integrationsPerCustomer * syncsPerDay * avgCallsPerSync * 30
 
overageCost =
  max(0, monthlyRequests - includedRequests) / 1000 * overagePerThousand

To mitigate these unpredictable cost spikes, engineering teams are forced into defensive architecture:

• Aggressive Caching: Building complex local caching layers to intercept read requests, which introduces state management headaches and stale data issues.
• Delayed Syncs: Downgrading real-time webhooks to daily cron jobs, forcing users to wait 24 hours to see their data updated.
• Data Starvation: Skipping related data fetches—like refusing to pull a contact's associated company details—simply to suppress the volume of outbound HTTP requests.

You end up intentionally degrading your own product's user experience just to appease your integration provider's billing model.

Apideck has moved to a saner middle ground with consumer-based pricing. A consumer using one integration or five integrations is still one consumer. But you're still paying per customer, which means your costs still scale linearly with your customer base.

The Hidden Costs Nobody Talks About: Building In-House

Faced with exorbitant vendor pricing and unpredictable API limits, engineering leaders often reach the same conclusion: "We will just drop the vendor and build the direct integrations ourselves. It is just a few REST API calls."

This is the integration iceberg. The initial HTTP request is the 10% visible above the water. The remaining 90%—authentication flows, token rotation, rate limit backoffs, cursor-based pagination, undocumented edge cases, and webhook signature verification—will completely derail your product roadmap.

Nobody estimates this honestly at the start. The estimate is always a few REST calls and an OAuth flow. The real work shows up later: permission drift, per-tenant credentials, sandbox weirdness, vendor-specific search syntax, optional custom objects that become mandatory for enterprise customers, and rate limits that are either badly documented or not documented at all.

Let's make this concrete. Say your team estimates 4 weeks (one engineer sprint) to build a single integration with Salesforce. At a fully-loaded Bay Area engineering cost of $200K/year, that's roughly $15,000-$20,000 for the initial build. But that's just the beginning:

• Year 1 maintenance: Salesforce deprecates an API version, changes their OAuth flow, or modifies rate limits. Budget 15-25% of the build cost.
• Year 2 maintenance: A customer's Salesforce instance has custom objects you didn't account for. Another customer hits edge cases in your pagination logic.
• Year 3+: The engineer who built it left. Nobody fully understands the code. Maintenance costs climb to 20-40%.

If your team maintains 20 direct integrations, you are statistically guaranteed to face a breaking change every single month. Instead of shipping core product features, your senior engineers are relegated to parsing cryptic 400 Bad Request errors from legacy SOAP APIs.

Consider the reality of webhooks. You do not just set up an endpoint and receive JSON. You have to handle HMAC signatures, JWT verification, and basic auth. Slack requires a specific URL verification challenge handshake. Microsoft Graph requires you to actively renew subscription leases or the webhooks silently stop firing. Maintaining this infrastructure requires dedicated engineering headcount.

For a comprehensive analysis of the engineering hours required to maintain custom connections, see our guide on Build vs. Buy: The True Cost of Building SaaS Integrations In-House.

How Truto Breaks the Cycle: Pay Per Integration, Not Per Customer

Truto was engineered specifically to break this cycle. We charge by the integration (connector), not by the connection, the linked account, or the API call.

If your platform supports Salesforce, HubSpot, and Zendesk, you pay for those three integrations. Whether you have 10 customers connected to them or 10,000 customers connected to them, your infrastructure cost remains exactly the same. This includes unlimited connections, unlimited companies, and unlimited API calls.

This model aligns perfectly with B2B SaaS unit economics. As you scale your user base, your integration costs remain flat, allowing your margins to expand. You capture the financial upside of your growth, rather than handing it over to your infrastructure provider.

Let's run the same scenario from earlier:

The "Flat" in Truto's column is the point. If you're using 15 connectors with Truto, your cost is determined by those 15 connectors whether you have 10 customers or 10,000. Your unit economics actually improve as you grow, because the integration cost per customer drops with every new signup.

This predictable, flat-rate pricing applies across our entire platform. Developers can utilize both our Unified API for normalized data schemas, and our Proxy API for direct, unmapped access to third-party endpoints. If a customer needs to hit a highly specific, custom resource in NetSuite, you simply pass the request through the Proxy API using the exact same authentication context. There are no arbitrary paywalls forcing you into enterprise tiers just to make a custom HTTP request.

Zero-Code Architecture: Why We Can Afford to Price Differently

How can Truto offer flat pricing when competitors demand $65 per connection? The answer is not a loss-leader strategy; it is a fundamental difference in software architecture. Pricing isn't just a business decision. It's an architecture decision.

Legacy unified API platforms are built using the Strategy Pattern. Behind their unified facade, they maintain separate, hardcoded logic paths for every single integration. It's an adapter farm: one path for HubSpot, another for Salesforce, another for NetSuite.

Every time they add a new integration, they write new code, create new database columns, and deploy new microservices.

// The legacy, code-heavy approach
if (provider === 'salesforce') {
  return {
    first_name: response.FirstName,
    last_name: response.LastName,
    created_at: response.CreatedDate
  }
} else if (provider === 'hubspot') {
  // entirely different logic path
}

When a customer needs a custom field mapped, the vendor has to manually update their codebase or force the customer to write complex passthrough logic. Their maintenance burden scales linearly with the number of integrations and the number of custom configurations. They must charge high per-connection fees because their internal operating costs are massive.

Truto uses the Interpreter Pattern. We built a platform with zero integration-specific code.

Our entire runtime engine—including the unified API, the proxy layer, sync jobs, and webhooks—contains no conditional logic for specific providers. There is no if (provider === 'hubspot') anywhere in our core execution path. Adding an integration is a data operation, not a code operation.

Integration behavior is defined entirely as declarative configuration blobs stored in a generic database schema.

# The Truto data-driven approach
integration:
  base_url: 'https://api.vendor.com'
  auth: oauth2
  resources:
    contacts:
      list:
        path: '/v1/contacts'
        response_path: 'items'

When a request enters the Truto pipeline, the generic execution engine loads the Integration Config (which describes how to talk to the API, including base URLs, auth schemes, and pagination rules) and the Integration Mapping (which uses JSONata expressions to translate data between the unified schema and the native API format).

JSONata: The Universal Transformation Engine

JSONata is a Turing-complete functional query language designed specifically for reshaping JSON. It allows us to handle incredibly complex data transformations entirely within a declarative string.

/* Truto's JSONata mapping */
response.{
  "id": $string(Id),
  "first_name": FirstName,
  "last_name": LastName,
  "email_addresses": Email ? [{"email": Email, "is_primary": true}] :[],
  "created_at": CreatedDate
}

The same code path that handles a HubSpot CRM contact listing also handles Salesforce, Pipedrive, Zoho, and every other CRM. Adding a new integration is a data operation—someone writes a JSON config describing the API and JSONata expressions for field mapping. No code changes, no deployment, no risk to existing integrations.

This is why the marginal cost of supporting one more customer on an existing integration is essentially zero. The config is already written. The engine is already running. There's no per-customer overhead in the architecture, so there's no per-customer overhead in the pricing.

To understand exactly how this engine evaluates complex requests without branching logic, read Look Ma, No Code! Why Truto’s Zero-Code Architecture Wins.

Solving the Schema Rigidity Problem

Because our architecture is entirely data-driven, we solved the schema rigidity problem that plagues other platforms.

Competitors force you into rigid schemas. If your enterprise customer has a heavily customized Salesforce instance with proprietary fields, those fields are stripped out by the unified API. Getting them back requires expensive enterprise contracts or abandoning the unified API entirely. You can learn more about why rigid schemas fail in Your Unified APIs Are Lying to You: The Hidden Cost of Rigid Schemas.

Truto solves this via our three-level override hierarchy:

• Platform level: Default mappings that work for most customers.
• Environment level: Your team can override any mapping—response fields, query translations, default values—without affecting other environments.
• Account level: Individual connected accounts can have their own mapping overrides. If one customer's Salesforce instance has custom fields that need special handling, only that account is affected.

All of this is configuration, not code. No deployment needed. No tier upgrade required. A customer needs a custom __c field from Salesforce included in the unified response? That's a mapping override that takes minutes to configure, not a feature gate that costs thousands more per year.

Because our maintenance burden does not scale with your customer count or your customization needs, we do not need to tax your growth. If you want a deeper dive into how this impacts product velocity, read 3 models for product integrations: a choice between control and velocity.

Making the Decision: A Framework for Evaluating Unified API Pricing

Before signing or renewing any unified API contract, use this checklist to model your true costs:

1. Project your linked account growth over 24 months. Not your customer growth—your linked account growth. If your product supports 3 integration categories and adoption rates are 60-80%, multiply your projected customer count by 1.8-2.4 to get your linked account count.

2. Ask what exact unit is billed. Linked account, consumer, request, connector, or something fuzzier.

3. Ask which states still count. Do idle accounts still bill? Disconnected accounts? Sandboxes? Webhooks?

4. Model ugly workloads. Don't just model the demo workloads. Include pagination, retries, historical backfills, webhook fan-out, and month-end spikes. If you are on an API-call pricing model, these will destroy your margins.

5. Factor in the customization tax. Ask where custom fields live. Are they included in the base plan, gated behind a contract tier, or pushed to professional services?

6. Ask how missing endpoints are handled. Do you have to wait for a roadmap ticket, can you use raw passthrough, or is there a configurable extension?

7. Don't forget the build-in-house comparison. Looking at software's total cost over its lifetime, maintenance typically accounts for 50-80% of expenditures. The integration you can build in two weeks will cost you for years.

Stop Paying the Growth Tax

B2B SaaS integration should be a solved infrastructure problem, not a recurring penalty on your balance sheet. Whether you are paying $65 per linked account, bleeding margin on API call overages, or burning engineering hours maintaining custom code, you are sacrificing your own margins to compensate for inefficient architecture.

Truto's zero-code architecture decouples the cost of running integrations from the number of customers using them. You pay for the integrations you need, and you scale your user base without fear of an exploding infrastructure bill. Growth stops looking like a billing bug. The integration layer starts behaving like product infrastructure.