What Is an API? How E-commerce Integrations Actually Work

In Brief

An API (Application Programming Interface) is the interface that lets two pieces of software exchange data under a defined contract. In e-commerce, marketplaces, carriers, payment gateways, accounting software and AI agents all talk to your store through APIs and nothing else. A well-built API layer means an order reaches the carrier in seconds, stock updates the marketplace instantly and the invoice posts to accounting on its own. A badly built one is an endpoint quietly returning errors at midnight while nobody watches. As of 2026 the question is no longer "do we have an API" but "which operation is being called, by whom, with what permission and which version".

Tuesday, 09.10. The marketplace dashboard shows 14 units of a product sold, your own site shows 9 in stock, and the warehouse count is 3. Three systems, three numbers, none of them lying; they simply never told each other. By noon two customers will receive a "cannot be fulfilled" message and one will leave a review.

Neither the marketplace nor the warehouse caused this. The cause is how the systems are connected. When stock changes in one place, who tells the other two, when, and through which channel? The answer is an API, and where the answer is missing you lose trust before you lose revenue.

What an API Is and What It Means in E-commerce

An API is the set of defined doors a piece of software opens to the outside. Each door has an address, a request format it accepts and a response format it returns. The restaurant analogy holds: you do not walk into the kitchen, you order from the menu through a waiter, the waiter talks to the kitchen and the food arrives. The menu is the contract, the waiter is the API, the kitchen is the other party's system.

Make it concrete. Your store's order API answers "give me the last 24 hours of orders" with a structured list. A carrier's API answers "create a shipment to this address at this weight" with a tracking number. A payment gateway's API answers "charge this amount to this card" with an approval or a decline. All three follow the same pattern: a request goes out, a response comes back, and the shape of both is agreed in advance.

Five terms a store owner needs

• Endpoint: the address of a single operation. /orders represents orders, /products/123/stock the stock of one product.
• Key (API key / token): the credential proving who is making the request. It is not your admin password; it is generated and revoked separately.
• Rate limit: how many requests you may send per minute. Exceed it on campaign day and the integration silently stops.
• Webhook: the other side notifying you without being asked. Instead of polling for new orders every minute, you get told the moment one arrives.
• Version: which edition of the API you are using. When the provider ships a new one and retires the old one, your integration stops.

A store owner who knows these five terms speaks the same language as the technical team or the agency, and can ask what actually sits behind "the integration is not working".

REST, webhooks and MCP: three ways of talking

You will meet three kinds of interface. REST is the classic request-and-response pattern and most e-commerce integrations run on it. A webhook is the other party calling you when something happens, which is more efficient than REST for real-time work such as orders, payments and delivery status. Model Context Protocol (MCP) is the newer layer: it lets an AI agent call your store's functions with typed parameters. The agent writes no SQL and never touches the database; it uses the tools you expose inside the limits you set. These three are not rivals but stacked layers.

Pattern	Who initiates	Best suited to	Weak point
REST API	You ask	Pulling catalogs, bulk stock updates, reports	Frequent polling burns limits and adds delay
Webhook	The other side notifies	New orders, payment approval, delivery events	A missed notification needs a retry path
MCP	An AI agent calls	Writing product copy, stock analysis, building campaigns	Risk grows without a permission ceiling

One Order's Journey Through the APIs

The quickest way to see what an integration does is to follow a single order through every door it passes. The flow below is typical for a mid-sized store with its own site and two marketplaces.

Before the order: catalog and stock

Product data lives in one source and goes to marketplaces through the API. A price change is made once, not typed into three dashboards. Stock drops on every sale and the new figure reaches the other channels instantly via webhook. Inconsistent product codes break this flow at the first step; a disciplined SKU structure is a prerequisite for API integration, not a later improvement.

At the order: payment and verification

When the customer reaches checkout, the payment gateway API takes over. Amount, instalment plan and card details travel encrypted and the approval returns within seconds. The 3D Secure step is part of this flow and, when misconfigured, cart abandonment rises noticeably. The moment approval lands, the order record is created, stock is reserved and the confirmation email fires.

After the order: shipping, invoicing and accounting

Once the order exists, a shipment request goes to the carrier API, a tracking number comes back and the label prints. The e-invoice API issues the invoice. The accounting system records the sale. As delivery status changes, webhooks trigger customer notifications. The whole chain completes in minutes without a human touching it; done by hand it takes ten to fifteen minutes per order. For the warehouse side of the picture, the logistics and warehouse management guide is the natural companion.

Step	API involved	Manual time	Integrated time
Stock sync (3 channels)	Marketplace product APIs	1-2 hours a day	Instant
Payment capture	Payment gateway API	Not possible	3-5 seconds
Shipping label	Carrier API	4 min per order	Instant
E-invoice	E-invoice integrator API	3 min per order	Instant
Accounting entry	Accounting API	2 hours weekly batch	Instant

In a store handling 60 orders a day, the shipping label and invoice lines alone add up to roughly 210 hours of human work a month. Once integrated, that effort goes back into customer service and product development.

The Integrations Turkish Stores Build Most, and Where They Break

Integration conversations usually start with "which platforms are supported" and end there. The real question is under which conditions the integration breaks, and who notices when it does. The sections below summarise what shows up most often in practice.

Marketplace integrations

The Trendyol and Hepsiburada APIs require category attributes; a product sent with a missing attribute is silently rejected and you only see the rejection when you open the dashboard. Rate limits are exceeded most often here, on campaign days. An integration that sends price and stock in batches uses far less of the limit and finishes faster than one sending records one by one. Marketplace campaign rules live outside the API, inside your seller contract: the integration can lower a price, but it does not know whether it should.

Carrier integrations

Carriers such as Yurtiçi, Aras, MNG and Sürat use different address formats, different volumetric weight formulas and different error codes. The most common failure is a single carrier's endpoint returning errors for weeks with nobody looking. The fix is operational rather than technical: a simple counter tracking each carrier's daily success rate. A counter dropping from 100 to 92 percent shows you next week's complaints today.

Payment and e-invoicing

On the payment side, the most common mistake is a sandbox key promoted to production: payments look successful but no money arrives. On the e-invoice side, the tax authority's taxpayer registry updates daily; whether to issue an e-archive or an e-invoice must be queried through the API, because deciding by hand produces the wrong document. Neither integration forgives errors, which is why a test order should be a monthly routine.

Accounting and ERP

With systems such as Logo, Mikro and Netsis, field mapping takes the most time. "Customer name" may be one field on your side and two fields, first and last name, in the ERP. The mapping is done once, correctly, and documented; undocumented, it becomes untouchable the day someone leaves the team. Asking whether these integrations come ready-made when choosing a platform avoids the largest bill you would otherwise pay later; we went through that cost in the mistakes made when choosing an e-commerce platform.

Ready-Made Integration or Custom Build?

Every store meets this choice. A ready-made integration is quick to set up and maintained by the provider; a custom build fits your workflow exactly but its maintenance is yours. The right answer is usually a mix: common integrations ready-made, your own business rules built on the API.

Criterion	Ready-made integration	Custom build (via API)
Setup time	Hours, at most days	Weeks
Upfront cost	Low, often included in the plan	Developer day rates
On version changes	Provider updates it	You update it
Custom business rules	Limited	Full flexibility
Best fit	Marketplaces, carriers, payments, e-invoice	Custom pricing, B2B flows, ERP mapping

One question settles it: will this integration still be running in three years, and who will be looking after it that day? If the answer is "I don't know", do not start a custom build. The Tecof integrations page shows which connections come ready and which can be extended through the API.

AI Agents and APIs: The New Layer

The biggest change to APIs in the last two years is that the caller is no longer only software but an AI agent. An agent takes a goal such as "list the products whose stock fell below five and pause their ads" and fulfils it by calling your store's API and the ad platform's API in sequence. That requires your API to be open to agents, meaning functions exposed with typed parameters. MCP standardises exactly that contract.

Permission ceilings for agent calls

The key an agent uses should never be the admin key. Give the agent its own user, grant only the endpoints it needs, log every call. Cap the price update function at 15 percent and no amount of clever prompting produces a 40 percent discount. We laid this out with a full permission matrix in our guide to agentic commerce. On Tecof, more than seventy tools spanning CMS, catalog, orders and analytics can be opened to agents with defined permission boundaries.

KVKK and data minimisation

If you send data to a model hosted abroad through an API, you are transferring personal data. District level is enough to estimate delivery time; full name and building number are not. Cover automated decision-making in your privacy notice, add the model provider to your list of data processors, and bring API logs into your retention policy. Any integration sending commercial messages must check IYS consent through the API; without consent, the message does not go out.

Standing Up a New Integration in 30 Days

Integration projects are usually planned as "the developer connects it and we are done" and are still in testing in month three. The timeline below is a realistic sequence for a single integration, say a new carrier.

Days 1-7: read the contract and the documentation

Open the API documentation and look for three things: the rate limit, the versioning policy and the list of error codes. Does the provider have a sandbox, and how do you get a test key? No code is written this week; if it is, it gets deleted next week.

Days 8-14: end-to-end flow in the sandbox

Push one test order all the way through: create the shipment, receive the tracking number, catch the status update via webhook, try the cancellation path. Write down what happens on each error code. Does "address not found" land with a person or get corrected automatically?

Days 15-21: live in shadow mode

Run the integration on live data while keeping the old method going. Compare the two every day. Do not switch the old method off until the difference reaches zero. This is the week that surfaces data quality problems: missing postcodes, wrong volumetric weights, mismatched province and district.

Days 22-30: monitoring and handover

Set up the daily success-rate counter and write down who gets notified when it falls below the threshold. Note where the keys are stored and who rotates them quarterly. If the person who built the integration is not the person who will run it, write a handover document. Only then switch the old method off.

Here is the job for tomorrow morning: put every active integration in your panel into one table, and next to each write the API version it uses, when its key was last rotated, and the error count for the last seven days. Any row where you do not know the version or the key date is the integration that will call you next month. On an e-commerce platform where integrations come ready, that table is available from the dashboard.

Frequently Asked Questions

Are an API and an integration the same thing?

No. The API is the door; the integration is the connection built through it. A carrier having an API does not mean your store is integrated with that carrier; someone has to wire that API into your system. A ready-made integration is that wiring done for you, a custom build is that wiring done to order.

Can I use an API without knowing how to code?

Calling an API directly needs code or at least a technical tool. Ready-made integrations and AI agents have largely removed that need, though. On a platform where you can say "connect Yurtiçi Kargo" in plain language, the API is called in the background and you see the result. Coding knowledge comes in when you commission custom business rules.

Who can I share my API key with?

Never share the admin key. Generate a separate key for the agency, the developer or the AI agent, grant only the required permissions, and revoke it when the work ends. Keys are not sent by email or chat; they are defined directly in the provider's panel. Set a quarterly rotation routine.

Should I choose webhooks or polling?

Webhooks for event-driven work (new order, payment approval, delivery), polling for batch work (nightly catalog sync, weekly reports). Webhooks can be missed, so running a fallback poll once an hour is a good habit. The most resilient setup uses both.

What happens when I exceed a marketplace API limit?

The provider rejects requests and the integration stops, usually silently. Stock updates halting on a campaign day means selling products you do not have. The fix is to batch submissions, send only changed records, and retry automatically on limit errors. Learn the limit before the campaign, not during it.

Will my integration break when the API version changes?

If the provider retires the old version, yes. Serious providers announce it months ahead, but an announcement nobody follows is useless. For ready-made integrations the update belongs to the provider; for custom builds it belongs to you. Ask for the version support window in writing.

What is MCP, and does it replace REST?

No, it sits on top. REST remains the standard for software-to-software communication. MCP standardises how an AI agent calls the same functions with typed parameters. For a store it means this: define your functions properly once and both software and different agents can use the same tools.

Who notices when an integration fails?

If that question was not answered during setup, the answer is "the customer". For every integration define a daily success-rate counter, a notification when it drops below the threshold, and a named person the notification goes to. These three steps are operational rather than technical, and missing in most stores.

Does a small store need API integrations at all?

Printing shipping labels by hand is fine at five orders a day. At fifty it is not. The threshold is how many hours a week the repetitive work consumes. Anything past five hours a week is enough justification for an integration, and ready-made integrations have put that threshold within reach of small stores too.