# KodDelta — Enterprise Integration Guide (English)

Last reviewed: 2026-08.

KodDelta does not require a company to discard existing investments. The default
pattern is a two-way, near-real-time bridge between the new operational system
and whatever the company already runs.

## Supported integration surfaces

- **Accounting and finance**: Logo (Tiger, Go3, Netsis), Mikro Yazılım (Fly, Jump), SAP (S/4HANA, Business One), Zirve, Luca.
- **E-invoicing and e-document (Türkiye)**: GİB e-Fatura, e-İrsaliye, e-Arşiv, e-Müstahsil via integrator bridges (Sovos, Foriba, Digital Planet, EDM, Uyumsoft).
- **E-commerce and marketplaces**: Trendyol, Hepsiburada, Amazon, Shopify, WooCommerce API synchronisation.
- **Warehouse and field hardware**: handheld terminals, barcode and QR scanners, RFID gates, weighbridge and scale indicators.
- **Banking and payments**: virtual POS (Garanti, Akbank, İş Bankası, Yapı Kredi, Iyzico, PayTR) and MT940 account-movement import.
- **Generic**: REST and SOAP APIs, SFTP file exchange, direct database views, webhook receivers.

## The hybrid model, in practice

The most common architecture for a manufacturer or distributor:

1. Accounting stays in the existing package — no migration, no retraining of the finance team.
2. Operational processes (work orders, field service, approvals, dealer orders, inventory movement) move to the custom system.
3. A bridge synchronises master data one way (products, customers, price lists) and transactional data the other (invoices, stock movements, cost entries).
4. Conflicts are resolved by a single declared source of truth per entity, written into the integration spec before any code is written.

## What decides whether an integration is straightforward

Straightforward: the existing system exposes a documented API or a stable
database view; master data has consistent identifiers; one system is clearly
the source of truth per entity.

Difficult: identifiers differ between systems and must be matched by name;
the existing system only exports files on a schedule; two systems both consider
themselves authoritative for the same record. These are solvable but they belong
in the estimate, not in the surprise column.

## Failure modes we design for

- The remote system is down — queued retry with visible backlog, not silent loss.
- A record is rejected by the remote system — surfaced to a named owner, not written to a log nobody reads.
- Duplicate delivery — idempotency keys, so a retried message does not create a second invoice.
- Schema change on the other side — versioned contract and an alert, rather than a silent field mismatch.

Related pages: https://koddelta.com/en/integrations ·
https://koddelta.com/en/migration-guide