تكامل الأنظمة الحكومية
In many sectors, software cannot operate without connecting to mandatory public systems and national e-government platforms. These integrations have strict rules, frequently changing schemas and low-error-tolerance flows; we have real production experience on this demanding surface.
In Turkey, software doesn't run without connecting to an official system
In healthcare you can't invoice without sending a Medula authorization; at a pharmacy you can't sell a drug without scanning the İTS barcode; a law office can't track a case without connecting to UYAP; a hotel can't complete a stay without reporting the guest to KBS. In many sectors in Turkey, software cannot do its job without connecting to these mandatory official systems — and this is our most concrete area of proof.
These integrations aren't a promise for us — they're a reality running every day inside 46 sector products: Medula, İTS and e-Nabız in our healthcare products; UYAP in our legal and accounting product; KBS in our hospitality product; ÇKS in our agriculture product; SGK entitlement queries in our optics and hearing-center products; Amazon SP-API in our logistics and retail products all run as live integrations. Below we show exactly which one runs in which product.
- Live integration with 7 official/institutional systems
- Each one runs in a real product — not invented
- A modular adapter architecture: new system = new adapter
- Documentation, test environments and version tracking are our job
6 things that make official-system integration hard
The 8 systems we run live
Each one runs live in a different sector, in a real product — you can see which one is where below.
e-Government
Identity verification and e-signature-based approval; used at the entry point of our enterprise products.
Medula
Health-insurance authorization and invoicing; live in our polyclinic product, Medora.
İTS (drug track-and-trace)
Drug barcode track-and-trace; live in our pharmacy product, Ecora.
e-Nabız (national health record)
The national health record; a shared integration point across our healthcare product family.
UYAP (judicial system)
Case/file and hearing data; live in our law-office product.
KBS (guest ID reporting)
Mandatory guest-ID reporting; live in our hospitality (PMS) product.
ÇKS (farmer registry)
Farmer-registry-ready data; live in our agriculture product.
Amazon SP-API
Marketplace order/stock integration; live in our logistics and retail products.
The 3 disciplines living beneath an official integration
Documentation and the application process
Connecting to an official system usually starts with an institutional application: an authorization letter, a contract, sometimes an on-site inspection. This process can take weeks, not days; because we've run it before, we know upfront which document is needed in which order — it doesn't enter the development timeline as a surprise.
- The authorization-letter & contract process is known upfront
- Expected duration is built into the timeline from the start
Test environment and sandbox access
You don't connect directly to most official services' live environment; end-to-end scenarios — success, failure, timeout — are validated first with test (sandbox) credentials. The sandbox credentials themselves require a separate application; requesting them early is the only way to keep development from waiting.
- Sandbox credentials are requested early
- Success/failure/timeout scenarios are validated in the test environment
Tracking version and schema changes
An official service's field name, required field or authentication method can change without notice. Because every integration is written as an independent adapter, a change affects only that adapter; monitoring and alerting catch a change before it hits production.
- Every integration is an independent adapter
- Change monitoring & early warning
Which system is live in which product
Not a made-up case study; every line is code running inside a real product.
Medora
Polyclinic management: Medula authorization and invoicing integration runs live.
Ecora
Pharmacy management: drug and product tracking via İTS drug-barcode integration.
Our healthcare product family
The e-Nabız national health record is a shared integration point; our optics and hearing-center products also run SGK entitlement queries.
Law & accounting practice solution
Connects to the profession's official backbone via UYAP case/file integration and filing services.
Our hospitality (PMS) product
A checked-in guest's ID is recorded ready for the mandatory KBS report.
Our agriculture product
Produces registry- and subsidy-filing-ready, exportable records for ÇKS.
Our logistics & retail products
Pull orders via Amazon SP-API and sync stock and price.
How we build an official-system integration
Application & documentation
We know upfront which document, contract and authorization is required, and start the application process early.
End-to-end testing in sandbox
With the provider's test credentials we validate success, failure and timeout scenarios together.
Writing it as an adapter
We build the integration as an independent module rather than embedding it in the core; when regulation changes, only this module is updated.
Go-live & monitoring
We go live with a controlled rollout in the production environment and wire error rate and schema changes into monitoring.
Version tracking & maintenance
We track version/schema changes announced by the institution and keep the adapter current under SLA maintenance.
The technology we build on
- SOAP
- REST
- XML
- e-Signature
- certificate
- mTLS
- Public-service adapters
- monitoring & alerting
- .NET 9
- PostgreSQL
Frequently asked
Have you really connected to these systems, or just read the documentation?
We really have. The Medula, İTS, UYAP, KBS, ÇKS and Amazon SP-API integrations run today inside the actual products we named — Medora, Ecora, our law/accounting solution, our hospitality product, our agriculture product, our logistics/retail products.
How long does it take to get test-environment access?
It depends on the system's institution; usually a few days to a few weeks. We start this application at the very beginning of the project, before development starts, so it doesn't delay the timeline.
What happens if the institution changes something?
Every integration is written as an independent adapter; when a field name or rule changes, only that adapter is updated — the rest of the application is unaffected. We also track change announcements and validate them in the test environment before they hit production.
Which official system is mandatory in which sector?
Medula and İTS in healthcare, UYAP in law, KBS in hospitality, and ÇKS in agriculture are generally mandatory; e-government and e-signature are used as an identity layer in many sectors. We clarify together in the first conversation which ones are mandatory for your sector.
Do you also manage the e-signature/certificate process?
You obtain the certificate itself from an e-signature provider; we integrate that certificate into the system and build the mTLS and signature-verification flow.
How long does it take for the system to go live?
It depends on scope; the general range is 3 weeks – 5 months. Documentation and test-environment time are built into this timeline from the start — no surprise delays.
Which official system do you need to connect to?
We'll listen to your sector and your mandatory integrations and map out where to start, together. The first conversation is non-binding.