Service
Systems integration and API development
If there is a person carrying a spreadsheet between two systems, an integration is missing. It costs time, and it manufactures errors.
API development and integrations we build most often
If your system isn’t listed, we check whether it exposes an API.
ERP and accounting
Two-way flow of orders, stock, accounts and invoices with systems such as SAP, Logo, Mikro, Nebim and Netsis. Manual entry into accounting stops.
E-invoicing
Invoices raised automatically after a sale and delivered to the customer, connected to your invoicing provider.
Marketplace integration
Product, price, stock and order matching across channels such as Amazon, Trendyol, Hepsiburada and N11. Selling the same stock on two channels costs you cancellations and seller rating.
Shipping and logistics
Automatic shipment creation, tracking numbers sent to the customer, delivery status fed back.
Payments and banking
Payment gateways, instalment tables, refund flows and reconciliation reports.
CRM and marketing
Form, order and support data flowing into your CRM, with segments and automations set up.
The hard part is not the connection — it is failure handling
Making two systems talk is usually a few days of work. The real question is what happens the moment one side stops answering: is the order lost, processed twice, or does nobody notice at all?
So every integration we build has three things as standard: retryability (resend the same record without processing it twice), logging (which record went where and when) and alerting (someone is told when failures accumulate). An integration that fails silently is more dangerous than no integration.
It is also written to survive rate limits and version changes. Providers do change their API versions; systems that were not built for it are found broken one morning.
Questions to ask on an integration project
Ask these when collecting quotes — the answers show whether the work has actually been thought through.
- Which side is authoritative? Where is stock considered correct? If both sides claim to be right, the data corrupts.
- How often does it flow? Real time, every minute, or nightly? Each option has a different cost and a different risk.
- Who hears about failures? Where does the alert go, and to whom? “We’ll check the logs” is not an answer.
- Is historical data migrated? The initial load is usually the riskiest step of the project and is planned separately.
- Is there a test environment? An integration tested in production means wrong emails sent to your customers.
Frequently asked
Our software has no API — is it still possible?
Usually a route exists. We look in this order: an official API, direct (read) database access, scheduled file transfer (CSV/XML), and as a last resort screen automation. That last option is fragile and we say so openly — it needs maintenance whenever the program is updated.
How long does an integration take?
A simple one-way transfer (orders → accounting) is typically 1–3 weeks. Two-way marketplace integrations covering stock and returns can run to 4–8 weeks. What sets the pace is not our code but the quality and documentation of the other side’s API.
What happens if the integration breaks?
It must never break silently. In the setups we build, failed records wait in a queue, are retried automatically, and raise an alert once they pass a threshold. That way you never hear “apparently orders haven’t transferred for three days”.
We sell the same product on our site and on marketplaces — how is stock handled?
We declare one system the source of truth, usually the ERP or the commerce panel, and every other channel is fed from it. Letting two channels hold stock independently produces cancellations and complaints sooner or later.
Off-the-shelf connector or a custom integration?
The honest answer: for most sellers an off-the-shelf connector is the better choice. For standard marketplace flows a subscription connector is cheaper and faster than custom code, and that vendor tracks the marketplace API changes for you. A custom integration makes sense in three cases: your ERP or a specific business rule isn’t supported; your product mapping is non-standard (variants, bundles, production-based stock); or your volume has pushed subscription costs above the build cost. We measure which case you are in during discovery — and if a ready product is enough, we say so.
Will you take over our existing integrations?
Yes. We review the current setup first and check whether logging and failure handling exist. On most integrations we inherit, the first job is making silent failures visible. It works best alongside infrastructure maintenance.
Which systems can’t talk to each other?
Tell us what you run and where the manual work sits. We will review the APIs and say clearly what can be connected.