Custom API and integration development that gets your ERP, CRM, marketplace, e-invoice and production systems talking to each other, with a two-way, secure and traceable data flow.
Prepared by Pan Innovation House, a software company based in Gaziantep, Türkiye · Last reviewed:
An API integration is the bridge that lets independently running pieces of software exchange data under defined rules. A company's accounting software, e-commerce site, production tracking system and marketplace panels usually live in separate worlds; the same information is keyed into each of them by hand, again and again. Integration removes those gaps: when stock is updated in one place it flows through to the others, an incoming order lands in the ERP automatically, and an issued invoice reaches GİB (the Turkish Revenue Administration) through your e-document integrator. The result is a single system backbone where duplicate data entry ends, errors fall and decisions are made on current data.
Off-the-shelf plugins and connectors solve the standard scenarios on the surface, but every company's workflow, software versions, field mappings and edge cases are different. A carpet factory's price-per-square-metre model, a machinery maker's part-and-BOM structure or an exporter's currency and customs fields rarely fit a packaged connector. With custom development we build the integration around your real process: which field goes where, under which condition, how often; what happens if a system stops responding; how a conflicting record is resolved. These things are designed by looking at the flow on the ground, not from a template.
At Pan Innovation House we build integrations with an API-first approach: every connection is set up with open, documented interfaces so it can talk to yet another system tomorrow. The source code we write and your data are handed over to you as defined in the contract; third-party and open-source components remain subject to their own licences. Documentation and configuration are handed over too. Every delivery goes through a review step before go-live, and monitoring, error handling and maintenance continue afterwards.
If your accounting/ERP software and your website, marketplace or B2B portal work in ignorance of each other, and you are tired of manually reconciling stock, prices and orders, a bridge between your systems is exactly what you need.
Single-point stock and order synchronisation for companies selling the same product across multiple marketplaces, dealer portals and corporate customers — like Gaziantep's carpet, textile, machinery and food exporters.
Businesses that want invoicing, dispatch notes and official document processes to flow automatically from their own software into the e-document system through their private integrator, and want reconciliation and archiving put in order.
Industrial and corporate companies with a long-serving but closed production, accounting or bespoke system, who want it talking to new applications without replacing it from scratch.
We design documented, versioned, authenticated REST or GraphQL services that open your systems to each other and to the outside world, delivered with OpenAPI documentation.
We build connections that sync customer account, product, stock, order and invoice data two-way between ERPs such as Logo and SAP and your CRM, e-commerce and field applications; field mapping is done to your process. The route depends on each system's version and the access you are given, and is established during discovery.
We develop an integration layer where products, prices, stock and orders across multiple sales channels are managed centrally, and a change in one channel is reflected in the others automatically.
Connections from your own software into e-invoice and e-despatch note processes, document status tracking and reconciliation flows — statutory integrations embedded in your workflow. E-invoices go through your private integrator's API, or through direct GİB integration where you are authorised for it.
Webhook and event infrastructure so other systems learn instantly when a record changes, with retry, ordering and error queue logic for reliable delivery.
For growing systems, a microservice architecture that gathers connections into a single, independently scalable integration layer, with inter-service messaging and contract management.
We connect closed or ageing systems to modern applications via the database, file-based transfer or an intermediary service — getting them talking without replacing them.
Not every integration needs custom development. The tables below set out four common routes, what an integration project covers and what it does not, what you receive at handover, and what drives time and cost. Where a ready-made connector will do, we say so plainly.
The choice mostly depends on how many systems are involved, whether data flows one way or both ways, how often it moves, and how specific your exception rules are.
| Route | Enough when | Where it struggles | Cost structure |
|---|---|---|---|
| Ready-made plug-in or connector | The two systems are widely used and their versions are supported; your fields are standard (product, stock, price, order). | Special fields (price per square metre, recipes, currency and customs), exception rules and what happens on failure often fall outside the plug-in. Ask its vendor which versions it supports. | One-off fee or subscription; limited room to customise. |
| Integration platform (iPaaS) or low-code workflow tool | The connectors you need already exist; flows are simple and volumes moderate. | Complex mapping, high volumes and legacy systems still need code. Subscription costs can grow with usage, and knowledge of the flows stays inside the platform. | Usage-based subscription, plus set-up. |
| Custom point-to-point link | You need one clear data flow between two systems. | As systems multiply, every link becomes its own maintenance burden. Without monitoring and an error queue from day one, silent data loss goes unnoticed. | A project fee and maintenance per link. |
| A central integration layer | Three or more systems (ERP, e-commerce, marketplaces, CRM, production) share the same data, and you want flows that can be monitored and retried on failure. | Design and data contracts take time; the initial investment is higher than a single link. | A project fee and a maintenance agreement. |
In most businesses running Logo, Netsis or Mikro, data flows roughly as below. Which system is the master for each kind of data is agreed in writing during discovery; if the same data is edited in two places, conflicts are inevitable.
| Data | Usual direction | A ready-made connector is enough when | Custom integration is needed when |
|---|---|---|---|
| Product records and variants | From the ERP to sales channels; channel-specific descriptions and images stay in the channel. | Your product structure is standard and the tool already maps the channel's categories and attributes. | Variants, units of measure or recipe structures do not map directly onto what the channel expects. |
| Stock | From the ERP (or warehouse system) to the channels, at short intervals. | One warehouse and a single stock figure are enough. | Several warehouses, reserved stock, or goods in production or in transit must count towards sellable stock. |
| Prices | From the ERP to the channels; rules are defined where a channel has its own price. | Every channel uses the same price or a simple percentage difference. | There are channel-, dealer- or customer-group-specific prices, campaigns and exchange-rate rules. |
| Orders | From the channel into the ERP; order, return and cancellation status flows back from the ERP to the channel. | Orders are uniform and partial deliveries, returns or exchanges are rare. | There are partial shipments, returns, exchanges, an approval step or rules for splitting orders. |
| Customer accounts | From the channel into the ERP, with a rule for matching existing accounts. | Individual customers can be grouped under one general account. | Business customers must land on their own account, with matching by tax number and duplicate checks. |
| Invoices and delivery notes | From the ERP to the e-document service provider; the document number and status are passed back to the channel if required. | Your document flow already works between the ERP and the service provider. | The channel's document notification or batch invoicing rules do not fit the ERP's standard flow. |
The external connection routes of Logo, Netsis and Mikro (web service, API, transfer file or staging table) vary by product, version and licence; some routes may need an extra licence or a separate tool from the vendor's partner. Ask your ERP partner which route is open in your version; we confirm it together, in writing, during discovery. A custom layer does not write directly into ERP database tables; it uses the route the vendor supports.
Scope is written down for every project during discovery. The split below shows the boundaries that most often get blurred in integration projects.
| Area | In the project | Out of scope or agreed separately |
|---|---|---|
| Connection and data mapping | Data contracts between systems, field mapping, exception and conflict rules, authentication, retries and logging. | Licences, API access fees and usage quotas of the connected systems are between you and their vendors. |
| E-documents | Passing invoice and delivery-note data to your e-document service provider and tracking document status. | Turkish e-invoices, e-archive invoices and e-delivery notes are issued through the service provider (özel entegratör); that service is a separate contract. |
| Marketplaces | Product, stock, price and order transfer that follows the marketplace's API. | The marketplace's category, content and campaign rules and its API changes belong to the marketplace; adapting to changes is handled under maintenance. |
| Data in the source system | Catching and reporting faulty or incomplete records. | Correcting a record in the source system is the job of the team that uses it; the integration makes the error visible rather than hiding it. |
Handover covers the working links and the documents that let another team maintain them too.
| Deliverable | What it is for |
|---|---|
| Working links and data contracts | Which field goes where, in which format, is written down; a new team can take over. |
| Error queue, alerts and reconciliation report | A system that does not respond or a rejected record is not lost silently; the right person is notified. |
| API documentation | The starting point for any team that later wants to connect a new system or channel. |
| Source code | The source code we write and your data are handed over to you as defined in the contract; third-party and open-source components remain subject to their own licences. |
A firm figure is given in writing after discovery and analysis. These factors set the quote most.
| Factor | Why it matters |
|---|---|
| Number of systems and direction of data | A one-way transfer and a multi-system, two-way flow are different jobs. |
| How each system can be connected | A documented API, file exchange or direct access to an old database mean very different workloads. |
| Exception rules | Conflicting records, partial deliveries, returns and exchange-rate differences each need their own rule and test. |
| Volume and frequency | An end-of-day batch and near-real-time sync need different infrastructure and monitoring. |
| Test environments | If the systems to be connected have no test environment, the controlled cut-over is planned more carefully and takes longer. |
If these are ready, the first call is concrete; we can fill any gaps together during discovery. The first 30-minute call is free; the scope of an on-site discovery, and its fee if any, is agreed in writing during that call.
We map on the ground which systems will share which data, in which direction. We examine the interfaces, versions and constraints of your existing software and pin down the integration map together.
For every connection we define the data contract (which field goes where, in which format) and the exception rules: how conflicting records, missing data and error scenarios will be resolved is settled on paper first.
APIs, webhooks or microservices are developed in short sprints. Authentication, retries and logging are set up from the start, and a working connection is shown at the end of each sprint.
Connections are tested with near-real data scenarios and verified first in a controlled environment. After a review step, they go live in stages, planned so as not to stop the production flow.
Flows are monitored in production; error queues, alerts and reconciliation reports catch problems early. Updates, new channel additions and improvements continue under the maintenance scope defined in the contract.
Off-the-shelf plugins solve standard scenarios quickly, but your software version, your custom fields (price per square metre, part-and-BOM, currency/customs and the like) or your exception rules often do not fit the package. With custom development we build the integration around your real flow and leave control and flexibility with you.
In most cases, yes. Connecting to ERPs such as Logo (a widely used Turkish ERP) and SAP is usually possible; the route depends on the version and the access you are given, and is established during discovery. E-invoices and other e-documents go through your private integrator's API (an integrator approved by GİB, the Turkish Revenue Administration), or through direct GİB integration where you are authorised for it. Marketplace and e-commerce panels are connected two-way. For systems closed to the outside, a file-based or approved import route is considered; whether it is possible depends on the vendor's terms and is settled during discovery.
A simple one-way bridge and a multi-system, event-driven integration layer are very different jobs. The number of systems to connect, the data volume and the exception rules determine the scope. We do not invent a fixed figure; cost and timeline become clear after discovery and analysis, along with the scope.
No. We build the integration with retry, error queue and ordering logic. Even if a target system is temporarily unreachable, messages are held and processed when the system comes back; every flow is logged and traceable.
Yes. The source code we write and your data are handed over to you as defined in the contract; third-party and open-source components remain subject to their own licences. Configuration and OpenAPI documentation are handed over too; you can continue with another team if you wish.
There is. We offer maintenance packages, with scope and response times defined in the contract, covering monitoring, error handling, security updates and the addition of new systems and channels. As your systems change or a new marketplace comes on board, the integration evolves with them.
API integration is the connection that lets independently running software exchange data automatically according to defined rules. When stock is updated in one place it is reflected in the other systems, an order drops into the ERP by itself, and the same information is not keyed in by hand again and again. We build connections on open, documented interfaces, with retry and error-queue logic.
Marketplace integration is done by matching product, price, stock and order data two ways between the marketplace's API and your ERP or e-commerce system. First we work out, from the actual flow, which field goes where, under what condition and how often; then the connection is developed, tested and taken live in stages. When a new marketplace is added, the integration is extended under the maintenance agreement.
We listen to what you need and tell you whether custom development or an off-the-shelf product fits better. The first 30-minute call is free; the scope of an on-site discovery, and its fee if any, is agreed in writing during that call.
We set up electronic data interchange with retail chains and major buyers alongside your ERP. We turn incoming orders into your records, your shipments into dispatch advices and your invoices into the message the buyer expects; a faulty message lands in a queue, gets corrected and is sent again.
Details →We build the cloud infrastructure that keeps your software stable, secure and scalable: an automated, observable and reversible flow from code change to production release.
Details →ERP software designed around your processes, bringing your entire operation — from production to finance — onto a single backbone. Where the off-the-shelf package falls short, we build a system that fits your factory exactly.
Details →We develop a manufacturing execution system built for your factory — making the shop floor visible in real time, from work orders to OEE, scrap to shifts, running on a PLC/SCADA bridge and shop-floor terminals.
Details →We design the whole chain from sensor to cloud: device firmware, MQTT-based telemetry, edge processing and a remote monitoring panel. Your machines, production line and field equipment come together in a single data stream — and the source code we write is handed over to you.
Details →We collect a machine's vibration, temperature, current and cycle data, learn its normal operating signature, and catch deviations from that signature before failure occurs. An alert becomes a maintenance work order; the machine's history and the parts used accumulate in the same record.
Details →
