Inventory and policy
What exists, who owns it, who calls it, and the written rules that will govern it. Short, and the output is an inventory with a decision attached to every row.
The API practice
API management in Saudi Arabia
An organisation usually discovers it needs API management the day it counts its APIs and gets a different answer from every team. This practice is about putting one layer in front of them that knows what they are, who may call them, and what happens when one changes.
In short
One layer that knows every API, and enforces the same rules on all of them
Interkey designs, implements and operates the API layer for organisations in Saudi Arabia: the inventory of what exists, the policies that apply to it — authentication, authorisation, rate limits, versioning — the gateway that enforces them, and the operation of that gateway afterwards. The platform Interkey implements for the gateway is Kong; the practice is the same whichever product ends up underneath it.
The scope is deliberately bounded. Connecting two systems that were never designed to talk to each other is systems integration, and building the service behind an API is software development. This page is about the layer in front of services that already exist: making them discoverable, governed and safe to expose to a partner, a mobile application or another department.
The reason it is worth a practice of its own is that the gateway is the easy part. Any team can stand one up in a week. What takes an engagement is deciding what goes through it, under which rules, owned by whom, and what a consumer is told when a version is retired.
Symptoms
What this looks like before it is fixed
The states organisations describe, and what each usually indicates. Very few of them are described by the people experiencing them as an API problem.
| What you observe | What it actually indicates | Where to start |
|---|---|---|
| Nobody can list the APIs | Interfaces were built per project, each with its own authentication and nobody responsible for the set | An inventory, before any product decision. Discovery is dull and it is the whole foundation: you cannot govern what you have not counted. |
| Every integration partner is onboarded by hand | Credentials, documentation and access are issued case by case, usually by whoever built the interface | A consumer model: who may call what, at what rate, with which credential type. The gateway then enforces a rule that finally exists. |
| A change to one service breaks three consumers | There is no versioning contract, so every change is a breaking change | A versioning and deprecation policy that consumers are told about in writing. The technical work is small; the discipline is the deliverable. |
| Security reviews stall the release | Each service handles authentication its own way, so each is reviewed its own way | Centralise authentication and authorisation at the gateway. One review of one layer replaces a review per service. |
| The mobile team built its own back end | The core systems had no safe surface to expose, so a parallel one was created | Expose the core through the governed layer and retire the parallel one. This is often the case that funds the whole programme. |
| An outage cannot be traced to a caller | Traffic is not observed per consumer, so nobody knows who saturated the service | Per-consumer metrics and limits at the gateway, fed into the observability platform the operations team already watches. |
The order
The gateway is step three
Programmes that start by installing a gateway end up with a gateway in front of an inventory nobody agreed and a policy nobody wrote. Each step below is only safe once the one before it holds.
-
Inventory what exists
Every interface, its owner, its consumers and how it authenticates today. Including the ones that were never called an API, because a shared database view is an interface whether or not anyone documented it.
-
Write the policy
Who may call what, with which credential, at what rate, and how versions are introduced and retired. Short, written down, and agreed by the teams that own the services rather than imposed on them.
-
Deploy the gateway
Now, and not before. Placed where the residency answer says the traffic may flow, sized for the traffic the inventory found, with the policy expressed as configuration rather than remembered by a person.
-
Onboard consumers
Documentation, credentials and limits issued through one process, and the parallel back doors closed as each consumer moves. The measure of this step is how many hand-built exceptions remain.
-
Operate and observe
Per-consumer traffic, error rates and latency visible to the people who will be paged, an upgrade cadence for the platform itself, and a deprecation calendar that is actually followed.
The constraint
Where the gateway runs is decided by the data passing through it
Control plane and data plane are two different residency questions
An API gateway sees every request and every response. That makes its location a data-classification decision before it is an architecture decision: if the payloads may not leave the Kingdom, neither may the component that inspects them.
The practical shape of it is that most platforms separate the plane that carries traffic from the plane that holds configuration. The traffic plane can run in-Kingdom, on infrastructure the organisation operates, while the configuration plane runs wherever the vendor hosts it — or both can run in-Kingdom, at the cost of operating both. Which of those is right is answered by the classification of the data on the wire and by who is prepared to operate the control plane for years. Interkey deploys either shape, and the Kong page works through the choice for that platform in particular.
Scope
How the work is usually shaped
Four shapes. The first is frequently bought alone, and it decides whether the rest is worth buying.
Gateway implementation
The platform deployed in the residency shape the classification allows, with policy as configuration, and the first consumers moved through it.
Consumer onboarding
Documentation, credential issuance and limits through one process, for partners, mobile teams and internal departments alike, and the hand-built exceptions retired.
Operation
The gateway run as a production platform: upgrades, capacity, per-consumer observability and the deprecation calendar, on the Saudi working week from Riyadh, as a managed service where wanted.
The Saudi layer
What is specific to this market
Two things change the shape of this work here rather than merely translating it.
Published APIs are increasingly a sector requirement, not an engineering preference. Several Saudi sector programmes now expect organisations to expose defined interfaces to regulators, partners or integration platforms, open banking being the best-known example. An organisation meeting such a requirement with a hand-built endpoint per obligation ends up with the symptoms in the table above, on a deadline. The governed layer is what lets the next obligation be a configuration change.
Arabic content passes through the same layer. Payloads carry Arabic names, addresses and free text, and a gateway policy that inspects, logs or transforms them has to handle right-to-left text, mixed-script fields and encoding correctly. This is tested on real local payloads during implementation rather than discovered when a partner’s first Arabic request is rejected.
The work is delivered from Riyadh by the engineering practice that also does systems integration and builds the services behind the APIs, which matters more than usual here: an API layer designed by people who never have to consume it tends to be technically correct and practically ignored.
Definition of done
What finished actually looks like
Each of these is either true or not, and each can be checked by someone who was not involved:
- There is one inventory of APIs, it has an owner per entry, and a new interface cannot go live without joining it
- Authentication, authorisation and rate limits are enforced at the gateway, and no consumer reaches a governed service any other way
- Every API has a version, a deprecation policy its consumers have been told, and a date after which the old version is gone
- A new consumer is onboarded through one documented process, and the number of hand-built exceptions is known and falling
- Traffic, errors and latency are visible per consumer to the people who will be paged
- The gateway’s own location matches the data classification of what passes through it, and the decision is written down
- The platform has an upgrade cadence and a named operator, whether that is your team or Interkey’s
Questions
Questions buyers actually ask
Common question
Do we need an API management platform, or just a gateway?
The distinction is mostly vendor vocabulary. What you need is a layer that enforces policy on traffic and a process that governs what is behind it. If the organisation has a handful of internal APIs and one team, a gateway with written rules is enough. If partners, mobile applications or regulators consume your interfaces, the onboarding, documentation and versioning parts are the work, and a platform that does them is worth its cost.
Common question
Which platform do you implement?
Kong, for the gateway and its policy layer. The practice on this page — inventory, policy, sequence, operation — does not depend on it, and an organisation already committed to another product is not turned away; the inventory and policy work is identical and the gateway is configured rather than replaced.
Common question
Can the whole platform run in-Kingdom?
Yes. The traffic plane can run on infrastructure you operate inside Saudi Arabia, and the configuration plane can too, at the cost of operating it. The residency note above explains why those are two separate decisions and what each costs. What Interkey will not do is assume the answer: it comes from your data classification, not from a deployment preference.
Common question
How long does this take?
The inventory is a matter of weeks and pays back immediately, because knowing what you have is worth having whatever you do next. A first gateway with the first consumers moved is a bounded project. Moving every consumer and retiring every back door is measured in quarters and depends far more on your consumers’ release schedules than on anything Interkey controls.
Common question
What about the APIs we expose to the public internet?
They go through the same layer with a stricter policy: stronger credential types, tighter limits, and a security review of the gateway configuration itself. What the gateway cannot do is make an unsafe service safe; it can enforce who reaches it and how often. The service behind it still has to be built and reviewed properly, which is the software practice’s job rather than this one’s.
From the insights library
The neighbouring decisions
Technology
Kong implementation and operations
The gateway platform Interkey deploys, and the in-Kingdom versus hybrid decision worked through for it specifically.
PracticeSystems integration
When the problem is two systems that cannot talk at all, rather than governing the ones that already can.
PracticeObservability consulting
Where per-consumer API traffic ends up: the platform the operations team already watches.
Explore related solutions
Next step
Start with what you actually expose
Describe the systems that need to talk to the outside world, who consumes them today, and where the data may live. The inventory conversation starts there, before any product does.
Or directly
+966-11-2180999 info@interkey.com.saTawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia