System integration · APIs
API integration services in Saudi Arabia: core systems, ERPs and government platforms
API integration services connect the systems an organisation already runs, so that a customer, an order or an identity check moves between them without being typed twice. Interkey integrates core systems, ERPs, third-party services and national platforms through APIs for organisations in Saudi Arabia, with a governed Kong gateway in front of every interface and Datadog monitoring behind it, so each call is controlled, measured and owned.
In short, for decision-makers
- What gets connected: core and ERP systems, the third-party services you depend on, and national platforms.
- How it stays under control: one gateway applies authentication, limits and logging to every call; one monitoring platform shows when an interface slows or fails.
- Where it runs: the gateway can run self-managed on infrastructure you operate in the Kingdom.
- How it is priced: scoped and quoted per engagement, after an inventory of the interfaces.
At a glance: what the service covers
Each part can be taken on its own; most projects need several of them.
| Area | What it covers | What you have at the end |
|---|---|---|
| Core and ERP systems | Customers, orders, invoices and stock between the ERP and the systems around it | Each record entered once and checked on the way |
| Third-party services | Payment, shipping, messaging and SaaS providers your business relies on | Outside APIs called through one controlled route |
| Government platforms | Identity, e-invoicing and registry services, built to each published specification | A connection that passes the sandbox and holds in production |
| Gateway in front | Kong Gateway: routing, authentication, rate limits, request checks | One policy for every API, kept as code |
| Monitoring behind | Datadog: traces, logs, metrics and scheduled API tests | Failures seen by your team before users report them |
| Support after go-live | Changes, version upgrades, credential renewals, new consumers | Interfaces that keep working when either side changes |
What API integration services have to cover
Writing the code that calls an API is rarely the hard part. The hard part is everything around it: what each field means on both sides, which system owns the record, what happens when the other side is slow or returns an error, and who is told when it breaks. An integration that skips those questions works on go-live day and fails months later, when a field changes meaning or a retry books the same order twice.
Read more
So an engagement starts with an inventory of the interfaces you have and the ones you need, with an owner and a consumer for each. Each interface then gets a short written contract: payloads, frequency, error handling, duplicates and change notice. The contract becomes the test baseline. Our system integration practice describes the wider method; this page covers the API work.
Relatedsystem integration practice
Integrating core systems and ERPs through APIs
Most API projects begin with the ERP: orders from an online store, customers from a CRM, stock for a portal, postings to finance. Where the ERP documents an API, we build against it; where it does not, we expose one in front of its database, files or message queue, so the systems around it see a clean, versioned interface.
Read more
Two rules prevent most failures. An order sent twice must not be booked twice, so every write carries a key that lets the receiver recognise a repeat. And a slow ERP must not take the portal down with it, so calls have timeouts, retries with limits and a clear message to the user. Arabic text, mixed scripts and legacy encodings are tested with real data before go-live. Our ERP integration page lists the common ERP interfaces and the pattern that usually fits each.
Government API integration: national platforms
Many processes in Saudi Arabia end at a national platform: e-invoices to ZATCA's e-invoicing platform (Fatoora), sign-in and identity checks through Nafath, commercial-registration data from Wathq. Each platform publishes its own specification, onboarding steps and sandbox, so each is its own integration. The registration and the credentials remain your organisation's; Interkey builds, tests and operates your side of the connection.
Read more
Government API integration needs more care than most: certificates and tokens that expire, versions that change on the platform's timetable, and submissions that must not be sent twice. Each version and certificate is recorded in the interface contract, with the person on your side who receives the platform's change notices. Our Nafath integration page sets out the Nafath flow, and the guide to Saudi digital platforms covers the others.
Third-party API integration: payment, shipping and SaaS providers
A third-party API is one you call but do not control. Its provider can change it, limit it or take it offline for maintenance. Third-party API integration therefore needs three things that internal interfaces can sometimes do without:
- One route out: calls to outside providers go through the gateway, so keys are held in one place and every call is logged.
- A plan for failure: what your system does when the provider is down, whether to queue, retry or tell the user.
- A watch on change: the provider's version notices are tracked, and each change is tested before it reaches production.
A Kong gateway in front, Datadog monitoring behind
An integration estate without a gateway grows one rule at a time: each service checks callers its own way, sets its own limits and logs in its own format. Interkey puts Kong Gateway in front of the APIs instead. Authentication (keys, JWT or OAuth 2.0), access lists, rate limits per consumer and request checks are applied in one layer, defined in version-controlled configuration and reviewed like code. The gateway can run self-managed on infrastructure you operate in the Kingdom, so payloads it inspects stay there. Our API management practice covers the policy behind it, and the API gateway page compares the ways to deploy Kong.
Read more
Behind the gateway, Datadog shows what each interface is doing. Traces follow a slow call from the gateway into the service behind it, logs show which consumer sent the failing request, and scheduled API tests call critical endpoints, including from a private location inside your network. Monitors alert the owning team when error rates rise or an interface stops sending. See Datadog Synthetic Monitoring for how API tests work.
Which approach fits each kind of interface
| Interface | Approach that usually fits | What to watch |
|---|---|---|
| Portal or app to core systems | Versioned API through the gateway | Load on the core system at peak times |
| ERP to CRM or online store | API through the gateway; events when several systems need the same change | Which system owns the customer record |
| Your systems to a third-party provider | Outbound calls through the gateway, keys held centrally | Provider limits, outages and version changes |
| Your systems to a national platform | API built to the published specification, tested in its sandbox | Expiring credentials and duplicate submissions |
| Legacy system without an API | An API exposed in front of its database, files or queue | Changes to the legacy data that nobody announces |
How an API integration project runs
-
Inventory.
The interfaces you have and need, with an owner and a consumer for each.
-
Contract per interface.
Payloads, frequency, errors, duplicates and change notice, agreed before building.
-
Gateway and policy.
Kong deployed where it must run, with authentication and limits as code.
-
Build and test.
Against the contract, with realistic data and failure cases, in each sandbox.
-
Monitor.
Datadog traces, logs, monitors and API tests in place before go-live.
-
Cut over.
One interface at a time, the old route kept until the new one agrees.
-
Support.
Changes, upgrades and credential renewals from Riyadh, or managed services.
What drives cost and timeline, and who does the work
Interkey publishes no fixed price for API integration, because the effort depends on what the inventory shows:
- The number of interfaces and how many systems each one touches.
- What the systems offer: a documented API is quicker to integrate than a legacy system that needs one built in front of it.
- National platforms in scope, since onboarding and sandbox testing follow each platform's process.
- Where the gateway runs, and whether a gateway is already in place.
- Your team's share: work done for you, or alongside you.
Read more
Duration follows the same drivers, so any timeline before the inventory is an estimate. Interkey works as an API integration company in Riyadh: the work is done by its own integration engineers there, in Arabic and English, who can then support the interfaces on a written scope or operate them under a managed services agreement.
Relatedmanaged services
Questions buyers ask
What do API integration services from Interkey include?
An inventory of your interfaces, a written contract for each, the build and tests, a Kong gateway in front, Datadog monitoring behind, and support after go-live. Take one part or the whole sequence.
Can you connect our systems to Saudi government platforms such as Nafath or ZATCA e-invoicing?
Yes, each as its own integration built to the platform's published specification and tested in its sandbox. Registration and credentials stay with your organisation; Interkey builds and operates your side.
How is an API integration project priced in Saudi Arabia?
Per engagement, after the interface inventory. The number of interfaces, what each system offers, the national platforms in scope and where the gateway runs drive the effort.
How long does it take to integrate our systems through APIs?
It depends on the number of interfaces, how quickly each contract is agreed and each platform's onboarding. Interfaces go live one at a time, so the first can run before the rest.
Can the API gateway and the integration traffic stay inside the Kingdom?
Yes, where that is required. Kong can run self-managed on infrastructure you operate in Saudi Arabia, and where each component runs is recorded in the design.
Is there a team in Riyadh to support our APIs after go-live?
Yes. Interkey's integration engineers in Riyadh support the interfaces on a written scope, or operate them as a managed service.
Next
Read next
Next step
Map your API integrations
Tell us which systems need to exchange data, which outside services and national platforms are involved, and which interfaces cause trouble today. We will propose the scope of an inventory and the approach we would expect for each interface.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia