Integration of the site with a third-party service via API
The ready-made module closes popular areas: carrier, payment gateway, familiar CRM. Next, the zone begins where there is no connector for your pair of systems, and the exchange has to be written.
The estimate here defines someone else's side, not ours. Does it have a test loop, does it report changes with a webhook, does the record have an identifier that allows it to be recognized a second time, and does it distinguish between failure and success. The same exchange on a prepared interface takes a week, and on an interface that responds to everything with a 200 code and an empty body - three times longer.
Therefore, we start not with the code, but with intelligence: we pull the methods and see what the interface can actually do. The period of work after it is 7–17 working days. We name the cost when we see someone else's API, not from the task description.
working days, free of charge, not included in the deadline
8
What we check in the interface
points: from authorization method to versioning
queue with repetitions, idempotent key, notifications
If someone else's service did not respond
comparing the number of records on both sides by two methods
Acceptance of work
30
Guarantee
calendar days for completed work
Process steps
Transparent stages with approval at every step
Total duration:7–17 days
1
Intelligence of someone else's interface
2-5 working days, free of charge
We pull methods and check eight points: documentation, authorization, webhooks, limits, pagination, identifier, error behavior, versioning. The output is a written conclusion and a draft exchange contract.
2
Exchange contract
1-3 working days
We record in writing: which records are transmitted, in which direction, with what frequency, by which identifier and what is considered a success. It is this document that then closes the dispute about the boundaries of the work.
3
Prototype on the test circuit
2-5 working days
The first working exchange in one direction and on the same type of records. If there is no contour in someone else's service, we pick up the stub with the answers according to the documentation and separately check it on live data later.
4
Failure behavior
2-4 working days
Queue with retries, idempotent key, log with request and response body, masking of personal data, notification to responsible. Here we intentionally break the other side and see if a double has appeared.
5
Reconciliation on live data
1-3 working days
We count records on the source and on the receiver using two independent methods, and explain each discrepancy. The run runs in a mode that counts changes, but does not record anything, so the ID error gets to the first record.
6
Launch and transmission
1-2 working days
We transfer the exchange to combat keys, turn on the schedule and notifications, go through the log with your person, give the repository and instructions.
Technologies & integrations
What we build on and what it connects to
Stack
REST with JSON — we take the format that gives someone else's side, and not the one that is more convenient for us
XML and CSV — when the service lives on downloads, not on requests
Webhooks with signature verification; limit: some services do not have them at all
Schedule polls via cron; limit: there is always a window of divergence between cycles
An idempotent key to the operation is protection against duplicates during repetition
A queue with retries and increasing retreat
Exchange log in a separate table with masking of personal data
A test loop of someone else's system, and in its absence, a local stub
OpenCart 3 and 4, WooCommerce, Next.js on the site side
PHP, MySQL, Node.js
Git is your repository
Integrations
arbitrary REST API with documentation
incoming and outgoing webhooks
accounting systems 1C and BAS
KeyCRM and other CRMs by API
warehouse and ERP systems
payment gateways
Carrier API
marketplaces and price aggregators
postal and SMS services
Telegram bot for notifications
GA4 and Google Tag Manager
What's included
Complete list of work and what you get as a result
The contract for the exchange of a separate document: which records, in which direction, with what frequency and by which identifier - work is then accepted according to it
Exchange on the mechanism that someone else's service actually has: webhooks with signature verification where they are, scheduled polls where they are not
Idempotent key per operation: Retry after a failure updates an existing record rather than creating a new one
Queue with retries and increasing backoff - unavailability of the other party delays the transmission, not losing it
Exchange log with request and response body, personal data masked
Notification to the person in charge when the queue is not resolved within the agreed time
Reconciliation of live data by two independent methods prior to job transfer
Instructions to your person: where is the magazine, how to restart the manual transmission, how to distinguish the failure of the other side
Sources in Git are on your side - the integration can be picked up by another developer
Guarantee of 30 calendar days for completed works
When this service isn't right
What's not included — so there are no surprises at delivery
Licenses, tariffs and commissions of third-party services
Changes on the side of someone else's system: if the method is not in the API, only the owner can add it
Tidying up your directories and merging duplicates is a separate job
Support after the warranty period, including conversion to a new version of a third-party API
Hosting and computing power for exchange
Who it's for
Situations where this service delivers results
Scenario 1 of 4
There is no module for your pair of systems in the market
Industry accounting program, narrow reservation service, customer's internal system, self-written warehouse. The extension market covers mass areas, and the more specific the system, the less likely you are to find a ready-made one. Here, the integration is written for a specific interface — and that is why it begins with its exploration.
We'll review your situation in a free audit
Scenario 2 of 4
The module is there, but it does not do what is needed
Transmits half of the fields, does not know how to reverse, creates a new record instead of updating an existing one. Adapting someone else's extension is sometimes more expensive than writing an exchange for your contract: in the first case, you blindly follow someone else's logic, in the second case, you own it.
Scenario 3 of 4
The exchange already exists, but no one knows if it works
The data diverges somewhere, and there is no log, so the analysis begins with assumptions. We measure both sides and show exactly where the recording is lost. It is often found that transmissions fall silent for years - the response status is successful and the body is empty.
Scenario 4 of 4
A catalog or order lives in several systems at once
Site, warehouse, manager's office, site. Each pair of them needs an agreement on the identifier and direction of transmission. Our case is about this: the description rewriting platform accepts catalogs from five sites in four formats, and there is no ready-made connector for such a mixture.
Write a turnkey integration versus waiting for a module from a vendor
How this option differs from the alternative
Waiting for the finished moduleOur approach
When will appearunknown: your pair of systems may not be in the vendor's plans at all7-17 working days after reconnaissance, date in the contract
Script coveragewhat the author of the module considered to be a typical caseexactly your records, fields and rules from the exchange contract
Behavior in the event of a failure of the other partyas done on the inside — not visible on the outside until the first incidentqueue with replays, idempotent key, log, notification
When someone else's API changeswaiting for the update and for the author to release itwe correct, the breakdown is visible in the journal of the same day
Possessionlicense and dependency on the author of the modulethe source is yours, the repository is yours
Moneylicense and subscription fee, sometimes zero — if the module is free and suitableone-time development, then only changes on the other side
Free exploration of someone else's interface
Before the estimate, we find out one thing: whether the other party is ready to exchange at all. Some of the requests rest not on the code, but on the fact that the required interface is simply not available in the service — and it is more profitable for both to find out before payment.
What we measure
Is there documentation and does it match the behaviorWe do not read the description, we pull several methods and compare the answer with the promise. Divergence is the norm here, and it eats up days at the development stage if it is not found in advance.
Authorization methodPersistent token, OAuth, or just a browser session. The latter means that there is no public interface: it remains to simulate the work of a person in the office, and we say about the fragility of such a solution before the contract.
Webhooks or surveysIf the service itself notifies about the changes, the exchange takes place almost instantly. If not, we interview him on a schedule, and between cycles there is a window in which the two sides see differently. The size of the window is called the number before the start.
Request limits and paginationHow many requests per minute are allowed and how a long list is given. A catalog of several thousand items at a hard limit is unloaded in minutes, and this affects the exchange schedule, not just the estimate.
A stable record identifierBy what value does someone else's system recognize the same product or order a second time. Without it, re-transmission produces duplicates, and it becomes noticeable when there are already hundreds of them.
Which comes in response to an errorA suitable interface is the difference between failure and success. Invalid returns a 200 code with an empty body, and outwardly it looks like a successful transfer. In the cosmetics store, which we measured on 07/31/2026, the regular feed and the site map gave exactly that — 200 and zero bytes.
Test circuitIs it possible to drive the exchange without touching the combat data. If there is no contour, we raise the plug on our side - it is more expensive, and the line appears in the estimate openly.
Versioning and change alertsDoes the interface have versions and does the owner notify about changes in advance. A service that changes the format silently makes integration a constant expense — and you need to know this before you start.
What you get
A written conclusion on eight points of intelligence: what the interface can do, what it can't do, and where there are holes in it.
Draft exchange contract: what records, in which direction, with what frequency and by what identifier.
An estimate of works with a deadline and a list of what may fall out of the estimate.
A 40-minute conversation on the document — with your developer, if you have one.
Timeline: 2-5 working days
Why is it free
Because the most expensive mistake here is to start development for an interface that is not ready for exchange. A few days of exploration is cheaper than a week of work that will have to be thrown away.
What's next
After the investigation - amount, term, contract. If the integration for your task is not possible or does not pay off, you will hear about it in the first email, and there will be no bill.
Short form: your contact and site URL
Did not find your case?
Describe how it works on your side — we will tell you whether “Turnkey integration: third-party API, data exchange, webhooks” fits and what it means in your situation. No brief and no call: one question, one answer.
Contract, act and 30-day warranty
Every project gets a written contract: scope, deadlines, amount, acceptance procedure. After delivery — act and invoice, then 30 calendar days of warranty.
Sole proprietor & bank transfer
The contractor is a registered sole proprietor. Payment by invoice with closing documents.
Rights & access — yours
Code, design and materials transfer to you after full payment. Domain, hosting, repository and analytics are registered to you.
Client portal instead of email chains
During the project you get access to a portal: contracts, invoices, acts and project status in one place.
European clients
Among our work — projects for Norway, Bulgaria, Moldova and Spain.
Verifiable numbers
Every case in the portfolio comes with a link to a live site and a technical measurement.
Audit first, then pricing
There is no price list on the site intentionally: the scope of the same work differs multiples between clients.
We say "no" when unsure
If the task isn't ours or the deadline is unrealistic — we tell you upfront.
What affects the price
Why two seemingly identical tasks are priced differently
The readiness of the other partyThe main component of the estimate, and it does not depend on us. A documented interface with a test loop and webhooks is the bottom line. The interface without a description, without an outline and without versions is the upper one, because the format has to be restored from the network requests of the cabinet and checked on the stub.
Number of record typesPassing only orders is one job. Items, balances, prices, statuses, and returns are five separate field and ID arrangements, each of which must be reconciled.
Direction of exchangeOne stream is cheaper than two by about half. In the reverse direction, a conflict is added: if a record is changed on both sides at the same time, someone has to decide whose version is the main one, and that decision is yours, not ours.
Volume and frequencyA hundred operations per day take place in any way. Tens of thousands of items hit the limits of someone else's service every hour, and then pagination, batches and schedules appear - a separate line of work.
The status of your dataIf there is no common identifier between the systems, the exchange begins with a handbook comparison. This work is not included in the development and is evaluated separately.
Requirements for fault toleranceQueue, replays, log and notifications are about a quarter of the effort. You can refuse them, but then the first failure of the other party means a silent loss of data.
Cases
Tasks and results in numbers — all metrics measured by us
own SaaS platform for rewriting product descriptions, accepts catalogs from five sites
Task
Accept feeds of catalogs from Prom.ua, Rozetka, Khorozhop, OpenCart and WooCommerce in XML, YML, CSV and Excel formats - there is no ready-made connector for such a mixture, each platform gives its own.
Solution
Application on Next.js with its own parsing of four formats, customization of text style and SEO structure of headings. Payment — non-cash transfer to the FOP's IBAN, minimum top-up of UAH 50. JSON-LD markup with SoftwareApplication, Offer, Organization, WebSite and FAQPage, connected PWA manifest.
Result
Measured on 07/31/2026: first response 220.6ms, full load 329.8ms - fastest response among 16 portfolio sites measured, HTML 140.8KB, 8 public pages. We call the limit of attribution directly: the import of catalogs itself is not verified from the outside, we measured what is visible from the visitor's side. The same measurement gave two defects: the robots.txt declares /sitemap.xml, which returns a 404, and there is no analytics counter on the landing page.
online store of professional cosmetics, catalog of over 5,000 items
Task
Calculate a live catalog where regular store data sources do not give anything.
Solution
We counted on a regular search of the platform with an empty request page by page, because /sitemap.xml and the product feed of the platform correspond with code 200 with a zero body.
Result
5,561 products — 55 pages of 100 items plus 61 for the last one, measured on 07/31/2026. First response 801.2ms with 153.8KB markup. For integration, the main thing here is different: two standard data sources return a success code and an empty body, that is, the response status is not a proof that the data has arrived. The same measurement showed that there is no analytics counter on the main one.
wholesale B2B catalog of goods from China, almost 6 thousand items
Task
Verify the actual volume of the catalog with two independent sources before building the download on it.
Solution
We counted in two ways: by regular search of the platform page by page and by site maps of both language versions.
Result
5,830 products: the search yielded 58 pages of 100 items plus 30, site maps — 6,234 addresses for each of the two languages, a total of 12,468. The first response was 506.9 ms with 333.1 KB of markup, measured on 07/31/2026. The difference between the 5,830 directory items and the 6,234 sitemap addresses must be resolved before the exchange starts, and not after the first discrepancy in the balances.
What we need from you
We can't start without this — best to prepare in advance
1Documentation of someone else's API or access to the cabinet from which it is visible.
2The key to the test circuit is the test circuit itself: we do not need combat data at the development stage.
3Contact of a technical person on the side of someone else's service with the right to answer about limits and format.
4A list of records and fields that are really needed: "everything there is" turns the exchange into a constant expense.
5Identification rule: by which value the record is identified the second time.
6One person on your side with the right to agree to the exchange contract and accept the job.
If something is missing — let us know, we'll help you gather it or do it as a separate task.
FAQ
Most frequently asked questions — with concrete answers
How to understand that integration is even possible with our service?
The answer to this is not the description on the vendor's website, but the interface itself. We pull together a few methods and look at eight things: documentation, authorization, webhooks, limits, pagination, record ID, error behavior, versioning. The most frequent stop sign is authorization only by a browser session: there is no public interface, and technically it remains to imitate the work of a person in the office. We do this, but we say directly that the solution is fragile and breaks when the layout of the office is changed.
There is no documentation at all — is this a verdict?
No, but this is a different scope of work and a different risk. When there is no description, the format is restored from the network requests of the office: addresses, composition of fields and type of response are visible. It's easy to read. The problem is deeper: no one is obliged to keep such an interface unchanged, and the owner can rework it tomorrow without warning anyone. We write this risk in the contract as a separate line so that you make a decision before the first breakdown, not after it.
Why doesn't a successful response mean that the data has been transferred?
Because the response code describes the transport, not the result. A suitable interface distinguishes failure from success and explains exactly what is wrong. Unfit gives 200 and an empty body for anything. This is not a theory: in the professional cosmetics store we measured on 07/31/2026, the staff site map and the product feed of the platform corresponded with a code of 200 with a zero body - both sources formally worked. Therefore, we consider a parsed answer with the expected fields as success, and not the fact of connection itself.
Webhooks or Scheduled Surveys?
Webhooks, when they exist: someone else's system reports the change itself, the data diverges by seconds. A large part of the services do not have them, and then there remains a survey once at a certain interval. The main thing here is not the mechanism, but the named number: between the cycles there is a window into which the two parties see differently. For stock, this means that the product can be bought twice. We agree on the size of the window before the start and write in the exchange contract, instead of the word "instant".
What will happen when someone else's service is down?
The operation must not disappear - a demand from which we will not back down. The transmission is queued and repeated with an increasing offset until it passes. So that repetitions do not produce duplicates, each operation carries an idempotent key: the foreign system recognizes it as the same and updates the existing record. If the queue is not resolved within the agreed time, the person in charge receives a notification. Without these three things, a failure on the other side becomes a silent loss of data that is noticed in weeks.
How do I check that the exchange is working properly and not just working?
Reconciliation by two independent methods, and we do it before the transfer of work, and not after the complaint. An example from the measurement on 07/31/2026: in the wholesale B2B catalog of goods from China, the volume was counted twice - the standard search of the platform gave 58 pages of 100 items plus 30, i.e. 5,830 products, and the site maps of the two language versions gave 6,234 addresses each, a total of 12,468. Each method counts its own set of addresses, and they are not obliged to converge - they must be the difference is explained. The same order of actions is transferred to the acceptance of the exchange: account at the source, account at the receiver, resolution of the difference.
How long does the work last and why is the sum of days by stage greater than the deadline?
7-17 working days after reconnaissance; the intelligence itself lasts 2–5 days, it is free and does not include a deadline. The lower limit is one transfer direction and one write type on a documented API with a test loop. Top - two-way exchange with multiple record types and reverse statuses. The stages are partially parallel: we write the queue and log while we wait for access or a response from a technical person on the other side.
Will the integration break when they change their API?
Once upon a time, yes, and planning for it is more honest than promising an eternal job. Therefore, the exchange is written in such a way that the failure is visible: the log shows which method started to respond differently, and the notification comes on the day of the failure, not on the day when the report failed. The 30-day warranty covers errors on our part. Changes on someone else's side - a new job with a separate assessment; services with versioning give it time, services without it do not.
Do you have a case specifically with our service?
Most likely not, and we will not invent it: someone else's exchange is not checked from the outside. We show what was actually measured. The closest to the task is our own platform for rewriting product descriptions: it accepts catalogs from five sites in four formats, there is no ready-made connector for such a mixture. We call the limit open: the import itself is not verified from the outside, we measured the visible — 220.6 ms to the first response with 140.8 KB of markup. We will analyze your interface in the same way specifically, up to the estimate.
Do the code and keys remain ours?
Yes. The repository is yours, the outputs are transferred together with the work and instructions: where is the log, how to restart the transfer manually, how to distinguish a failure of the other side from your own. Access keys are issued to you, not the contractor, and reside in environment variables, not code. An integration that can only be supported by its author is a dependency, and we don't want to sell that.
Send a link to someone else's API documentation — or say it doesn't exist.
In response — a conclusion on eight points of intelligence, a draft of the exchange contract and an estimate of the works with a deadline. If the interface is not ready for sharing, you will hear it in the first email.
From measured cases5,561 products — 55 pages of 100 items plus 61 for the last one, measured on 07/31/2026
There is no price list on the site on purpose: the same work differs several times over between two clients, and a “from” figure explains nothing in that case. First a free audit — we count your pages, duplicates and speed — then we name the sum and the deadline and fix both in the contract.