An API (Application Programming Interface) is a set of rules by which one program asks another for data or an action. Your website never goes "inside" a bank or a courier company: it sends a request in the format that system expects, and gets a response back. That is what makes card payments, delivery cost calculation and automatic CRM lead creation possible.
For a business owner an API is not a technical detail. It is the line between a brochure site and a site that does the work of a manager. Without integrations, somebody copies orders into a spreadsheet by hand, calls the courier and reconciles payments. Every integration removes one of those routines.
What is an API in plain words: the waiter analogy
Picture a restaurant. You are at a table and you want pasta. You do not walk into the kitchen, pick up a pan and ask the chef where the salt is. You call a waiter, name a dish from the list, and a few minutes later a plate arrives.
The waiter is the API. The kitchen — someone else's system, a bank, a courier, a CRM — does not let you in, and does not have to. The menu is the documentation: what can be ordered at all, and in what wording. The waiter knows the rules: how to pass the order on, what to do if a dish has run out, and how to bring the answer back.
Three things follow immediately. You can only order what is on the menu — if a payment provider has no such function, no developer can add it. You have to be precise, or the wrong thing arrives. And the kitchen can say no — your site must handle that answer gracefully.
How a request and a response work
The exchange is simpler than it sounds. Four steps:
- Your site builds a request: the endpoint, an access key, and the data — the payment amount and the order number, for instance.
- The request goes to the provider's server, which checks the key and the permissions.
- The provider performs the action and returns a response, usually as JSON: a status, an identifier, an error message.
- Your site reads the response and shows the result to a human: "Payment accepted", "Branch No. 12", "Please try again".
The access key, or token, is your pass. It proves to the provider that the request really came from your site. That makes a key as valuable as an admin password — more on that below.
Responses are neither instant nor always successful. The provider may be under maintenance, the rate limit may be exhausted, the data may be invalid. A properly built integration always defines what happens then.
The APIs we connect most often
This is not a theoretical list — it is what clients actually ask for. Timings assume the site already exists and the provider's documentation is sane.
| API | What it gives the business | Time to connect |
|---|---|---|
| LiqPay / WayForPay | Card payments on the site itself, no manual bank transfers | 2–5 days |
| Stripe | Payments from international customers in their currency | 3–7 days |
| Nova Poshta | Branch picker in the form, shipping cost, automatic waybill | 3–6 days |
| KeyCRM / Bitrix24 | Leads land in the CRM with source and owner, nothing gets lost | 2–5 days |
| Google Maps | Directions and branch locations on the contact page | 0.5–1 day |
| Telegram | New-lead notification in a chat within seconds | 0.5–1 day |
For an online store the baseline is payments plus delivery plus CRM — without them the shop simply moves the work onto a manager. For a corporate website, CRM, maps and Telegram alerts are usually enough.
Why integrations cost money
The usual question: the provider already has an API, so why is this not an hour of work? Because connecting is more than calling an endpoint. It is accounts and keys, a sandbox, field mapping (your "Customer name" against the CRM's `contact_name`), error handling, retries, logging, and testing against real orders.
Our real ranges: a typical integration is £200–500 — payments, a courier, a CRM with standard fields, a messenger. A complex one is £1,000–3,000: non-standard logic, two-way stock sync, a legacy accounting system with no usable documentation, or several services that must stay consistent with each other.
A practical example is the Raul Avto auto-parts store: its part finder and calculator run on integrations, and those, not the design, set the project timeline.
Common API mistakes
Keys in public code
The most expensive one. An API key left in front-end files or pushed to a public repository is found by automated scanners within hours. What follows is requests made in your name, an exhausted quota and, at worst, real charges. Keys belong on the server only, in environment variables, and should be rotated when you change contractors.
No error handling
The provider goes down and the customer sees a blank screen or an endless spinner. The order is lost, and the owner finds out a week later. The right behaviour: a clear message, a retry, a log entry and an alert to the administrator.
Nobody reads the logs
An integration quietly stops working after a provider-side update — this happens regularly. Without logs and monitoring you discover it through falling sales rather than through an error.
Connecting everything at once
The urge to ship "all the integrations" at launch pushes the launch back by months. What works: payments and leads first, the rest after the first real orders.
Read next
For the full picture, see what a CMS is — that is how you manage content, while the API manages data exchange. And separately, how a website admin panel works, which shows where integration data actually lands.
