Your embedded iPaaS pricing model is making decisions for your engineering team, whether you realize it or not. When the bill goes up every time a sync runs, the rational move is to throttle, skip backfills, and limit field coverage. Tenant-based pricing removes that pressure entirely, and the difference shows up in the product your customers actually experience.
TLDR:
- Usage-based iPaaS pricing turns into a variable tax on success: a $50/month workflow can hit $5,000 at production scale
- Tenant-based pricing ties your integration costs to customer count, so your margins stay predictable as you grow
- True TCO includes vendor fees, engineering maintenance time, and opportunity cost: more than just the line item on the pricing page
- Watch for how vendors count multi-connector tenants: some bill per linked connector, quietly tripling your expected costs
- Hotglue bills per active tenant on a 30-day rolling window, keeping total integration spend under 10% of a customer's MRR
What Embedded iPaaS Pricing Actually Measures
Pricing an embedded integration layer is genuinely awkward. You are not selling seats. You are not selling storage. You are selling the ability to connect your customers' data to other systems, and that defies the usual SaaS billing playbook.
Vendors have landed on several competing units of measure:
- Tasks or operations, where each API call or record processed adds to your bill
- Workflow runs, where each automation triggered counts against your quota
- Monthly active records (MAR), which tracks volume of data moving through the system
- Seats, which charges based on users with access
- Tenants, which charges based on connected end customers
The unit you choose determines everything downstream. Charge by tasks and your bill grows every time a customer syncs a large dataset. Charge by seats and you are measuring the wrong thing entirely, since the engineer who configured the integration is not the one generating value. The CPO trying to forecast integration costs needs a number that tracks with how their product actually grows, not a variable that spikes whenever a customer runs a backfill.
The Common Pricing Models Used in Integration Tools
Each pricing model in the embedded iPaaS space works from a different assumption about what "usage" means.
| Pricing Model | Billing Unit | Predictability | Best Fit | Watch Out For |
|---|---|---|---|---|
| Task-based | Per API call / trigger | Low: spikes with sync volume | Low-volume automations | Bill explodes when customers sync large datasets |
| Record / MAR-based | Rows or monthly active records | Low: scales with data growth | Internal analytics pipelines | A $50 prototype can reach $5,000 at production scale |
| Workflow flat fee | Per workflow or automation | Medium: fixed per workflow | Simple, stable automations | Costs multiply as connector count grows |
| Credit-based | Credits per operation complexity | Low: vendor sets credit costs | Mixed-complexity workflows | Budgeting requires guessing at credit burn rates |
| Seat-based | Per user with tool access | High, but misaligned unit | Internal SaaS tooling | Measures the wrong thing for embedded use cases |
| Tenant-based | Per connected end customer | High: scales with customer count | Customer-facing embedded iPaaS | Confirm how multi-connector tenants are counted |
Why Usage-Based Pricing Breaks Down at Scale
Usage-based integration pricing feels fair until your product succeeds. Then it becomes a penalty. Congratulations on your growth. Here's your surprise invoice.
As Truto notes, this model turns your integration layer into a variable tax that scales with customer success. Your customers sync more CRM contacts, more support tickets, more accounting records, and your vendor bill climbs in lockstep. Gross margin stops scaling with you. Your integration cost does.
The prototype-to-production gap makes this worse. A workflow costing $50 a month in testing can reach $5,000 a month once real customers run real syncs at real volumes. That's a foreseeable outcome of picking the wrong billing unit, and by the time you notice, you're already mid-renewal.
Hidden Costs That Don't Appear in the Pricing Page
Before signing anything, ask your vendor these specific questions:
- Which connectors are included in my base plan, and which require a premium add-on?
- Is there a surcharge for AI-assisted mapping or LLM-powered features?
- How are failed syncs and retries billed? Do I pay for the attempt or only the success?
- What triggers an overage, and how much does it cost per unit above my limit?
- Who handles API schema changes when a third-party updates their endpoints?
That last question is where hidden costs get serious. When Salesforce or QuickBooks updates an API, someone has to rewrite the connector. If your vendor does not handle that, your engineering team does. At typical senior developer rates, a single connector rebuild can run several days of work, and the average production SaaS product touches dozens of third-party APIs.
Overage fees compound the same way. A customer runs a historical backfill, volume spikes for one billing period, and you absorb a charge that had nothing to do with new customer growth. Credit-based models are especially prone to this since complexity costs are assigned by the vendor, not negotiated by you.
Get overage rates in writing, ask explicitly about connector tiers, confirm who owns API maintenance, and model your bill at 3x your current data volume before you sign.
How to Calculate the True TCO of SaaS Integration Costs
True TCO breaks into three buckets most procurement checklists miss.
The first is your vendor license or usage fee. The second is internal engineering time: initial setup, ongoing maintenance, debugging failed syncs, and responding when a third-party API changes its schema. The third, and most overlooked, is opportunity cost. Every hour an engineer spends maintaining a Salesforce connector is an hour not spent on the feature your customers actually asked for.
That math gets uncomfortable fast when you build in-house. According to Albato's embedded iPaaS breakdown, building integrations in-house costs $50,000 to $200,000 per connector and takes 3 to 6 months to ship. Multiply that across five connectors and you're looking at a multi-year engineering commitment before a single customer syncs anything. For teams weighing the decision, what embedded iPaaS is and what it handles becomes the baseline for any accurate cost comparison.
A simple framework for your TCO calculation:
- Vendor fee, including license, usage, and overages
- Engineering hours multiplied by loaded hourly rate, covering setup and annual maintenance
- Connectors needed, multiplied by expected maintenance events per year
- Opportunity cost: what could those engineering hours build instead?
The pricing model you choose affects all three buckets. A volume-based model keeps your vendor fee unpredictable, which makes the full TCO nearly impossible to model accurately before you sign.
Why Tenant-Based Pricing Aligns With How B2B SaaS Actually Grows
Tenant-based pricing charges you for connected end customers, full stop. One tenant syncing 50,000 records costs the same as that tenant syncing 500,000. The billing unit is the relationship, not the data volume.
This aligns cleanly with how B2B SaaS revenue actually works. When you close a new customer, your MRR goes up. With tenant-based pricing, your integration cost goes up by one tenant fee. The ratio stays roughly constant, which means you can model your integration spend as a predictable percentage of revenue, not a variable that reacts to customer behavior you can't control.
The definition of "active tenant" matters more than it sounds. At hotglue, billing counts only tenants active within a 30-day rolling window following a sync. A customer who connected once and went dormant stops counting. That prevents the common trap where ever-connected accounts accumulate on your bill long after the integration stopped running, a real problem with flat monthly seat counts applied to integration tools.
Your integration costs grow when your customer count grows, slow when churn happens, and stay flat when existing customers start syncing more data. That's the closest thing to a naturally hedged cost structure that embedded iPaaS pricing offers.
What to Watch Out For in Tenant-Based Pricing
Before committing to any vendor's tenant model, press on three specific questions.
The first is how multi-connector tenants are counted. If one customer connects QuickBooks, Salesforce, and Shopify, does that count as one tenant or three? Some vendors bill per linked connector, which quietly turns a 100-tenant deployment into a 300-unit bill. With hotglue, a single tenant connecting to multiple connectors counts once.
The second is how the billing window works. A tenant active on the last day of one month and the first day of the next could trigger charges in both periods. Hotglue's 30-day rolling window prevents dormant or low-frequency tenants from accumulating charges across billing periods.
The third is whether high-volume, low-value deployments have any protection. A flat per-tenant rate without volume tiers can compress margins fast for SaaS products serving hundreds of SMB tenants. Ask whether the vendor offers tiered rates above certain tenant thresholds before you model the long-term economics.
These are the gaps where "tenant-based pricing" stops being predictable and starts resembling the usage-based models it was supposed to replace. When choosing an embedded iPaaS, pressing vendors on these specifics before signing is one of the most important steps in the evaluation process.
How Pricing Models Vary Across the Embedded iPaaS Market
Each pricing model in the embedded iPaaS market traces back to a vendor's core architecture.
Warehouse-centric pipeline tools like Fivetran are built around data volume, so MAR-based pricing follows naturally. That works for internal analytics workloads, but gets expensive fast when your customers trigger syncs based on business events instead of scheduled bulk loads.
Workflow automation tools like Workato charge per task or recipe execution. For customer-facing integrations where a single sync touches thousands of records across multiple objects, the meter runs fast.
Unified API abstraction layers tend toward call-volume or sync-based models, since their architecture revolves around real-time API requests.
Embedded iPaaS tools built for customer-facing integrations land most naturally on tenant-based pricing because connectors, jobs, field mappings, and sync histories are all scoped to the end customer. Charging per tenant is a direct reflection of how the product actually works.
When a vendor's pricing feels misaligned with your growth, it's usually because their architecture was designed for a different use case than yours.
The Pricing Model Your Engineering Team Will Thank You For
Pricing decisions get made in finance meetings, but engineers live with the consequences.
When your bill climbs every time a sync runs, the rational engineering response is to throttle: reduce sync frequency, limit field coverage, avoid full backfills. Every one of those choices is a quiet degradation of the integration your customers are actually using, not because your team made a bad technical call, but because the pricing model created the wrong incentive.
Tenant-based pricing removes that pressure. When the bill is fixed per connected customer regardless of sync volume, there's no reason to artificially cap how much data moves or how often. Your team can run complete backfills on onboarding, sync hourly instead of nightly, and cover every field the connector supports without mentally accounting for overages.
That freedom shows up in real decisions:
- Sync frequency: your team sets it based on what customers need, not what keeps the bill flat
- Backfill strategy: new customer onboarding can pull full historical data without a cost spike
- Field coverage: connectors can map every relevant field instead of trimming to reduce record counts
- Retry logic: failed syncs can be retried aggressively without cost anxiety on each attempt
The integration your customers experience is a direct reflection of the decisions your engineers were free to make. Tie those decisions to a usage meter and you get a quieter, cheaper, worse integration. Tie them to tenant count and you get one that's built to actually work.
How hotglue Approaches Embedded iPaaS Pricing
Hotglue prices on active tenants within a 30-day rolling window following a sync. A tenant who connects once and goes quiet stops counting. A tenant who syncs across a month boundary gets counted once. One customer connecting QuickBooks, Salesforce, and Shopify is still one tenant.
The base license runs $1,500 to $2,500 per month, with a per-active-tenant fee that typically keeps total integration spend under 10% of a customer's MRR. Across 38,000+ active tenants processing roughly 10 billion records weekly, that structure holds.
The Inventoro team shipped 40+ integrations in their first three months on hotglue. Under a record-volume or per-task model, that pace would have produced a bill that made the whole exercise financially unworkable. Under tenant-based pricing, it produced a cost that scaled with their customer count, not their sync activity.
Final Thoughts on Embedded iPaaS Pricing Models and True SaaS Integration Cost
The billing unit your vendor uses will shape how your engineers build, what your customers experience, and how predictable your margins stay as you grow. Tenant-based pricing keeps that relationship simple, and hotglue's implementation of it is the most straightforward in the market. One tenant fee, one billing window, no multipliers hiding in the fine print. If you want to run the numbers for your own product, book a demo and we can work through it together.
FAQ
How does Hotglue's per-tenant pricing model work, and can it scale down for high-volume SMB deployments where per-tenant fees need to stay very low?
Hotglue's active tenant pricing counts only tenants that have run a sync within a 30-day rolling window, so dormant or churned customers never accumulate on your bill. A single tenant connecting QuickBooks, Salesforce, and Shopify counts as one tenant, not three. For high-volume SMB deployments, ask vendors directly about tiered rates above certain tenant thresholds before modeling long-term economics, since a flat per-tenant rate without volume tiers can compress margins fast when you're serving hundreds of small accounts.
What commercial pricing models does Hotglue support for partners, and how does total SaaS integration cost scale as a partner grows?
Hotglue supports multiple commercial structures, including direct billing to the end customer, referral arrangements, and reseller models. The base license runs $1,500 to $2,500 per month, with a per-active-tenant fee structured to keep total embedded iPaaS pricing under 10% of your MRR. As your customer count grows, integration cost grows by one tenant fee per new customer, and the ratio stays roughly constant, which makes forecasting straightforward instead of a monthly guessing exercise.
How do I calculate the true TCO of SaaS integration costs before signing with an embedded iPaaS vendor?
Start with four buckets: vendor license plus overages, internal engineering hours multiplied by your loaded hourly rate, expected maintenance events per connector per year, and opportunity cost from engineering time diverted from product work. Building in-house runs $50,000 to $200,000 per connector and takes three to six months; multiply that across five connectors and the math gets uncomfortable quickly. Model your vendor bill at 3x your current data volume and get overage rates, connector tier structures, and API maintenance responsibilities confirmed in writing before you sign.
Embedded iPaaS vs building integrations in-house: what should a B2B SaaS product team actually choose?
For most B2B SaaS teams, the hidden costs of building in-house (API schema changes, connector rebuilds, ongoing maintenance) consume far more engineering time than the initial build. A single Salesforce or QuickBooks API change can run several days of senior developer time, and production SaaS products typically touch dozens of third-party APIs. An embedded iPaaS like Hotglue handles API maintenance, authentication, and connector updates, freeing your engineers to build the product features customers actually asked for.
What should I watch for when comparing tenant-based pricing across embedded iPaaS vendors?
Three questions separate genuine tenant-based pricing from a usage-based model in disguise. First, ask whether multi-connector tenants count as one or many, because some vendors bill per linked connector, which quietly multiplies your bill. Second, confirm how the billing window works, since a tenant active across a month boundary could trigger charges in both periods. Third, ask whether there are volume tiers at higher tenant counts, especially if your product serves a high volume of SMB customers where per-tenant economics need to stay predictable at scale.