Monetisation will not pay for your platform

In one API management business case out of three, monetisation shows up on the revenue line: "in time, the platform will pay for itself by selling APIs". It is one of the most effective arguments in an investment committee, and one of the least kept promises on the market.

The monetisation module itself works fine. What is missing is everything else.

Why it almost never happens

You need a product, not an API. An API that sells is an API from which someone outside draws measurable value, with faultless documentation, service guarantees, support. That is a product in the full sense, with a product owner, marketing, a pricing policy. Most APIs put forward for monetisation are internal APIs people hope to sell as they stand. They are worth nothing as they stand.

The market is smaller than expected. Who, precisely, will pay? The honest answer is often: the existing partners, who already paid for the service another way, and for whom per-call billing sometimes damages the relationship more than it brings in.

Billing is a trade of its own. As soon as a call costs money, every counting error becomes a dispute. You need legally binding statements, credit note handling, alert thresholds on the customer side, a billing support desk. The platform module counts calls, it does none of that.

The gateway counter is not a source of truth

This is what sinks the projects already under way, and it is technical. A monetisation module counts what the gateway saw. The customer, for its part, argues from what it sent, and the two numbers always differ.

They differ for perfectly ordinary reasons. Gateway metrics are often aggregated and sometimes sampled, a reasonable performance choice and an accounting disaster. An instance restart loses the in-memory counters not yet exported. Calls rejected upstream, quota exceeded or invalid token, are counted here and not there. And a response served from an edge cache never reaches the counter.

A billing system needs the opposite of a metric. It needs one record per billable event, immutable and timestamped. A unique identifier per event, which makes replay idempotent. Retention at least as long as the dispute window written into the contract. And a monthly reconciliation against the total invoiced.

These four properties turn up in every usage billing system, at a telecoms operator as much as at a cloud provider. No gateway delivers them by default. Hence the first question to put to the vendor selling the module: does your counter produce reconcilable individual events, or aggregated series? The second answer means the billing is still to be built.

What counting really earns you

The good news is that monetisation infrastructure has one use that pays off almost every time: internal chargeback, or even its invoice-free version, plain visibility of consumption.

Publishing every month who consumes what, in volume and in allocated infrastructure cost, changes behaviour more surely than any standard: runaway batch jobs get fixed, caches appear on the consumer side, capacity is sized on figures. That is governance by transparency, and it needs neither a contract nor a billing desk.

If you really do want to sell

There are legitimate cases: rare data, a service that is hard to replicate, a marketplace position. If you are in one of them, treat it as a product launch, not as an option of the platform:

1. a named product owner, whose main objective this is.
2. a willingness-to-pay study run with real prospects, before any development.
3. simple pricing to start with: monthly tiers rather than pay per call, to limit the dispute machinery.
4. service terms written down and actually achievable, backed by your real observability.
5. the billing chain plugged into the company's billing systems, not into the gateway module.

Two subjects are always discovered too late, and neither is technical. Tax first. Selling API calls to customers in several countries is a sale of electronic services, with VAT rules that depend on the customer's country and on its VAT status. No API management module knows them.

Collections next: reminders, service suspension for non-payment, credit notes. These are company processes, and they decide whether the revenue is collected or merely invoiced.

And above all: a kill threshold decided in advance. If revenue at twelve months is below the cost of the setup, you stop. Zombie monetisation, kept alive because it was in the business case, is a cost line dressed up as a revenue line.

The line to write in the business case

Instead of "the platform will pay for itself", write: "the platform will make consumption visible and chargeable". That is fundable, it holds from the first year, and it does not force you to invent a market.

The full business case, line by line, is the subject of What an API management platform really costs. Monetisation appears there, in its place: an uncertain option, never a pillar of the funding.