Doing This Yourself

You do not need a platform to put a stand-in behind a gateway. Any competent API gateway can route to a temporary backend, and any competent mocking tool can be that backend. If you have both and a free afternoon, you can reproduce the first day of this.

It is worth being honest about that, because the interesting question is not day one.

What has to agree

For a partner to integrate against a stand-in and keep working when the real service arrives, five things have to say the same thing:

1. The contract — the paths, methods and shapes the partner writes against.
2. The gateway’s routes — what it accepts, and where it sends it.
3. The stand-in’s responses — what comes back while there is no implementation.
4. The credentials and scopes — what each partner is allowed to call, issued to them individually, from something that knows what the contract’s operations are.
5. The real implementation — which has to match all four when it arrives.

Get those five agreeing once and you have a working demonstration. The trouble is that a contract is not finished on day one — it changes the moment a partner reads it properly, and again when you discover something while building.

What each change costs, assembled

A single change to the contract — one added field, one renamed property — has to be carried into the gateway’s routes, the stand-in’s responses, any scope that changed, and the implementation. Four places, by hand, in the right order, with no single thing telling you when one of them is behind.

Nobody owns that. Your gateway does not know about your mocking tool. Your mocking tool does not know who your partners are. Neither knows what scopes you issued. The only place they are connected is somebody’s memory, and the failure is silent: a partner integrates against a stand-in that no longer matches the contract the implementation is being built to, and everybody finds out at cut-over.

The part that is usually underestimated

Statefulness is the one people cost as “a few days”. Making a mocking tool remember what a caller created — so a partner can create something on Tuesday and fetch it on Wednesday — is scripting, per resource, maintained as the contract changes. Then it is thrown away when the real service arrives, because it was never the thing you were building.

The part that is usually costed at zero

A gateway routes and enforces. It does not issue credentials. So “each partner gets their own client id and secret, scoped to what they may call” needs an authorisation server as well — and then the two have to be introduced to each other, and both have to be told what the contract’s scopes are.

That is a setup cost once, and an operation per partner forever: register a client, mint a secret, decide its scopes, map them to operations, hand them over securely. Whoever owns the identity system does that, which means a request, a queue and a wait. Several gateways offer API keys from a portal instead, which avoids the queue and gives you a different thing — a key is not a credential with scopes, and it will not carry an identity through to your service.

It is worth testing this on the second partner rather than the first. The first is a setup task and feels like progress. The second is the one that tells you whether onboarding is self-service or a ticket.

We have built this part by hand twice, on two different commercial gateways — once at a global bank and once at a startup, a year each time. In both cases the gateway itself was running in the first week. What took the year was the three things it did not come with: the authorisation server — issuing credentials per consumer, scoped to operations, revocable, and trusted by the gateway — the access control deciding what each consumer may reach, and the deployment management that gets a release onto the gateway repeatably.

That is not an argument that you could not do it. It is the reason we know what it costs, and why all three are line items most often estimated in days. Note which part was quick: buying and standing up the gateway was never the hard bit, and it is the part the licence pays for.

Twice matters more than once. Two different products, two different companies, the same year — so it is not a story about one platform being awkward. It is what the work is. And at the end of both, the result still did not join up with how releases were actually shipped, which was a separate project again.

What is different here

The five things do not have to be kept in agreement, because there is only one of them. The contract is what the gateway routes by, what the stand-in answers from, what the partner’s credentials are scoped against, and what the implementation is verified against. A change to it is a change everywhere at once, because there is no “everywhere” — there is one document and a set of views generated from it.

That is also why the stand-in is stateful without being scripted, why partners get their own credentials without anyone issuing them by hand, and why replacing the stand-in with the real service changes nothing a partner can see.

When assembling is the right answer

If you need a mock for a fortnight, build it with a mocking tool and throw it away. If the partners are internal and will tolerate a URL change, most of this does not apply. If you already run a gateway and your team has capacity this quarter, you may well prefer to keep what you know.

The case for not assembling is not that it cannot be done. It is that the cost is not the setup — it is every change after it, for as long as the product lives.

See also: From Mock to Real · Mock Data