API integration is the connection that lets two pieces of software talk to each other. In practice it means this: no longer typing the same data into two different programs by hand. This article covers when you need it, how it's built and what goes wrong.
What an API is — and what it isn't
An API (Application Programming Interface) is the door a piece of software opens to the outside world: a contract that says "if you ask this address in this format, I'll give you this data". A user interface is for people; an API is for other software.
A common misconception: API integration isn't just "pulling data". The real work is mapping the data models of two systems to each other and handling errors.
When do you need it?
If you see these signs, there's a case for integration:
- The same information is entered into two programs by hand (orders → accounting, stock → website)
- Excel files are being carried between two systems
- At the end of the day someone checks "which records were transferred"
- Errors happen because a change in one system reaches the other too late
- A significant part of the team's time goes into moving data
On the other hand, where 5 records a day are moved, the cost of integration won't pay back. The rough threshold: more than 3 hours of manual transfer per week.
The most common integrations
| Connection | What you gain |
|---|---|
| E-commerce → accounting | Orders and invoices transferred automatically |
| E-commerce → shipping | Barcode, tracking number, customer notification |
| Website/panel → ERP | Stock, customer accounts, prices from one hub |
| Marketplace → panel | Trendyol and Hepsiburada (Turkish marketplaces) orders on one screen |
| CRM → email/SMS | Automatic notifications and campaigns |
| Bank → accounting | Statement and payment reconciliation |
How it's built: 6 steps
1. Data mapping table
The one thing to do before any code is written: map the fields in the two systems to each other, in writing. "Product code" may be the SKU in one system and the barcode in the other. An integration written without this table always gets fixed afterwards.
2. Data direction and authority
Which system "tells the truth" for which data? The warehouse for stock, the ERP for prices, the CRM for customers, and so on. If this isn't defined, the two systems overwrite each other's data.
3. Authentication and permissions
API keys shouldn't be written into the code; they should be kept in environment variables, with permissions as narrow as necessary. Don't ask for write access for a read-only operation.
4. Error handling
This is the part that really determines the quality of an integration. When the other system doesn't respond:
- The record must not be lost; it should wait in a queue
- It should be retried at intervals (exponential backoff)
- After a set number of attempts, a notification should go to the person responsible
- Every attempt should be logged
Without these four, the integration "looks like it works" and produces losses that are noticed months later.
5. Test environment
Trials shouldn't be run on the live system. That's how real SMS messages reach real customers and fake orders end up in accounting.
6. Gradual rollout
Start with one channel or one transaction type. In the first week every record is checked by hand. If something goes wrong, the impact stays limited.
Technical notes
- REST and JSON are the most common standard; most modern systems speak it.
- Webhooks mean the other system calls you when an event happens — both faster and cheaper than constantly asking (polling).
- A queue lets requests be processed in the background; setups that save an order while waiting for an API response are both slow and fragile.
- Rate limits exist on most APIs. Bulk transfers need to respect them.
- Version management: so the integration doesn't break when the other side updates its API, version pinning and monitoring are essential.
What about legacy systems?
The most common situation in Turkey: the accounting program has no API, or a very limited one. The options:
- Intermediate database: If the program writes to its own database, read from there
- File-based transfer: Generate and read CSV/XML at set intervals
- The vendor's integration module: Costs extra but is the safest
- Upgrade: Sometimes the most economical path is moving to the current version of the program
In these cases the effort is 2–3 times higher than connecting to a documented API. When asking for a quote, state the other system's version and API status clearly.
Timeline and cost
| Scope | Timeline | Budget |
|---|---|---|
| One-way, single flow | 1–2 weeks | 8,000–20,000 TL |
| Two-way, 2–3 data types | 3–5 weeks | 25,000–60,000 TL |
| ERP / legacy system connection | 6–10 weeks | 60,000–150,000 TL |
The main source of variation is the quality of the other system's API. There's a big difference between a documented, current API and connecting to an old program's database.
Frequently Asked Questions
Will the integration slow down my system?
Not if it's built correctly. Transfers should run in the background through a queue.
What happens if the other side changes its API?
If monitoring is in place, it's noticed right away. That's why a maintenance agreement should be part of the integration.
How is data security ensured?
HTTPS, narrowly scoped keys, storage in environment variables and, when personal data is transferred, compliance with KVKK (Turkey's personal data protection law, similar to GDPR). Card and ID details must not be kept in logs.
How many systems can be connected?
There's no limit, but with more than two systems, building a central hub (instead of connecting everything to everything) makes maintenance much easier.
To get started
Tell us which two systems you want to connect and which data should flow; we'll scope it and estimate the timeline for free. For service details see our API integration page, and for the e-commerce side our OpenCart API integration article.
Phone / WhatsApp: +90 536 628 0007
Email: info@enextware.com
