DEV Community: Samandar Xusenov

Shipping an Instagram DM automation engine without breaking Meta's rules: 6 lessons

Samandar Xusenov — Mon, 28 Sep 2026 09:21:05 +0000

We run Targenix, a free automation platform for businesses in Uzbekistan that sell through Facebook and Instagram ads. This year we replaced our hard-coded "reply to a comment, then ask for a phone number" logic with a real flow engine: 9 triggers (ad comment, DM, story reply, story mention, ad click, ig.me link, Ice Breakers, persistent menu, button), 17 step types, and an AI reply step for everything the flow does not cover.

The engine itself was the easy part. The hard part was the platform rules and the edge cases they create. Here is what we would tell anyone building on the Instagram Messaging API and Messenger Platform.

1. The first reply to a comment is not a normal message

When someone comments under an ad, you are allowed to send them one private reply about that comment. It is addressed to the comment, not to the person. You do not know the customer's messaging ID (PSID/IGSID) until the Send API returns it in its response.

That changes your data model. We had assumed "a conversation starts with a user id", so a run was keyed on the user before anything was sent. For comment flows that is impossible. The fix: send the private reply first, read the recipient id from the response, and only then open the run.

2. There are two windows, and they are not the same window

A private reply to a comment is allowed for 7 days after the comment.
After that, every message is governed by the standard 24-hour window that starts at the customer's last message.

Our first version applied the 24-hour check to the private reply as well. Every comment flow older than a day died on its first step, silently. If you model "can I send now?" as a single function, give it the reason you are sending, not just the timestamp.

3. "Waiting for the customer" must be woken by the customer

A flow often greets the customer and then waits for their answer. We implemented the wait as a state (awaiting first inbound message) and, out of habit, attached it to the scheduler that handles timed waits.

A timer can never know that the customer replied. The result was a flow that said hello once and then stayed silent forever. The inbound webhook has to resume the run. Timers are only for "no answer after N hours".

4. Run the new engine in shadow before it talks to anyone

We did not switch engines at once. For every page in the pilot, the new engine processed each event and recorded what it would have sent, while the old code kept answering customers. We compared the two decisions for 48 hours, fixed the differences, then enabled real sending page by page.

One practical detail: write the shadow decisions to the database, not to logs. Our logs went to stdout, and a deploy recreates the container. The first comparison window disappeared with it.

5. You cannot test comment replies from your own account

A page cannot send a private reply to a person who has a role on that page. Meta returns error 10903 ("This user can't reply to this activity"). The owner commenting on their own ad is the most natural test, and it never works.

Keep a role-less test account for end-to-end checks, and do not read 10903 in production as "the engine is broken".

6. AI is a step, not the whole flow

A pure AI chat drifts. A pure rule-based flow breaks the moment the customer asks something unexpected ("do you deliver to Samarkand?"). What worked for us:

Deterministic steps handle the path we care about: answer the price, show photos, ask for a phone number, create a lead in the CRM or Telegram group.
An AI reply step catches everything else, grounded in the ad text and the facts the business entered (prices, delivery terms, working hours). Then the flow returns to its goal.
Complaints and complex questions go to a human operator instead of looping.

Each public comment reply is generated separately, so a hundred "price?" comments do not get a hundred identical answers. Repeated template text is what both users and platforms read as spam.

What we did not build

No broadcasts, no "we miss you" messages days later, no messages to people who never wrote. Conversations start with the customer and stay inside the window. Keeping messaging permissions is worth more than any single campaign.

If you are solving the same problem for a Facebook or Instagram business, Targenix does all of the above without code and is free (one plan, 0 UZS, AI included): targenix.uz/en. Questions about the Messenger Platform edge cases are welcome in the comments.

How Uzbek businesses turn Instagram lead ads into sales: automating 3 million leads without code

Samandar Xusenov — Sun, 27 Sep 2026 06:04:06 +0000

In Uzbekistan, and across much of Central Asia, paid social is Instagram. When we looked at the leads flowing through Targenix, the platform we build in Tashkent, the pattern was hard to miss: the overwhelming majority come from Instagram placements, not the Facebook feed, and almost every lead leaves a phone number instead of an email.

That one fact shapes everything about how a local business should handle leads. Email-first tools built for the US market quietly fail here: there is no email to nurture, and a lead that waits an hour for a call is usually gone. This article is about the system we built around that reality, and what it looks like after roughly 3 million leads, 1 million+ deliveries and close to 200 active businesses.

The problem: a lead is worth the most in its first minute

A Facebook or Instagram lead form collects a name and a phone number in two taps. Then, by default, the lead sits in Meta's Leads Center until someone downloads a CSV. For a shop selling a product through a call center, or a clinic booking consultations, every minute of that delay costs conversions.

So the first job is boring but decisive: get the lead to the person who will call it, in under a second.

1. Lead routing: one lead, many destinations

Targenix connects to a Facebook Page once and then delivers every new lead from every form on it to wherever the team works:

CRMs: Bitrix24, amoCRM/Kommo, Pipedrive, HubSpot, Salesforce, Zoho
Messengers and sheets: Telegram chats, Google Sheets, Notion, Asana, Todoist
Email and outreach: MailerLite, SendPulse, ActiveCampaign, Kit, Instantly
National CPA and e-commerce platforms used in Uzbekistan — in total 50+ international and national platforms

One lead can go to several destinations at once (say, the CRM and the sales team's Telegram group). Failed deliveries retry automatically, every delivery is logged, and a Test lead button proves a new connection works before real traffic hits it.

2. Automation like ManyChat — for comments and DMs

The second place leads leak is the comment section. People ask "narxi qancha?" ("how much?") under an ad and never get an answer.

Targenix has a visual flow builder for exactly this:

9 triggers — a comment, a DM, a story reply or mention, an ad click, an ig.me / m.me ref link, Ice Breakers, the persistent menu, a button tap
17 step types — reply to the comment publicly, send a DM with buttons or a carousel, ask for a phone number and save it, tag the contact, wait, branch on conditions, hand off to a human, reply with AI, or turn the conversation into a lead that flows into the CRM like any form lead
Ready-made templates such as "answer anyone who asks the price" and "send the catalog carousel"
A test mode on the canvas that lights up the path a message would take — nothing is sent while you experiment

The platform has handled around 100,000 comments and messages this way, and moderation rules can hide comments that leak phone numbers or turn negative.

3. Landing pages — no code, or all the code you want

Not every campaign should use an instant form. For those that send traffic to a page, Targenix builds the page too:

200+ ready-made templates grouped by niche, each in several looks
blocks for offers, countdown timers, reviews, FAQs and order forms — and a custom HTML block when you want full control
Meta Pixel plus server-side Conversions API out of the box (deduplicated), GA4, Yandex Metrica and TikTok Pixel
your own domain with free SSL, publishing, revisions and one-click rollback

Form submissions on a landing page become leads in the same pipeline, so they reach the CRM exactly like Instagram form leads.

4. Keeping ad spend honest

Routing leads is half the job; the other half is not overpaying for them. CPL Guard pauses a campaign automatically when its cost per lead runs above your limit, or when it spends without producing leads. Profit digests arrive in Telegram, and campaigns can even be created and launched from the Telegram bot. Conversions API events are sent back to Meta when a lead turns into a sale, so the ad algorithm learns from real outcomes rather than form fills.

What we'd tell any business running lead ads

Measure time-to-call, not just cost per lead. A cheap lead that waits an hour is expensive.
Design for phone numbers. In markets like Uzbekistan, email nurture is not your funnel; Telegram and the phone are.
Answer the comments. Every unanswered "how much?" is a lead you paid for and lost.
Send real outcomes back to Meta. Conversions API with sale events beats optimizing for form submissions.

Try it

Targenix is completely free — no card, no subscription, no hidden fees — and works in Uzbek, Russian and English. Connect a Facebook Page at targenix.uz and the first lead will be in your CRM or Telegram in about two minutes.

Samandar Xusenov, founder of Targenix

A campaign that pauses itself before you check your phone

Samandar Xusenov — Thu, 03 Sep 2026 14:00:41 +0000

Every performance marketer has woken up to a campaign that spent all night at triple the target cost per lead. The dashboard was right there. Nobody was looking at it at 3am. Here is what we built after the third time that happened, and the two design decisions that made it trustworthy enough to actually leave switched on.

The failure mode nobody budgets for

Cost per lead does not drift gradually most of the time. It steps — a competitor enters the auction, an audience saturates, a creative fatigues — and the step can happen in an hour. A human checking dashboards once a day catches it a day late, which in ad spend terms is not a delay, it is a bill.

The obvious fix is an alert. The better fix is an action, because an alert at 3am gets read at 9am, and the six hours in between are exactly the six hours that mattered.

What "pause the campaign" actually requires

The mechanism: on an hourly sweep, check every active campaign that spent today, compare its cost per lead against a target, and pause the ones that broke it. Two details decide whether marketers actually leave it running.

A minimum-leads gate. One unlucky expensive lead in the first hour of a new campaign should not kill it. The rule only arms once enough leads exist for the cost-per-lead number to mean something. Without this gate, the feature pauses good campaigns on noise, and the first false pause is usually the last time anyone trusts it.

A separate zero-lead spend cap. A campaign that spends money and produces zero leads has an undefined cost per lead — you cannot compare "undefined" against a target, so the rule above can never fire on it. That is precisely the campaign most worth stopping. So a second, independent check exists purely for spend with no leads at all, because the CPL rule structurally cannot catch it.

Miss either of these and the feature is either too trigger-happy to trust or blind to the worst case it exists for.

Scope it per Business Manager, not globally

A target CPL that makes sense for one product line is nonsense for another running in the same ad account. Scoping the rule per Business Manager (or per campaign group) lets the target mean something specific instead of something average.

Tell the human what happened and why

A pause with no explanation reads as a bug. Ours sends a message naming the campaign and the number that triggered it — "CPL hit $X against a target of $Y" or "spent $X with zero leads." That single line is the difference between a marketer trusting the automation and disabling it the first time it surprises them.

What this is not

It is not bid optimisation, and it does not try to fix the campaign — only to stop it from bleeding further while a human decides what changed. Auto-resume is deliberately not part of it: a human should look at why before spend resumes.

The part that made us trust it enough to ship

We run it same-day only — it evaluates today's spend against today's leads, not a rolling average. That is a real limitation, and stating it plainly turned out to matter more than hiding it. A guard rail that oversells its own reliability gets disabled the first time it is wrong in a way nobody warned you about.

This runs in production at Targenix, free lead automation for Facebook and Instagram advertisers, as part of the free plan.

Your cost per lead is falling and your sales are flat. That is the algorithm working.

Samandar Xusenov — Tue, 01 Sep 2026 11:59:31 +0000

A lead campaign gets cheaper every week. Cost per lead down 40%. Sales, unchanged.

The instinct is to look for a bug — bad tracking, a broken CRM sync, an operator not calling back. Usually there is none. The account is working exactly as instructed.

Facebook optimises toward whatever you tell it success looks like. If the only thing you ever report back is "a form was submitted", it will go and find the people most likely to submit forms cheaply. Those people exist in large numbers. Very few of them buy anything.

The signal you are not sending

Ad platforms are guessing most of the time. Cookies are gone or blocked, click ids get dropped, email matching is probabilistic, attribution windows are a polite fiction. Everyone has made peace with that.

Lead Ads are the exception, and it is worth appreciating how unusual it is.

Every submission arrives with a leadgen_id. When you later send a server-side conversion event carrying that same id, the join is deterministic. Not "we think this hashed email is probably that user" — literally the identifier the platform handed you, given back. No cookie, no pixel in a browser, no identity resolution.

Almost nobody running lead ads uses it.

Two events, and only one of them is interesting

Lead received. Fire when the lead lands and passes validation.

Status changed. Fire when the order actually moves — confirmed, delivered, cancelled.

Teams ship the first one, see no change, and conclude the integration does not work. Of course it does not: "a lead arrived" is the one fact the platform already had. You have told it nothing.

The second event is the whole point, and it is inconvenient in a specific way — it arrives days later, because that is how long it takes a human to answer a phone, confirm an order and have a courier deliver it. An integration that only handles same-request events cannot express it. You need somewhere to write the outcome when it eventually shows up, and something that walks those outcomes and sends them.

Make it idempotent twice

Status transitions repeat. Dispatchers re-scan. Order events get written twice by two paths that both thought they were first. Send a conversion twice and you have quietly doubled a number an optimiser is now steering on.

The pattern that has held up:

dedupe_key = f(lead_id, event_type)     -- deterministic, no timestamps

Put a UNIQUE constraint on it in your own table, and hand the same value to the platform as the event id. Now suppression exists in two independent systems: your insert fails on the second attempt, and if one ever slips past, the platform discards it as a duplicate event. Two boring guards beat one clever one.

Deriving the key from anything time-based defeats the entire thing. It has to be a pure function of what happened, not of when you noticed.

The multi-tenant trap

A dataset belongs to one ad account. Send an event about a lead belonging to a different account and you get no error, no warning, no failed response — the data is simply ignored.

This is the worst possible failure mode: everything looks healthy, dashboards show events flowing, and none of them teach anything. If you run this for multiple advertisers, scope every send to the owning account's own dataset with the owner's own credential. A shared or default credential will produce a system that looks fine and does nothing.

What to expect, and how to not misread it

Slowly. The optimiser needs a meaningful number of conversion events to learn from, and that is bounded by real order volume and real fulfilment time — not by your deploy.

Then the shape changes rather than a single number:

Cost per lead goes up. Fewer cheap form-fillers.
Number of leads goes down.
Cost per order goes down, which is the only one that was ever paying anyone.

If cost per lead is still the metric on the wall at that point, this integration will look like it broke the account. Change the metric before you ship the feature, or you will roll back something that was working.

That is the same lesson as everywhere else in this work: the number worth reporting is the one you would defend, not the one that looks best.

We build this at Targenix — free Facebook and Instagram lead automation for Uzbekistan. The Conversions API mechanics are written up in more detail here, the whole platform is mapped here, and the destination list is at targenix.uz/integrations.

The leads that never touch your form: turning ad comments into pipeline

Samandar Xusenov — Tue, 01 Sep 2026 11:53:06 +0000

Everyone building on Facebook Lead Ads instruments the form. The form fires a webhook, the webhook writes a lead, the lead goes to a CRM. Solved problem.

Then you look at the ad itself and find thirty comments saying "narxi qancha?" — how much is it — and eleven people who typed their phone number directly under the post. None of them touched the form. None of them exist in your pipeline. They raised their hand in public and your system did not notice.

We route leads for advertisers in Uzbekistan, mostly physical goods sold on price and speed of callback. Here is what we learned building the comment path.

A comment is not a lead until three things are true

It has to be reachable. Extracting a phone number sounds like a regex problem and mostly is, until you see what people actually type. Numbers with a greeting glued to the front. Numbers with an order note after them. Numbers in Cyrillic-adjacent formatting. Local numbers with and without the country code, sometimes both in one thread. Normalise to something a partner API will accept before it leaves you — a compacted + and digits — and keep the raw text separately, because the raw text is often where the product they want is written.

It has to be attributable. A form lead arrives with a form id and a page id. A comment arrives attached to an ad. If you want cost-per-lead to mean anything afterwards, resolve the comment back to the campaign that paid for it at capture time, not later.

It has to be deduplicated across sources. The same person very often comments and fills the form, ten minutes apart. If your unique constraint is on the form's lead id, the comment version sails straight past it and your operator calls the same person twice. Dedupe on the normalised phone within a window, not only on the platform's identifier.

Replying is where it stops being an engineering problem

The obvious move is an auto-reply. The obvious auto-reply is "Assalomu alaykum! Telefon raqamingizni qoldiring" under all thirty comments, which reads exactly like what it is and performs accordingly.

What worked was narrower: read the product and price out of that specific ad's own caption, answer the actual question, and ask for the number as the last clause rather than the first. One reply per comment, never a second one, and off by default per page so it is a decision rather than a default.

The failure mode to design against is not a bad reply. It is a plausible reply that invents a price. If the caption does not state one, the reply must not either.

The part nobody warns you about

Your comment section is a list of people who publicly announced they want to buy, with contact details attached, on a competitor's screen as easily as yours.

In a market where several sellers run near-identical creative for the same product, that is not hypothetical. So phone-bearing comments can be hidden automatically — visible to you, invisible to everyone else — and abusive ones removed. The lead still reaches you. It just stops being a shared resource.

This is the sort of feature you only think of after an advertiser explains, patiently, why they stopped replying to comments at all.

Permissions, and asking for them at the right time

Comment access needs Facebook permissions that lead retrieval does not. The instinct is to bundle everything into one consent screen at signup. Do not: you will ask for four extra scopes from every user, most of whom will never use the feature, and lower your connect rate for all of them.

Request them in a second, separate flow triggered when someone actually turns the feature on. Facebook shows only the new scopes on re-consent, so the ask stays small. And treat "does this token carry the scopes" as a live fact you check, not a flag you store — users revoke things, and a stored boolean will happily lie to you for weeks.

Was it worth building

Yes, and not for the reason we expected. The volume matters, but the bigger effect is that comment leads arrive earlier in the buying decision than form leads. Someone asking the price in public is often still comparing. Someone filling a form has usually already decided — sometimes on a competitor.

We build this at Targenix — free Facebook and Instagram lead automation for Uzbekistan: form leads, comment leads and your own landing page, routed to 50+ destinations including CRMs, Telegram, Google Sheets and local CPA networks. There is a written map of the whole platform here, the integration list is at targenix.uz/integrations, and it is genuinely free — the reasoning is at targenix.uz/pricing.

Why a 200 OK is not proof of delivery: 4 lessons from routing 100k+ webhook deliveries

Samandar Xusenov — Mon, 31 Aug 2026 06:31:36 +0000

I maintain a service that takes Facebook and Instagram Lead Ads and delivers each new lead, in real time, to wherever the business actually works — a CRM, Telegram, Google Sheets, a CPA network, or a plain webhook. Over 50 destination types, all of them somebody else's API, all of them free to break at 3am.

The naive version of this is one HTTP POST. The real version is about 80% error handling, and almost every line of that 80% exists because something failed silently in production first.

Here are the four lessons that cost me the most.

1. A 200 OK is not proof of delivery

This one still stings.

We had an integration reporting a ~99% success rate while users complained that rows were missing. The destination returned 200 OK every single time. It was also writing empty rows.

The cause was a field mapping that pointed at a form field's label instead of its value. We sent a well-formed request full of empty strings, and the API cheerfully accepted it.

The fix was to stop trusting the status code and start reading the response body. For Google Sheets, the append call echoes back an updatedRange:

"updates": { "updatedRange": "Sheet1!A2:C2", "updatedRows": 1 }

If that range is missing, or the row count is zero, it was not a delivery — no matter what the status line said. Every adapter now has a "what does success actually look like in the body?" check, not just res.ok.

Rule of thumb: for any write API, find the field in the response that proves the write happened, and assert on that.

2. Retries have to survive an outage, not a blip

Most retry examples you find online do 3 attempts with exponential backoff over ~30 seconds. That handles a dropped packet. It does not handle a CRM that is down for six hours, which is completely normal.

We separate failures into two classes:

Validation failures — duplicate, blacklisted, malformed phone number. Retrying is pointless; the payload will never become valid. Fail once, record why, move on.
Infrastructure failures — timeouts, 5xx, DNS, connection reset. These are worth retrying for a long time.

Infra retries now stretch across roughly 26 hours with widening backoff. An overnight outage stops being lost revenue and becomes a delay.

The important part is that this split is decided at the point of failure, by inspecting the error, not by a global retry count. Getting that classification wrong in either direction is expensive: retry a validation error forever and you burn the queue; give up on a 503 after 30 seconds and you lose the lead.

3. Circuit breakers belong per destination, not globally

The first breaker I wrote was global. One dead endpoint slowed everyone down, because the queue kept marching into the same wall.

Breakers are now keyed per destination. But that raised a subtler question: when does a breaker close again?

A breaker that opens because a remote host is unreachable is telling you something about the network. A breaker that opens because the API returned 401 is telling you something about one user's credentials. Those need completely different recovery:

Network-class breakers can heal on their own, and they can also be healed by evidence — if any other tenant successfully reaches that same host, the network is clearly fine, so parked breakers can be moved from OPEN to HALF_OPEN immediately instead of waiting out a timer.
Auth-class failures should never silently retry into a lockout. They should flip the connection's health to "broken" and tell the human, with the specific reason.

Conflating those two was one of our longest-lived bugs. A transient 502 from one provider once flipped a perfectly good connection to error and quietly stopped delivering. Now transient failures leave health unchanged, and only a provider-rejected credential marks a connection broken.

4. Report your success rate honestly

Our dashboard used to show a delivery-rate gauge computed as delivered / total. It looked bad, and unfairly so — because total included duplicates we intentionally blocked, blacklisted numbers, and phone numbers that were never valid.

Those are the system working, not failing.

So validation-class outcomes are now excluded from the denominator. The gauge answers a real question — "of the leads that could be delivered, how many were?" — instead of a meaningless one.

This is worth saying out loud because the temptation runs the other way. It is very easy to build a metric that makes your product look good and tells your user nothing. A number your user cannot act on is decoration.

The boring conclusion

Nothing here is clever. It is all just refusing to believe optimistic signals: the status code, the retry count, the global breaker, the flattering percentage.

If you are building anything that hands data to somebody else's API, I would spend your first week of hardening on lesson 1. It is the one that hides the longest.

I work on Targenix, which does this for Facebook and Instagram lead ads. The list of destinations is here if you are curious what 50+ different failure modes looks like in practice.

Routing Facebook & Instagram leads to any CRM in real time (and why we made it free)

Samandar Xusenov — Sun, 30 Aug 2026 11:23:31 +0000

If you run Facebook or Instagram Lead Ads, you know the gap: a customer fills in the form, and then the lead just sits inside Meta's Ads Manager. By the time someone exports the CSV, it's hours later and the lead is cold.

We built Targenix to close that gap for businesses in Uzbekistan — deliver every Lead Ads lead to wherever the team actually works, in real time. This post is a quick tour of how it works, and why we decided to make lead forwarding completely free.

The problem: leads that arrive too late

Meta Lead Ads are excellent at collecting leads and poor at delivering them. The native options are a manual CSV export or a raw webhook you have to build and babysit yourself. Small teams and solo marketers don't have an engineer on call, so leads pile up and conversion drops the longer nobody calls back.

The pipeline

The core is boring on purpose — boring is reliable:

Webhook ingestion. Subscribe to Meta's leadgen webhook. Every submitted form fires an event with a leadgen_id; we fetch the full field set from the Graph API.
A queue, not a cron. Each lead becomes a job. That gives back-pressure, ordering, and somewhere safe to retry — instead of a giant loop that dies halfway.
Adapters per destination. One small adapter per target: CRMs (Bitrix24, Kommo, amoCRM, Salesforce, Notion, Monday), Telegram, Google Sheets, and local CPA networks. Adding a destination means writing one adapter, not touching the core.
Idempotency + retries. Dedupe by leadgen_id so a webhook re-delivery never double-sends. Failed deliveries retry with exponential backoff and a circuit breaker per connection, so one flaky CRM doesn't stall the rest.
Conversions API. The same lead is sent back to Meta via the Conversions API (keyed by leadgen_id) so the ad algorithm optimizes on real conversions, not just form-fills.

A few things we learned the hard way:

Validate before you count. Duplicates, blacklisted numbers and malformed phones should never inflate your "delivered" rate. We separate real delivery failures from validation drops.
Health has to be truthful. A transient 502 from a messenger API should not flip a connection to a permanent error state and silently drop leads. Transient == unchanged; only a provider rejecting credentials means "reconnect".
Attribution is a denominator problem. Spend ÷ captured leads and spend ÷ delivered leads are different numbers, and mixing them makes your cost-per-lead lie.

Why free?

The honest answer: forwarding a lead costs us very little, and charging per lead punishes exactly the small businesses we want using it. So lead routing and the core features stay free — no subscription, no card. We'd rather win the market on being genuinely useful and monetize higher up the stack later.

Try it

If you're running Lead Ads and tired of exporting CSVs, you can connect a page and pick a destination in a few minutes: targenix.uz. The full list of destinations lives at targenix.uz/integrations, and if you're curious whether it's really free, that's spelled out at targenix.uz/pricing.

Happy to answer questions about the pipeline in the comments.