Overview
Application Integration is the architectural discipline that enables independently developed applications, databases, cloud services and field devices to communicate securely and consistently through a common data language. An order traveling from an e-commerce site to the ERP, then on to the warehouse management system and the carrier's API, or sensor data from a production line flowing to a reporting platform in real time, is the result of a well-designed integration layer. Indexline designs, builds and operates this layer under a managed service model.
Every year, organizations' application portfolios grow; yet these applications often run unaware of one another. The same customer record is held in three different systems in three different formats, reports are merged manually in Excel files, and a change made in one system shows up in another only hours later. This disconnect comes back as data inconsistency, operational delays and lower-quality decisions. Integration is the invisible but most decisive infrastructure component of digital transformation; end-to-end automation of business processes is only possible when systems are reliably connected to one another.
The modern integration ecosystem is built on two main communication models. In synchronous communication, REST, GraphQL or gRPC-based APIs are documented with OpenAPI and published through API gateways such as Kong or Apache APISIX, with authentication, rate limiting and versioning. In asynchronous communication, messaging infrastructures such as MQTT, Apache Kafka and RabbitMQ come into play. With its lightweight design and publish/subscribe model, MQTT is ideal for IoT devices and low-bandwidth connections; Kafka is preferred for high-volume event streams, and RabbitMQ for reliable job queues.
Growing integration without a plan comes at a heavy price. Point-to-point connections written directly between two systems for every new need gradually turn into a fragile structure known as "spaghetti integration", one that nobody fully maps. A version upgrade in one system can break dozens of connections, faulty messages can be silently lost, and personal data can flow over unencrypted channels. This creates both a serious compliance risk under KVKK (Turkish Personal Data Protection Law) and a visibility gap that makes root cause analysis nearly impossible during an incident.
Indexline treats integration not as a one-off software project but as a living platform that must be managed. First, the existing application and data flow map is drawn up; then a target architecture based on API-first and event-driven principles is designed. The API gateway, MQTT broker and message queues are deployed on Kubernetes in a highly available configuration, and every flow is made traceable, retryable and auditable. After go-live, the Indexline team takes on 24/7 monitoring, capacity management, version updates and the handling of new integration requests under the SLA.
How It Works
Discovery and Inventory: Existing applications, databases, field devices, external services and the data flows between them are mapped. Point-to-point connections, manual data transfers and critical dependencies are documented.
Target Architecture Design: We determine which flows will run over synchronous APIs and which over asynchronous messaging. A reference architecture is built, consisting of an API gateway, MQTT broker, event streaming platform and integration services.
Data Model and Contracts: Common data models, OpenAPI and AsyncAPI contracts, the MQTT topic hierarchy and message schemas are defined. Versioning and backward compatibility rules are clarified.
Security Design: Authentication with OAuth 2.0 / OpenID Connect, service-to-service encryption with mTLS, per-device certificate management and topic-level authorization (ACL) policies are implemented.
Platform Setup: The API gateway, MQTT broker cluster and message queues are deployed on Kubernetes in a highly available configuration. All configuration is kept under version control using an IaC and GitOps approach.
Integration Development: Connectors, transformation rules, error handling, retry and dead letter queue mechanisms are developed. Flows are validated end to end in a test environment.
Phased Migration: Existing point-to-point connections are moved to the new platform in order of priority. With parallel running and comparative validation, the migration is completed without business disruption.
Managed Operations: Message latency, error rates, queue depth and API response times are monitored 24/7. Incident management, capacity planning, version updates and new integration requests are handled by Indexline under the SLA.
Key Features
API Gateway Management
REST, GraphQL and gRPC services are published through a single gateway. Authentication, rate limiting, caching and versioning are managed centrally.
MQTT Broker Infrastructure
With a clustered MQTT broker, thousands of devices and applications communicate using the publish/subscribe model. QoS levels, persistent sessions and retained messages are configured to match business needs.
Event-Driven Architecture
With Apache Kafka or RabbitMQ, systems communicate through events without being tightly coupled. A slowdown or maintenance window in one system does not bring the others to a halt.
Prebuilt Connectors and Transformation
Connectors are used for ERP, CRM, databases, file servers and SaaS applications. Data is transformed between formats such as JSON, XML, CSV and EDI, and enriched along the way.
End-to-End Traceability
Every message and API call is tracked with a correlation ID. With OpenTelemetry-based distributed tracing, the system where a transaction is stuck is identified within minutes.
Fault Tolerance and Retry
With automatic retries for transient errors, a dead letter queue for persistent errors and idempotent processing, no message is silently lost or processed twice.
Layered Security
With TLS-encrypted channels, mTLS, OAuth 2.0, device certificates and topic-based authorization, the integration layer is protected in line with Zero Trust principles.
Developer Portal
With a developer portal offering an API catalog, interactive documentation and key management, internal teams and business partners can launch integrations on a self-service basis.
Benefits & Advantages
Manual data transfers and duplicate data entry are eliminated; operational error rates and staff workload drop significantly.
Data flows between systems approach real time; management and field teams make decisions based on up-to-date data.
Because a central integration layer replaces point-to-point connections, the time needed to add a new application or replace a legacy system is shortened.
Thanks to the event-driven architecture, a failure or maintenance work in one system does not stop the others; business continuity improves.
Since all data flows are centrally monitored and logged, producing evidence for KVKK and internal audit processes becomes easier.
With setup, monitoring and updating of the integration platform handed over to Indexline, the in-house IT team can focus on projects that create business value.
Documented APIs and a developer portal accelerate digital collaboration with business partners, dealers and suppliers.
Industry Use Cases
Manufacturing
PLC and sensor data was transferred via MQTT to a central broker through Teltonika industrial gateways; by combining production data with MES and ERP, OEE reporting moved from daily manual compilation to a real-time view.
Retail / E-Commerce
Marketplaces, the e-commerce site, ERP and the warehouse management system were connected through an event-driven architecture; stock synchronization delay dropped from hours to seconds, and cancellations caused by out-of-stock sales fell by 60%.
Finance & Banking
Scattered internal services were consolidated behind an API gateway; APIs exposed to business partners were protected with OAuth 2.0 and rate limiting, and onboarding time for new partner integrations fell from weeks to days.
Healthcare
The hospital information management system, laboratory and imaging systems were integrated through an HL7 FHIR-compliant API layer; the time for patient results to reach physicians was shortened, and all data access became auditable.
Energy
Field data from distributed power plants was collected via MQTT and fed into a time-series database; by matching fault alarms with SCADA and the work order system, response time was reduced by 40%.
Logistics
Vehicle tracking devices, carrier APIs and the order management system were unified in a single integration layer; by sending customers real-time delivery status notifications, call center workload fell by 35%.
The Indexline Approach
Most integration projects struggle not because of technology but because of unclear ownership and undocumented contracts. That is why Indexline starts every project not with tool selection but by mapping data flows and business processes together with their owners. An integration built before it is clear which system is the "source of truth" for which data, how much latency each flow can tolerate and who must be notified when an error occurs becomes fragile at the first problem.
In our architectural choices, we combine API-first and event-driven approaches. For query and transaction steps that require an immediate response, we build well-designed APIs documented with OpenAPI; for scenarios where state changes must propagate to multiple systems, we design event streams based on MQTT or Kafka. Rather than trying to solve every problem with a single technology, choosing the right communication model for each flow delivers the healthiest long-term outcome in terms of both performance and maintenance cost.
We see security as an integral part of the integration layer. The integration platform is a highway carrying an organization's most valuable data, and an attractive target for attackers. We therefore work according to the Zero Trust principle, treating every connection as untrusted by default; we apply service-to-service mTLS, short-lived tokens, device certificates, topic- and endpoint-based authorization, and masking of personal data. All access is logged and can be forwarded to a SIEM infrastructure.
In our managed service model, responsibility does not end at go-live. Signals such as queue buildup, rising error rates, a slowing external API or a certificate approaching expiry are monitored proactively, and issues are addressed before business units notice them. Broker and gateway version updates, capacity expansions and disaster recovery drills are carried out within a planned maintenance calendar. Flow volume, success rates and SLA compliance are shared transparently in monthly reports.
Every organization's integration maturity is different. Some want to make a few critical flows reliable first, while others aim directly for an API ecosystem open to business partners or an IoT data platform connecting thousands of devices. Without forcing complexity the organization does not need, Indexline creates a phased roadmap that starts with quick wins and delivers measurable value at every stage. The goal is for integration to become not a bottleneck but a capability that brings new business ideas to life quickly.
Frequently Asked Questions
What is the difference between MQTT and REST APIs, and which should we use?
REST APIs work on a request-response model: when a client needs data, it asks and receives a response. MQTT works on a publish/subscribe model: the data producer publishes a message to a topic, and the broker delivers it to all interested subscribers. REST is better suited to real-time queries and transaction steps, while MQTT is better for devices that continuously generate data, low-bandwidth connections and scenarios where an event must be distributed to many systems. Most enterprise architectures use both together.
What do the QoS levels in MQTT mean?
QoS 0 means a message is delivered at most once, with no acknowledgement expected; it is the fastest option but tolerates loss. QoS 1 guarantees that a message is delivered at least once; since redelivery may occur, the receiver must tolerate duplicate messages. QoS 2 ensures that a message is delivered exactly once; it is the most reliable option but carries the highest overhead. QoS 0 or 1 is typically chosen for telemetry data, and QoS 1 or 2 for commands and critical business events.
Are MQTT and Apache Kafka alternatives to each other?
Not exactly; they complement each other. MQTT is designed for connecting large numbers of devices and clients through a lightweight protocol. Kafka is an event streaming platform that durably stores high-volume event streams, allows them to be replayed and distributes them scalably to multiple consumer groups. In a common architecture, devices connect to the MQTT broker, data is transferred to Kafka through an MQTT-Kafka bridge or a Kafka Connect connector, and analytics, reporting and business applications are fed from Kafka.
Can our existing ERP and legacy systems be integrated?
Yes. Systems that offer modern APIs are connected directly. For legacy systems without APIs, connectors are developed using database-level change data capture (CDC, for example Debezium), file-based transfers, SOAP services or other interfaces the system supports. The aim is to bring the legacy system securely into the modern integration layer without forcing it to change.
What happens if a message is lost in the integration layer?
In a well-designed integration platform, messages are not silently lost. Persistent queues, broker replication, delivery acknowledgements and automatic retry mechanisms handle transient errors. Messages that cannot be processed after a set number of attempts are moved to a dead letter queue and an alarm is raised. Idempotent processing design also prevents a resent message from creating a duplicate record.
How is the integration platform secured?
All traffic is encrypted with TLS, and mTLS is used between services. Applications authenticate with OAuth 2.0 / OpenID Connect, and IoT devices with X.509 certificates. Topic-based authorization is applied on the MQTT side, and endpoint- and scope-based authorization on the API side. Rate limiting and a WAF prevent abuse; all access logs are stored centrally and can be forwarded to a SIEM system.
Does the platform run in the cloud or in our own data center?
Both models are possible. Since the integration components run as containers on Kubernetes, they can be hosted on Indexline infrastructure, in the organization's own data center, in a public cloud or in a hybrid setup. Where data must remain within Turkey due to KVKK or sector-specific regulations, the architecture is designed accordingly.
What does Indexline take on as part of the managed service?
The scope is defined according to need, but it typically includes 24/7 monitoring of the platform, incident response, capacity and performance management, broker and gateway version updates, certificate renewal, backup and disaster recovery drills, monthly SLA reporting, and the analysis and development of new integration requests. This way, the organization does not need to build a separate expert team to operate the integration platform.