Druge platforme in integracije spletnih trgovin

Kako uporabljati webhooke v avtomatizaciji marketinga spletne trgovine

Posted on July 18, 2026 by

Webhook je sporočilo, ki ga vaša trgovina samodejno pošlje v trenutku, ko se nekaj zgodi — oddano je naročilo, obnovi se naročnina, izvede se vračilo kupnine — na URL, ki ga izberete. V marketinški avtomatizaciji ta URL usmerite na svoje e-poštno/SMS orodje (ali na majhno skripto vmes) in dogodek postane sprožilec: označi kontakt, zaženi tok, posodobi polje, pošlji SMS. Webhooki so način, kako povežete vedenje, ki ga nobena izvorna integracija ali predloga Zapierja ne pokriva, običajno ceneje in hitreje kot povezovalnik, ko obseg naraste. Ta vodnik pokriva, kdaj jih uporabiti, katere dogodke je vredno poslušati, kako enega nastaviti, ne da bi kaj pokvarili, in načine odpovedi, ki ljudi zalotijo.

Če se še niste odločili, ali to pot sploh potrebujete, najprej preberite kako izbrati med izvorno integracijo in Zapierjem — webhooki so odgovor na določeno vrzel, ne privzeta izbira za vsako trgovino.

Kaj webhook pravzaprav je, v jeziku trgovine

Predstavljajte si razliko med tem, da vsako uro pokličete dobavitelja in vprašate “kakšna nova naročila?”, in tem, da vas dobavitelj pokliče v sekundi, ko naročilo prispe. Prvo je poizvedovanje: nenehno preverjanje, večinoma za prazen nič. Drugo je webhook: dogodek se sam potisne k vam, takoj in samo takrat, ko se zgodi.

Vaša trgovina izstreli majhen paket podatkov (običajno JSON) na URL. Ta paket pove, kaj se je zgodilo, in nosi podrobnosti — ID naročila, e-poštni naslov kupca, postavke, vsoto. Nekaj na drugem koncu ga sprejme in opravi delo. Brez urnega preverjanja, brez zamude, brez zapravljenih zahtevkov.

Ta neposrednost je celoten smisel za marketing. Tok za obnovo košarice ali potrditev naročila, ki se sproži v trenutku, ko se dogodek zgodi, prekaša tistega, ki čaka na naslednji cikel sinhronizacije, in pri časovno občutljivih sporočilih je vrzel enaka denarju.

Kdaj je webhook pravo orodje

Webhooki so smiselni v treh situacijah in te se prekrivajo s primerom za Zapier — a mu niso enake.

Izvorne integracije ni, obseg pa je velik. Zapier bi deloval, a pri tisočih naročil na mesec njegovo zaračunavanje po opravilu postane drago. Webhook naravnost v API vašega e-poštnega orodja nima stroška na dogodek poleg vaših obstoječih paketov.
Potrebujete dogodek, ki ga izvorni povezovalnik ignorira. Vaša platforma sinhronizira naročila, ne pa recimo “naročnina ustavljena” ali “garancija registrirana”. Če lahko vaša trgovina za to izstreli webhook, lahko na to reagirate.
Ste na prilagojeni ali headless postavitvi. Pogosto ni povezovalnika za kupiti, zato dogodke tako ali tako pošiljate sami. Za podrobnosti glede povezave trgovina-platforma glejte kako povezati prilagojeno spletno trgovino z Omnisendom in kako uporabljati Omnisend s trgovino, ki temelji na API-ju.

Če vas ne opisuje nobena od teh, je izvorna integracija manj dela in bi se morali ustaviti tukaj. Webhooki zamenjajo trud pri nastavitvi in nekaj tehnične samozavesti za nadzor in ceno — poštena zamenjava le takrat, ko zares potrebujete tisto, kar dajejo.

Dogodki, ki jih je vredno poslušati

Webhooka ne želite za vse. Šum ustvarja delo. Izberite dogodke, ki se preslikajo v marketinško odločitev.

Naročilo ustvarjeno / plačano — hrbtenica. Nahrani tokove za potrditev naročila, navzkrižno prodajo in dopolnjevanje ter posodobi polja o življenjski vrednosti.
Naročilo pripravljeno / odposlano — poganja obvestila o pošiljanju in dostavi, sporočila z najvišjo stopnjo odpiranja, kar jih večina trgovin pošlje.
Vračilo kupnine / vrnitev ustvarjeno — pri teh kupcih skoraj zagotovo želite zavreti tok z zahtevo za oceno ali navzkrižno prodajo. Poslati e-pošto “kako vam je bilo všeč?” nekomu, ki je izdelek pravkar vrnil, je prav takšna napaka, ki se ji webhooki omogočijo izogniti.
Naročnina obnovljena / ustavljena / preklicana — pri trgovinah s potrošnim blagom in naročninami te poganjajo celoten ritem zadrževanja.
Kupec ustvarjen / posodobljen — vzdržuje polja o kontaktih in soglasje usklajena.

Opazite, da polovica teh obstaja zato, da ustavi napačno sporočilo, ne da ga pošlje. Zaviranje je podcenjena polovica avtomatizacije, podatki o dogodkih pa so način, kako to dobro počnete.

Kako enega nastaviti, ne da bi pokvarili svoje tokove

Mehanika se razlikuje od platforme do platforme, a oblika je povsod enaka.

Poiščite, kje vaša trgovina izstreljuje webhooke. Večina platform ima nastavitveno območje za obvestila ali webhooke (Shopify, WooCommerce prek vtičnika ali jedra, BigCommerce in drugi). Izberete dogodek in prilepite ciljni URL.
Določite cilj. Dve možnosti. Usmerite neposredno na točko API vašega e-poštnega orodja za dogodke ali prilagojene dogodke, če ta sprejema vhodne dogodke. Ali usmerite na tanek vmesni sloj — majhno strežniško funkcijo ali orodje brez kode — ki podatke preoblikuje in posreduje naprej. Neposredno je enostavneje; vmesni sloj vam kupi filtriranje in preoblikovanje.
Preslikajte podatkovni paket v polja, ki jih vaše e-poštno orodje razume. Webhook pošlje imena polj trgovine; vaše e-poštno orodje pričakuje svoja lastna. Ta preslikava je mesto, kjer gredo stvari tiho narobe — nepreslikano polje preprosto prispe prazno, e-pošta, ki je od njega odvisna, pa se izriše prazna.
Preizkusite z resničnim dogodkom, preden mu zaupate. Oddajte pravo testno naročilo. Opazujte, kako se kontakt in dogodek pojavita na drugi strani. Preverite, ali se je res napolnilo vsako polje, ki ga nameravate uporabiti v sporočilu.
Šele nato, in ne prej, vklopite tok, ki dogodek porabi.

Ta vrstni red je pomemben. Vklopite tok, preden ste potrdili, da podatki pravilno prispejo, in bodo pokvarjene e-pošte prvi dan romale k resničnim kupcem.

Načini odpovedi, pred katerimi vas nihče ne posvari

Webhooki so preprosti, dokler niso. Štiri stvari ljudi ugriznejo, poznavanje teh vnaprej pa prihrani dneve.

Ponovni poskusi in podvojitve. Če je vaša končna točka počasna ali vrne napako, večina platform ponovi poskus — kar pomeni, da lahko isti dogodek prispe dvakrat ali petkrat. Brez zaščite kupec dobi oznako ali e-pošto večkrat. To rešite tako, da unikatni ID vsakega dogodka obravnavate kot ključ in ponovitve ignorirate (temu se reče idempotentnost). Če dogodke povezujete naravnost v tok, vsaj potrdite, da se tok ob podvojitvi ne bo znova sprožil.

Tihe napake. Izvorna integracija, ki se pokvari, pogosto pokaže napako v nadzorni plošči. Webhook, ki neha delovati, preprosto … utihne. Nobeno naročilo se ne sinhronizira, noben alarm ne zazvoni, vi pa opazite teden dni pozneje, ko nekdo vpraša, zakaj so potrditve prenehale prihajati. Vgradite preverjanje: ali se število prispelih dogodkov naročil približno ujema z naročili, ki ste jih danes dejansko sprejeli?

Vrstni red prispetja. Dogodki ne prispejo vedno v vrstnem redu, v katerem so se zgodili. Webhook “pripravljeno” lahko ob obremenitvi prispe pred webhookom “ustvarjeno”. Ne gradite logike, ki predpostavlja strogo zaporedje, razen če preverjate časovne žige.

Manjkajoči podatki. Webhook se sproži, a polje, ki ste ga potrebovali, je prazno ali čudno oblikovano, zato se personalizacija naprej po toku pokvari. Če se vaši bloki izdelkov ali podrobnosti naročila v e-pošti pojavijo prazni, začnite pri kako odpraviti manjkajoče podatke o naročilu v e-poštnih platformah — večina tega izvira iz podatkovnega paketa ali preslikave polj.

Konkreten primer: zaviranje napačne prošnje za oceno

Tukaj je resničen vzorec iz mojih lastnih trgovin, opisan tako, da lahko logiko prekopirate.

Težava: naš tok po nakupu je poslal prošnjo za oceno 14 dni po dostavi. Dobra zamisel, le da so bili kupci, ki so izdelek vrnili, naprošeni, naj ocenijo nekaj, kar so poslali nazaj. Nerodno in izpadli smo, kot da ne pazimo.

Rešitev je uporabila webhook refund/return created. Ko se je sprožil, je kontakt označil z returned-recent. Tok za ocene je dobil en dodaten pogoj: preskoči vsakogar s to oznako. Nobena izvorna integracija ni ponujala tega specifičnega zaviranja; webhook je vzel eno uro za nastavitev in nerodne e-pošte so prenehale. (Ponazoritev pristopa — natančna imena dogodkov in nastavitev vaše platforme bodo drugačna.)

To je vsakdanja vrednost webhookov. Ne velika nova avtomatizacija — majhen, natančen košček vedenja, ki obstoječi tok naredi pametnejši.

Kako izmeriti, ali deluje

Stopnja ujemanja dogodkov. Prejeti dogodki proti dogodkom, ki bi se morali sprožiti (sprejeta naročila, izdana vračila kupnine). Vrzel pomeni, da webhook podatke izpušča ali tiho odpoveduje.
Zakasnitev. Čas od dogodka v trgovini do prispetja dejanja. Webhooki naj bi bili skoraj takojšnji; sekunde, ne minute.
Stopnja podvojenih dejanj. Kako pogosto je isti kupec dvakrat dobil isto oznako ali sporočilo. Nad ničlo pomeni, da vaše razdvajanje ne drži.
Uspešnost toka naprej. Pravi preizkus: ali je tok, ki ga webhook nahrani, dejansko deloval — obnovljene košarice, oddane ocene, manj pošiljanj napačnemu občinstvu?

Kje se umešča Omnisend

Omnisend uporabljam v vseh svojih trgovinah in pri delu z webhooki je pomemben del njegova podpora za prilagojene dogodke in API: nanj lahko izstrelite dogodek trgovine in sprožite tok, nastavite polje ali dodate oznako, kar je točno tisto, kar ti primeri uporabe potrebujejo. Za pogoste platforme webhookov sploh ne boste potrebovali — izvorna integracija že prenaša naročila, košarice in dogodke brskanja. Webhooki pridejo v poštev za dogodke zunaj tega standardnega nabora, za primere zaviranja ob vrnitvi in statusa naročnine od zgoraj.

Omnisend je partner Shopimationa v pridruženem programu; priporočam ga iz resnične rabe. Poštena omejitev: pošiljanje dogodkov v katero koli orodje je lahka polovica. Poskrbeti, da prispejo zanesljivo, niso podvojeni in nosijo čiste podatke, je delo in tega dela vam nobena platforma ne opravi. Če vaša trgovina teče na platformi brez izvornega povezovalnika, povezovanje Shopwara z Omnisendom brez izvorne integracije predela nastavitev v slogu webhookov od začetka do konca.

Vaš naslednji korak

Izberite en dogodek, na katerega trenutno ne morete reagirati — vrnitev, ustavitev naročnine, registracijo garancije — in ta teden zanj napeljite en sam webhook. Preizkusite ga z resničnim dogodkom, potrdite, da podatki prispejo, nato dodajte tisti en pogoj toka, ki ga omogoča. Ena natančna avtomatizacija prekaša ducat napol delujočih. Ko boste pripravljeni pregledati celoten sklad za takšne vrzeli, izvedite pregled integracij za marketing spletne trgovine.

Other Ecommerce Platforms and Integrations

How to Use Webhooks in Ecommerce Marketing Automation

Posted on July 18, 2026 by

A webhook is a message your store sends automatically the moment something happens — an order is placed, a subscription renews, a refund goes through — to a URL you choose. In marketing automation, you point that URL at your email/SMS tool (or a small script in between), and the event becomes a trigger: tag the contact, start a flow, update a field, fire an SMS. Webhooks are how you wire up behavior that no native integration or Zapier template covers, usually cheaper and faster than a connector once volume climbs. This guide covers when to use them, the events worth listening for, how to set one up without breaking things, and the failure modes that catch people out.

If you haven’t yet decided whether you even need this route, read how to choose between native integrations and Zapier first — webhooks are the answer to a specific gap, not the default for every store.

What a webhook actually is, in store terms

Think of the difference between calling a supplier every hour to ask “any new orders?” and the supplier calling you the second an order lands. The first is polling: constant checking, mostly for nothing. The second is a webhook: the event pushes itself to you, instantly, only when it happens.

Your store fires a small packet of data (usually JSON) at a URL. That packet says what happened and carries the details — order ID, customer email, line items, total. Something at the other end receives it and does the work. No hourly checking, no delay, no wasted requests.

That immediacy is the whole point for marketing. A cart-recovery or order-confirmation flow that fires the instant the event happens beats one that waits for the next sync cycle, and for time-sensitive messages the gap is money.

When a webhook is the right tool

Webhooks make sense in three situations, and they overlap with — but aren’t identical to — the case for Zapier.

No native integration exists, and volume is high. Zapier would work, but at thousands of orders a month its per-task pricing gets expensive. A webhook straight into your email tool’s API has no per-event cost beyond your existing plans.
You need an event a native connector ignores. Your platform syncs orders but not, say, “subscription paused” or “warranty registered.” If your store can emit a webhook for it, you can act on it.
You’re on a custom or headless build. There’s often no connector to buy, so you’re sending events yourself anyway. See how to connect a custom ecommerce store to Omnisend and how to use Omnisend with an API-based store for the store-to-platform specifics.

If none of those describe you, a native integration is less work and you should stop here. Webhooks trade setup effort and a little technical comfort for control and cost — a fair trade only when you actually need what they give.

The events worth listening for

You don’t want a webhook for everything. Noise creates work. Pick the events that map to a marketing decision.

Order created / paid — the backbone. Feeds order-confirmation, cross-sell, and replenishment flows, and updates lifetime-value fields.
Order fulfilled / shipped — powers shipping and delivery updates, the highest-open messages most stores send.
Refund / return created — you almost certainly want to suppress a review-request or cross-sell flow for these customers. Firing a “how did you like it?” email at someone who just returned the item is the kind of mistake webhooks let you avoid.
Subscription renewed / paused / cancelled — for consumable and subscription stores, these drive the entire retention cadence.
Customer created / updated — keeps contact fields and consent in sync.

Notice that half of these exist to stop the wrong message, not send one. Suppression is the underrated half of automation, and event data is how you do it well.

Setting one up without breaking your flows

The mechanics vary by platform, but the shape is the same everywhere.

Find where your store emits webhooks. Most platforms have a Notifications or Webhooks settings area (Shopify, WooCommerce via a plugin or core, BigCommerce, and others). You choose an event and paste in a destination URL.
Decide the destination. Two options. Point directly at your email tool’s event or custom-event API endpoint if it accepts inbound events. Or point at a thin middle layer — a small serverless function, or a no-code tool — that reshapes the data and forwards it. Direct is simpler; a middle layer buys you filtering and transformation.
Map the payload to fields your email tool understands. The webhook sends the store’s field names; your email tool expects its own. This mapping is where things quietly go wrong — an unmapped field just arrives empty, and the email that depends on it renders blank.
Test with a real event before trusting it. Place a genuine test order. Watch the contact and event appear on the other side. Check every field you plan to use in a message actually populated.
Then, and only then, switch on the flow that consumes the event.

That order matters. Turn the flow on before you’ve confirmed the data lands correctly and you’ll send broken emails to real customers on day one.

The failure modes nobody warns you about

Webhooks are simple until they aren’t. Four things bite people, and knowing them up front saves days.

Retries and duplicates. If your endpoint is slow or returns an error, most platforms retry — which means the same event can arrive twice or five times. Without protection, a customer gets tagged, or emailed, more than once. Handle this by treating each event’s unique ID as a key and ignoring repeats (this is called idempotency). If you’re wiring events straight into a flow, at least confirm the flow won’t re-trigger on a duplicate.

Silent failures. A native integration that breaks often shows an error in a dashboard. A webhook that stops firing just… goes quiet. No orders sync, no alarm rings, and you notice a week later when someone asks why confirmations stopped. Build a check: does the number of order events arriving roughly match the orders you actually took today?

Order-of-arrival. Events don’t always arrive in the order they happened. A “fulfilled” webhook can land before the “created” one under load. Don’t build logic that assumes strict sequence unless you’re checking timestamps.

Missing data. The webhook fires, but a field you needed is empty or formatted oddly, so downstream personalization breaks. If your product blocks or order details show up blank in the email, start with how to troubleshoot missing order data in email platforms — most of it traces back to the payload or the field mapping.

A concrete example: suppressing the wrong review request

Here’s a real pattern from my own stores, described so you can copy the logic.

The problem: our post-purchase flow sent a review request 14 days after delivery. Good idea, except customers who’d returned the product were getting asked to review something they’d sent back. Awkward, and it made us look like we weren’t paying attention.

The fix used a refund/return created webhook. When it fired, it tagged the contact returned-recent. The review flow had one added condition: skip anyone with that tag. No native integration offered that specific suppression; the webhook took an hour to set up and the awkward emails stopped. (Illustrative of the approach — your platform’s exact event names and setup will differ.)

That’s the everyday value of webhooks. Not a grand new automation — a small, precise piece of behavior that makes an existing flow smarter.

How to measure whether it’s working

Event match rate. Events received vs. events that should have fired (orders taken, refunds issued). A gap means the webhook is dropping or failing silently.
Latency. Time from the store event to the action landing. Webhooks should be near-instant; seconds, not minutes.
Duplicate action rate. How often the same customer got the same tag or message twice. Above zero means your dedupe isn’t holding.
Downstream flow performance. The real test: did the flow the webhook feeds actually perform — recovered carts, review submissions, fewer wrong-audience sends?

Where Omnisend fits

I use Omnisend across my stores, and for webhook work the part that matters is its custom-events and API support: you can fire a store event at it and trigger a flow, set a field, or add a tag, which is exactly what these use cases need. For the common platforms you won’t need webhooks at all — the native integration already carries orders, carts, and browse events. Webhooks come in for the events outside that standard set, the return-suppression and subscription-status cases above.

Omnisend is an affiliate partner of Shopimation; I recommend it from real use. Honest caveat: sending events into any tool is the easy half. Making sure they arrive reliably, aren’t duplicated, and carry clean data is the work, and no platform does that part for you. If your store runs on a platform without a native connector, connecting Shopware to Omnisend without a native integration walks through a webhook-style setup end to end.

Your next step

Pick one event you can’t currently act on — a return, a subscription pause, a warranty registration — and wire a single webhook for it this week. Test it with a real event, confirm the data lands, then add the one flow condition it enables. One precise automation beats a dozen half-working ones. When you’re ready to audit the whole stack for gaps like this, run auditing ecommerce marketing integrations.