API

In practice an API looks like a list of addresses and the rules for calling them. The client sends a request, say GET /orders/123 with a token in the header, and the server returns a structured JSON response plus a status code: 200 when all is well, 404 when the object does not exist, 401 for access problems, 429 when a rate limit is hit. The two common styles are REST, where data is exposed as resources and addresses, and GraphQL, where the client describes exactly which fields it wants in a single query.

On a commercial project the API work is almost always the most underestimated line in the estimate. It is how the site exchanges data with the accounting system, the payment provider, the delivery service, the CRM, the mailing platform, the telephony. Each of those is not a one-hour connection: it is field mapping, error and timeout handling, retries, a queue, logging, and a separate plan for when the other system is down. That is why integrations typically eat 10-15% of a website budget and are the usual reason a schedule slips when they were priced by guesswork.

Three traps show up more often than the rest. First, no documentation: when the API contract lives in one developer’s head, changing contractors turns into reverse engineering. Second, breaking changes without versioning: a field gets renamed and the mobile app stops working for half the userbase, because not everyone updates and not immediately. Third, treating somebody else’s API as if it were your own: third-party services have limits, degradations and maintenance windows, and your system has to survive them without losing orders rather than returning a 500 to the customer.

• Machine-readable documentation (OpenAPI or a GraphQL schema), not a chat thread.
• Versioning and a stated deprecation policy for endpoints.
• Token authentication with scoped permissions rather than one all-powerful key.
• Idempotent money operations: a repeated request must not create a second payment.
• Rate limits, timeouts, retries and a queue on the calling side.

Related terms

• Headless CMSA headless CMS is a content platform with no built-in templating layer: editors work in a familiar admin panel while a website, a mobile app and any other channel pull the same content over an API and render it themselves.
• MicroservicesMicroservices are an architecture in which an application is split into several independent services, each with its own data and release cycle: they talk over the network through APIs, deploy separately and scale individually, but they demand mature infrastructure.
• SLAAn SLA is a service level agreement: it fixes system availability as a percentage, response and resolution times by incident severity, the hours support operates, and the compensation owed when the provider fails to meet those numbers.
• Technical specificationA technical specification is the document that fixes what exactly will be built and on what grounds the work counts as accepted: goals, roles, scenarios, screen-level requirements, integrations, non-functional requirements and an explicit out-of-scope section.
• AI agentAn AI agent is a program in which a language model does not merely answer but acts: it receives a goal, chooses its own tools such as search, APIs, a database or sending mail, works through steps in a loop and stops when the task is done or a limit is hit.

Related services

• Web app and Telegram Mini App developmentFor when a site is no longer enough and you need a product: an account area, a dashboard, an internal tool or a Mini App inside Telegram. We design the architecture, write the backend and frontend, and take it to release.
• IT consulting and product auditThe most expensive mistakes in software happen before the first line of code: a misread problem, a stack chosen out of a contractor’s habit, and a specification that does not exist. Consulting exists to settle all of that before the development meter starts running: what to build, out of what, at what cost and in which order. The result is a document, not an opinion on a call.
• Website development, end to endWe build sites that still hold up a year later: from a one-page CMS build to a store or a web application on React and Next.js. One team for design, code, integrations and launch.

Read more

• How to Choose a Tech Stack: Criteria That Outlive the HypeA stack is a five-year commitment usually made in a single call. Here is the order the decisions should be taken in, the criteria that carry real weight, working stacks for six project archetypes and what a wrong choice costs.
• What to Build Your Site On in 2026: Tilda, WordPress, Bitrix or Next.jsBuilder, CMS or custom code is not a matter of taste but of scenario and planning horizon. We break down three-year cost of ownership, the ceiling of each platform, and what it costs to move if you picked wrong.