Skip to content
megapromotingLet's talk

Expertise · Integrations and Automations

Your systems talking to each other, without someone retyping the same data.

We connect the scheduling system, the shop, the CRM, spreadsheets and messaging channels so that an agent or a scheduled rule can read and write to them in real time. Keys stay on the server, tools have written limits, and every integration is also tested for the case where the other system goes down.

Already builtProprietary integrations, written and run, measured today in code: the connector for the Altegio booking system (946 lines, with six tools exposed to the agent), the amoCRM CRM connector (2,888 lines in the messaging platform, plus 12 server functions in the voice platform), Bitrix24 (903 lines, plus 4 functions), Google Sheets (615 lines, plus 10 functions and a dedicated service account), the live catalogue above the shop (platform service, 318 lines), lead notifications on Telegram (1,776 lines), SMS via Infobip with anti-abuse limits, scheduled automations (1,088 lines) and the chat channel of a local ads platform (2,459 lines). In execution, the agent can call 15 types of internal tools, in addition to webhook tools and custom code tools run in isolation.

An integration is not a logo on a page. It is the answer to a very concrete question: can this system be read and written in real time, by whom, with what rights, and what happens when it does not respond? That is why our first question for any integration is not „with which API”, but „what public gateway does it have”. Sometimes the answer changes the cost of the work completely: WooCommerce shops, for example, expose a public shop API that does not require any consumer key, so a new client connects only with its site address — not with credentials it has to generate, send and then rotate.

In our messaging platform, a tool that the agent can call during a conversation is one of three types: a webhook call, custom code run in isolation, or an internal platform tool. We prefer the internal tools, because they keep the keys out of the database: today there are fifteen, from reading a page and writing to a spreadsheet, to availability and creation of a booking, sending an SMS and querying the product catalogue.

The difference between an integration that holds and one that breaks lies almost always in small, on-the-ground details. The booking system returns nothing if you ask for a specialist's hours for a service they do not perform — the service and the specialist always travel together. The same system refuses if the request comes with the HTTP library's default header, so each request must identify itself explicitly. A shop can report a zero price for products with variants, and a search on empty words returns the full catalogue. There are ten such details per integration, and none of them is in the documentation.

Above integrations sit automations: rules that run in time, not at someone’s request. With us, they are scheduled with an in-process scheduler — resuming unanswered conversations, the first message to a new contact, pausing and restarting the agent after working hours — each with its own counters, so you can see how many runs there were, how many messages were sent, how many were skipped and why. An automation without a counter is an automation you cannot say is working.

Transparent automation — integrations that can be verified · video in Romanian, with subtitles and a transcript in English

Full transcription

Let's get straight to the point. Today we will dissect the technical and, honestly, often overlooked realities of automation through AI-based assistants. We will focus on a super pragmatic approach to the iCat.md platform developed by Mega Promoting. We have no marketing promises today and, definitely, no vague concepts. We are talking about a platform already in production, with functionality explained directly from the database architecture. So let’s see what fully transparent automation actually looks like. The agenda for this analysis is simple and to the point. We go through the time problem, the mechanics of the technology, a real case, the system’s clear limits, data management, and the next steps. We start with the first section, the time problem.

You all know that extremely frustrating question? Why does an entire support team lose hours every day, day after day, writing by hand answers to the exact same five questions? The information already exists on the company’s website, but even so, customers keep asking for the details repeatedly. And that is exactly the core of our problem. Without the right technical solution, all these repetitive requests simply clog direct messaging, it does not matter whether it is Instagram or Messenger. As a result, responses are massively delayed for customers who truly have a complex problem, requests get lost in the sea of messages, and the whole support process becomes practically a black box that you cannot verify or measure. Part two.

How does the technology actually work under the bonnet? Here’s the thing. The platform setup is based on four very logical steps. First, we connect the communication channels using custom code. Then the entire knowledge base is indexed. Next comes linking the tools that can carry out actions in your existing systems. And in the end, and this detail is vital, a clear route is configured and logged directly in the database through which the bot hands the conversation over to a human operator. Everything is a visible and fully configurable system. Now, one absolutely fascinating aspect. We are not talking from hearsay here. These are settings extracted directly from the database schema. When the assistant needs an answer, it uses a so-called hybrid search.

By default, the algorithm extracts 5 text fragments, applies a strict similarity threshold of 0-70, and gives 30% weight to exact word matches. Everything is processed through the Text Embedding 3 Small model. In practice, the system turns words into mathematical concepts in order to capture the exact context. The responses are not guesswork, but pure mathematics. Remember this number. 15. It is an absolute technical limit in the system. It represents the maximum time, in seconds, allocated to run any tool or search. If an external integration takes longer than that, say it needs 40 seconds, we cannot leave it in the live conversation flow. It has to be processed asynchronously, otherwise the natural rhythm of the dialogue would break completely.

And there is more. People write in chat in bursts, right? 2, 3, 4 short messages sent one after another. To keep the system from going mad, there is a 15-second concatenation buffer. Everything that comes in during this window gets merged and becomes one clear request. On top of that, on platforms like Meta, where you sometimes run into duplicate messages sent by mistake, the system applies a 120-second memory filter on the message ID. That way, the customer gets one coherent response, not 3 false alarms. Section three. Let’s look at a real case. We have this classic e-commerce scenario. We have an online store, with an impeccable catalogue on the website, but which receives an avalanche of private messages on Instagram and Messenger?

Is it in stock? How much does it cost? Here the integration was done elegantly, connecting the assistant directly to the public Store API interface from WooCommerce. Without security complications, the live catalogue of the store was simply put into the assistant’s hands. Only here does the technical reality of each platform intervene, even under the umbrella of the same company, such as Meta. On Messenger, the assistant can show you beautiful product carousels. On Instagram, the bot will reply only with text and at most a simple image. Why? Simply because Meta does not support those generic templates on Instagram. The assistant must play exactly by the rules of the channel it is on. This is the critical point.

What happens when the bot is out of its depth? Well, in the database the conversation has explicit states. When a question goes outside the catalogue’s comfort zone, the discussion thread immediately moves from the bot state to the human state. And the brilliant part is that the system tracks the time in which the human operator replies, marking everything clearly: OK status, warning, or overdue deadline. All the context is handed over to the person, without losing absolutely anything along the way. Section A4 System limits Because transparency means knowing what it cannot do. There are a few firm limits that we have to accept. You cannot send proactive messages on WhatsApp if more than 24 hours have passed since the customer’s message.

Meta will throw an error, more specifically error 131047, and the action will fail. The system does not make PDF files, it does not read attachments. On foreign languages, translations work only in one direction. The customer receives the translated answer, but the operator sees the original. And although the integration with 999.md works, it is unofficial and relies on browser cookies. If the platform changes its mechanisms, the connection drops and needs fixing. And make sure you remember this. The assistant is a mirror of your data. A wrong price on the website will definitely become a wrong price in the conversation. It acts as a reader, not as a store manager. It will not correct human errors in catalogues on its own initiative.

The technical infrastructure here is not a game. Everything is kept on a private Microsoft Azure server. We’re discussing an extremely structured MySQL database, with over 80 tables clearly modelled to separate channels and for audit. Access keys for WhatsApp, which are highly sensitive, use fernet encryption. On top of that, at the web level, the domains for the chat widget are added manually to a whitelist. No one connects without explicit permission. But we do need to address an obvious reality. People will write all kinds of personal data in those chat windows, phone numbers, addresses. Technically, you can’t block a free text field. So the solution is administrative. When you implement such a system, from second 1 you need clear retention policies that dictate exactly who is allowed to see that data and for how long it is stored.

And we’ve reached point 6. The final step. The central philosophy of the whole system can be summed up by this quote. An ultimate assistant is not the one that composes poems or writes beautifully, but the one that is connected to real information and, very importantly, knows exactly where it has to stop. Effective automation in business means the correct capture of data and the confidence with which you hand control over to a human operator at the right moment. Therefore, the next step is not to buy software, but to carefully analyse your current processes. Assess which workflows are truly worth building and automating, how they can be connected safely, and, most importantly, establish how you will measure the results with real data, not with marketing illusions.

And I’ll leave you with this thought. Of all the communication processes in a business, which are the ones that truly require a person’s empathy and tact, and which are, in fact, just repetitive tasks waiting simply to be connected precisely to the correct database? Any automation plan should start from this question. Thank you for being with us in this analysis!

What it covers

The work, by component

First, we check what public door the system has

For WooCommerce stores, we use the public store API, which does not require a consumer key: the client connects only with the site address. It is a choice with real consequences, not just an aesthetic one — we replaced with it hand-written tools that kept store keys in clear text in the database. When the system has no public door, we move to authentication, but then the key becomes something to be managed, not something forgotten in a database row.

Keys stay on the server, not in the tool and not in the page

The SMS tool is internal to the platform precisely because the environment where a tool’s own code runs does not have access to environment variables — if sending were done from tool code, the key would have to be written to the database, and that key can send messages at everyone’s expense. The same with the scheduling system: the partner token is a single one, kept in the server environment, while the client only sets their company identifier.

The agent calls the tool during the conversation, with parameters and a deadline

Each tool has a description written for the model, typed parameters with what is required and what is not, and its own execution deadline — from 15 seconds for a list of services to 30 for an availability search. The deadline per tool is not a detail: without it, a slow integration blocks the conversation, and the person on the other end hears silence.

Real bookings in the salon or clinic system

Six tools over Altegio: the list of services with real prices, specialists, full availability, booking creation, cancellation and editing. Availability does not return only “free/busy”: it returns which specialists perform the requested service and the first free times for each, sorted by the earliest, precisely so the agent can propose a concrete alternative instead of saying “not available”.

The store catalogue, read live

Price and availability are read from the store at the time of the question, not from an outdated copy. The catalogue is loaded paginated, up to 30 pages of 100 products each, kept in a temporary ten-minute cache per site and normalised into a single form, read unchanged by all consumers — including the product carousel in messaging, which needs a numeric price, and the widget on the page, which needs a title.

CRMs, spreadsheets and messaging channels

amoCRM and Bitrix24 with full OAuth, token refresh and status verification. Google Sheets through a dedicated service account, separate from the rest of the credentials, with writing triggered by the agent. Telegram for lead notifications. SMS through Infobip. Plus the chat channel of a local classified ads platform, connected with its own refresh token — the kind of integration that does not exist in any international catalogue and that matters very much locally.

Automations that run in time, with counters

Resuming unanswered conversations, the first message to a new contact, pausing and restarting the agent after hours. Each run increments visible counters: how many runs, how many messages sent, how many skipped because the agent was off, how many because there was no configuration, how many errors. Without them, the only way to find out an automation has died is a customer complaint.

Anti-abuse limits, because a model makes the decision

A tool called by a language model needs boundaries the model cannot exceed. For SMS: in “to company” mode, the recipient comes from configuration, never from the model; in “to client” mode, the number is normalised and validated. On top of that, a daily cap per agent, a one-minute pause to the same number and a message length limit. These are fences written in code, not instructions in the prompt — a prompt can be bypassed, a fence cannot.

Output filters, for data that is not allowed to leave

When an integration returns more than the client should know, we filter on output; we do not hope the agent holds back. A real example: for a transport client, policy forbids the agent from dictating the driver’s phone number, but the API was returning those numbers in the response. We wrote a filter that recursively walks the tool result and removes the driver contact fields, while keeping the dispatch numbers. The filter is applied exactly where needed, not globally, so it does not hide anything else by mistake.

What it looks like

The path, step by step.

01

Inventory: which systems, which gates, which rights

Which systems are involved, what each exposes, who has the right to create credentials and who rotates them. For each one, the basic question: can it be read without authentication? If yes, the integration becomes much cheaper and much easier to repeat for the second client.

02

The connector: declared tools, server keys, time limits

Each action becomes a tool with a name, a description written for the model, typed parameters and its own time limit. The keys remain in the server environment. In the end, the agent does not “know how to do” something vague: it has a finite set of actions, each with its own boundaries.

03

Testing the case that fails, not just the one that works

A connector is tested on the correct request, the incomplete request, the system that responds slowly and the system that does not respond at all. What the agent says when the integration fails is a design decision, not an error the client discovers: we prefer an honest message and a handover to a human, instead of a plausible improvisation.

04

Resistance to the other system’s instability

Retry with increasing pauses, but only for errors that make sense to retry — a rate limit or a server error, not a bad request, which will still be bad the second time. And when the problem is at the other system’s network level, the treatment is different; the example below is exactly such a case.

05

Handover: what changes when the provider changes

We note what breaks if the other system changes its API, which credentials expire and when, what must be renewed manually. An integration without this list is hidden debt: it works perfectly until the day it does not work any more and no one knows why.

One centre. Around it, what enters it — along separate routes.THE CENTRE RELIES ON WHAT SURROUNDS IT
External systems around the conversation: appointments, the shop catalogue, CRM, spreadsheets, SMS and messaging channels — each read on demand, with the keys staying on the server.

The data

What we touch, where it lives, and how long it stays

The questions anyone with a data protection officer would ask — asked here before they do.

Where the credentials are kept
The platform’s provider keys stay in the server environment, not in the database and never in the client page. A client’s own credentials — where the integration requires them — are stored encrypted. The difference matters: a compromised platform key affects everyone, a client credential affects one account; we treat them differently because the risk is different.
What is stored from external systems and what is not
The product catalogue is not copied: it is read on demand and kept in a ten-minute temporary cache, so ten consecutive questions about the same store do not mean ten full reads. Bookings are not duplicated by us — the source of truth remains the salon system. What we keep is the conversation trail and the action result, not a replica of the other system’s database.
What reaches the language model
The result of a tool enters the conversation, so it also enters the model’s context. That is why filtering is done on the result, before it is passed to the model, not in the instructions. The fields the client is not allowed to hear are removed at the source; what has been removed cannot be dictated, no matter how the agent is asked.
Who can link an integration
Connecting an integration is an authenticated operation, tied to the business account, and the resulting tools are attached to a specific agent — not to everyone. An agent has exactly the tools it needs for its role. It is the same logic as with employee access: not every key is handed out just because that is easier.
What remains to be fixed, stated openly
Not all integration modules in our platform are at the same level. The ones listed here are written and run. There are also modules that have been started, of a few dozen lines, which do not do anything useful yet — we do not present them as available and we do not include them in any offer. If you need a system that is at that stage with us, we treat it as a build task, with a compatibility check first, not as a tick-box.

A case

The integration was dropping out intermittently, and it was not on our side

The situation

A CRM connector sometimes worked and sometimes did not, with no obvious pattern at first glance. Requests stayed stuck until they exceeded the server environment’s execution limit, so a timeout appeared in the logs — the sign that wrongly sends you looking for slowness in your own code.

What we built

The cause was in the network, at the other end. The CRM account domain name resolves to several IP addresses, and some of the cluster nodes were unhealthy. A normal HTTP request picks one address and, if that one does not respond, does not try the other addresses returned by DNS — there is no automatic fallback to the next response. The fix was to stop using the default HTTP client for that domain: we resolve the name ourselves, open encrypted connections directly to each address in parallel, with a short timeout on each, and use the first one that responds; if all are cold in one round, it retries.

What came out

The intermittent outages stopped being a lottery. More importantly for the client: the diagnosis became expressible in one sentence — “the provider’s nodes are intermittently unavailable, and we are bypassing them” — instead of “sometimes it does not work”.

What the case does not say

It is a fix that compensates for someone else’s problem, and that must be said. It adds complexity in our code for a defect in the provider’s infrastructure; if they fix their cluster, the complexity remains with us. We document it as such, so it can be removed when it is no longer needed.

Questions

What people ask us before they call

What systems have you actually connected, not theoretically?

The Altegio scheduling system, with six actions called by the agent. amoCRM and Bitrix24, with full OAuth and token refresh. Google Sheets, with a dedicated service account. WooCommerce stores, via the public store API. Telegram, for notifications. Infobip, for SMS. The chat channel of a local advertising platform. Plus Meta and Telegram messaging channels for conversations. For any other system — including store platforms that we have not taken to completion — the honest answer is: on request, after a compatibility check, treated as a build task, not as a setting.

Does my store need to generate API keys for me?

For WooCommerce, no. We use the public store API, which does not require a consumer key — you connect with the site address. It is also safer, not just simpler: with this approach we replaced older tools that kept store keys written in plain text in the database. For other platforms, it depends on what they expose; we check before we promise.

Can the agent make a real booking, not just say it does?

Yes, if the scheduling system allows it. It creates the booking, can cancel and change it, and checks availability first. One detail that is only learnt in practice: in that system, the service and the specialist travel together — if you ask for the free hours of a specialist for a service they do not perform, you get zero results, not an error. That is why the availability tool returns all specialists who perform the service and the first free hours for each, so the agent can propose a concrete alternative.

Where do my keys go?

Platform keys remain in the server environment, never in the database and never in your page. Credentials that are yours are stored encrypted. The rule we apply is: if a key can spend money or can read data for all clients, it has no business being anywhere that code running at the request of a language model can reach.

Can the agent send SMS to whoever it wants?

No, and it is a deliberate restriction. In company notification mode, the recipient comes from configuration — the model cannot choose it. In client mode, the number is normalised and validated. On top of that there is a daily cap per agent, a one-minute pause to the same number and a message length limit. These are guards in code, not instructions in the prompt; a prompt can be bypassed through conversation, a guard cannot.

What happens when the other system goes down or responds slowly?

Each tool has its own execution timeout, so a slow system does not block the conversation. We retry with increasing pauses, but only on errors that are worth retrying — a rate limit or a server error, not a bad request. And the agent’s behaviour on failure is written in the scenario: it says it cannot verify now and hands over the discussion, instead of inventing a plausible answer.

What happens if the provider changes its API?

Something breaks, and that is why we prefer official gateways instead of page scraping. Tools that extract information from a site’s HTML break with any theme change — we deliberately replaced them with a single implementation over the official API, precisely so we do not maintain dozens of fragile variants. When there is no alternative, we say it is a fragile solution and treat it as such.

Can you do automations without an agent, just scheduled rules?

Yes. Resuming conversations left unanswered, the first message to a new contact, stopping and restarting the agent after working hours — these are scheduled tasks that run on their own. Each has its own counters for runs, messages sent, messages skipped and errors, so the question “did it run?” can be answered with a figure, not a guess.

How do you make sure the agent does not say what it should not, from an integration?

We filter the result before it reaches the model, not after. The concrete case we solved: a client’s policy forbade the agent from dictating the driver’s phone number, but the API returned those numbers. We wrote a filter that recursively walks the tool response and removes the driver contact fields, while keeping the dispatch numbers, applied exactly to that tool. What does not reach the model cannot be spoken, no matter how the agent is asked.

What the statements above rest on (18 sources)

18 of them are code and files from our repositories. We don't publish their name or line: together, on a single page, they would describe too precisely how systems that aren't only ours are built. We go through them with you, in the repository, on request — verification stays possible, it just happens in a conversation.

What would you want to work better?

Tell us about your process. Together we decide what is worth building, what we can connect, and how we check the result.

Let's talk