Service
Integration and automation — built for the day it fails.
An integration is two systems passing data to each other without a person in between: an order from the site into 1C, a payment from the bank into the CRM, stock from the warehouse into the store. A single integration typically takes 3–5 days; an automation package spanning several systems takes 1–3 weeks. After a short brief we return within 3–5 days with a data-flow diagram, stages and a firm quote, and that stage is not billed.
- One integration
- 3–5 days
- Automation package
- 1–3 weeks
- Estimate
- 3–5 days
Connecting two APIs is the easy day
Wiring one endpoint to another takes about a day. Everything after that is spent on a single question: what happens when the other side does not answer. It will not answer, reliably — a server goes down, a rate limit is reached, a field changes shape without notice. The entire difference between an integration that runs for a year and one that gets repaired every month lives in how that case was handled.
Light connections can run on webhooks: an event happens, a request goes out. That is cheap and appropriate where losing one event does not matter — a notification, an analytics marker, a message posted to a channel. The moment orders, payments or stock are involved, a webhook alone is not enough. A queue goes between the systems, every message is acknowledged by the receiver, and a failed delivery is retried on a widening interval rather than dropped.
Then idempotency. If a request is retried, the order must not be created twice — that is what a unique operation key is for. Without it retries stop being insurance and become a source of duplicates. We build it in by default rather than quoting it as an option.
And observability.
Integrations fail quietly. Nobody sees an error; orders simply stop arriving, and it is noticed a day later through a customer complaint. So monitoring and alerting are part of every connection we build: we see the break, not you. Our Merkuri project runs on exactly this — data moves between shippers, brokers and customs databases and is confirmed at each step.
What the work covers
Included
- Audit of current processes and systems
- Data-flow diagram: what moves from where to where
- API review and confirmation of the limits
- The integration itself and the data transformations
- Queueing, retries and duplicate protection
- Error logging and alerting
- Scenario testing on a staging environment
- Monitoring: what broke and when
- Documentation: the diagram and a support guide
Not included
- Third-party service subscriptions
- Licences for the systems being connected
- Signing agreements with banks or operators
- Rewriting the legacy system
- Manual data cleanup
What you receive
- A working integration on your infrastructure
- Repository and configuration in your account
- The data-flow diagram, written down
- Monitoring and error alerts
- Restart and rollback instructions
- A 3-month warranty
What drives the price
We do not publish a price list: one connection can take a week or a month, and the difference is the quality of somebody else’s API. These move a quote.
- Number of systems and the direction: one-way or both ways
- API condition: documented REST, a legacy format, or nothing at all
- Data volume and frequency: a nightly sync or real time
- Transformation complexity: fields that map directly, or values computed by rules
- Reliability requirements: where loss is unacceptable, queueing and retries are their own scope
The data-flow diagram, the stages and a firm quote reach you within 3–5 days of the brief, at no cost.
Stack
Chosen per task. A light connection lives on webhooks; heavy flow goes through a queue.
Protocols
- REST API
- Webhooks
- GraphQL
Queues
- Celery
- RabbitMQ
- Kafka
Systems
- 1C
- amoCRM
- Bitrix24
- WhatsApp API
Operations
- Docker
- CI/CD
- Monitoring
Stages
-
Audit and data-flow diagram
3–5 daysWhich systems exist, who re-types what by hand, and which step costs the most time. Output: a diagram and a quote.
-
API review
1–2 daysDocumentation, rate limits, test credentials. This is where a missing API surfaces — and we say so immediately.
-
Building the connection
2–5 daysTransport, transformations, queueing and retries. A working version on staging.
-
Scenario testing
1–2 daysThe happy path, the other side being down, a duplicate send, a malformed payload. Each is tested separately.
-
Release and monitoring
1–2 daysCutover to production and alert configuration. We watch the flow with you for the first few days.
-
Warranty
3 monthsDefects are on us. If a partner changes their API, that is a separate small job — see the questions below.
When you do not need this
Automation only pays back through repetition. We raise these on the brief ourselves.
The process runs once a month and takes 15 minutes
Writing an integration and then maintaining it for years to save three hours a year does not add up. A template or a simple export is enough here.
One of the systems has no API
With no database access and no export there is nothing to connect to. Sometimes the only honest answer is to replace that system, and we will say so before the start.
The process changes every month
An integration sets today’s rule in code. Stabilise the process first.
The data volume is small
Re-typing five orders a day takes a few minutes. At that volume automation will not pay back for years. We will do that arithmetic on the brief and give you the number.
If one of these describes you, write anyway. The audit is free, and the conclusion is often "do not automate that step, automate the one next to it".
Related work
Frequent questions
What if a system has no API?
We look at the options: direct database access, a scheduled export, sometimes automation at the interface level. If none of them work we say so on the brief rather than inventing a solution.
What happens when the other side is unavailable?
The request is not lost: it stays in the queue and is retried on a widening interval. After several failures an alert goes out. When the service recovers the queue drains itself and the data is intact.
Could orders be duplicated?
No. Every operation carries a unique key, so a repeated request does not create a second record. Without that, retries turn from insurance into a source of duplicates, which is why it is standard rather than optional.
Will we have to replace our current systems?
Usually not: the integration is built on top of your current systems, and replacement is only necessary where a system offers no entry point at all — which surfaces during the audit, not halfway through the build.
A partner changed their API — who fixes it?
Within the three-month warranty, we do, at no cost. After that it is a separate small job. External APIs change once or twice a year and we say so upfront. That is why monitoring is part of every connection. We see the break, not you via a customer complaint.
Which steps should we automate
A short brief is enough: which systems you run, what gets re-typed by hand, and how many times a day. We come back within 3–5 days with a diagram and a quote.