Blog
Integration Hub is priced by transaction volume, and the transaction is where the meter runs. Here is how the cost actually accrues and where buyers overpay.
ServiceNow Integration Hub transaction cost is driven by one unit, the transaction, and understanding what counts as one is the difference between a commitment that fits and a bill that surprises you. A transaction is an outbound execution of an integration through the hub, and packs are sold in committed volumes per year. The cost is not the per transaction rate on its own. It is the committed pack size, the uplift on that commitment, and the overage rate that applies once you run past the balance. Buyers who price only the headline pack and ignore the overage mechanics are the ones who get the year end top up charge they did not budget for.
A transaction is generally counted each time an integration executes through the hub, so a single business process that calls three external systems can consume three transactions, not one. High frequency automations, record syncs and scheduled jobs are the usual sources of volume that grows faster than anyone forecast. Before committing to a pack, instrument the actual execution count over a representative month and project it across the full term, because the meter does not care how valuable the integration is, only how often it fires.
Integration Hub transaction packs are committed annual volumes. You agree a balance, you pay for it whether or not you use it, and you pay again at an overage rate for anything beyond it. The overage rate is where the real exposure sits, because it is typically less favourable than the committed rate and it triggers as top up charges once the balance is gone. The asymmetry is deliberate. A pack sized comfortably below your real usage looks cheap at signing and becomes expensive in month nine when the overage clock starts.
Two opposite mistakes both cost money. Oversizing the pack to be safe means paying every year for committed volume that goes unused, and that committed number then carries the annual uplift, typically in the 7 to 12 percent range based on benchmark observations. Undersizing the pack means walking into overage at an unfavourable rate. The right size sits at realistic projected usage with a modest buffer, paired with the right to true up at the committed rate rather than the overage rate if you cross the line. Without that true up right, growth is punished twice, once by the overage rate and again at the next renewal when the base resets higher.
Under the Foundation, Advanced and Prime model the integration consumption mechanic sits alongside metered AI assists, and the two are easy to confuse on a quote. Now Assist actions are metered as assists, with large agentic actions consuming materially more, while Integration Hub usage is metered as transactions. Keep the two lines separate in your own model so you can see which commitment is driving cost. An integration heavy estate and an AI heavy estate have very different exposure profiles, and a quote that blends them hides which one you actually need to negotiate.
Right sizing starts with measured usage, not the vendor estimate. Pull the real transaction count, project it conservatively, and commit to a pack that matches projected usage with a small buffer rather than the comfortable round number the account team suggests. Then negotiate the overage terms before signing, because they are far harder to change once you are over the balance. Secure a true up at the committed rate, a cap on the annual uplift applied to the commitment, and clarity on exactly what the hub counts as a transaction.
Integration Hub is one line in a wider estate where the same right sizing logic applies across modules. Our explainer on ServiceNow Integration Hub transactions breaks down the counting in more depth, and the same discipline applies to ServiceNow App Engine licensing, where seat and pack definitions drive cost the same way. When the estate is large, a ServiceNow licensing advisory review maps every metered line so the integration commitment is sized against real usage rather than a vendor forecast.
Consider an estate that commits to a transaction pack sized on the first month of integration activity. In that month a handful of automations fire predictably and the pack looks generous. Over the following two quarters new integrations come online, a record sync is switched from daily to hourly, and a single business process that calls three external systems is rolled out across more teams. Each of those changes multiplies transactions without anyone deciding to spend more. By month nine the committed balance is gone and overage begins at the less favourable rate. The lesson is that transaction volume grows with adoption and process change, not with a budget decision, so the commitment must be sized on where the estate is heading rather than where it starts.
Beyond sizing the pack itself, three contract points decide your exposure. The first is a true up at the committed rate so growth is not punished at the overage rate. The second is a stated cap on the annual uplift applied to the committed volume, holding it well below the 7 to 12 percent range that applies before negotiation based on benchmark observations. The third is a clear written definition of what the hub counts as a single transaction, because the difference between counting a process once and counting each system call separately can change the bill several times over. Settle all three before signing, because each becomes far harder to move once you are already over the balance.
The buyer side summary is straightforward. Treat the transaction as the unit that drives cost, measure how many you really execute, and size the pack on where the estate is heading rather than where it starts. Then negotiate the overage rate, the true up and the uplift cap before signing, because every one of those terms is far cheaper to secure in advance than to renegotiate once the meter has already run past your committed balance.
Cost is driven by committed transaction packs sold in annual volumes, plus an overage rate for anything beyond the committed balance. A transaction is counted each time an integration executes through the hub, so a process calling several systems can consume several transactions.
Once the committed balance is used, overage applies at a rate that is typically less favourable than the committed rate, billed as top up charges. Securing a true up at the committed rate before signing protects you from being charged the overage rate when usage grows.
Measure real transaction execution over a representative period, project it conservatively across the term, and commit to a pack that matches projected usage with a small buffer. Negotiate overage terms, a true up right and an uplift cap before signing rather than after.