DEV Community: Luca Siviero

I built an AI business assistant that knows your Webround store.

Luca Siviero — Sun, 06 Sep 2026 11:19:52 +0000

Webround Agent: an AI business assistant that already knows your store

When running an e-commerce store, you always end up asking the same questions: what was my best month, season, or year so far? Which product category is worth investing in more? What's the right strategy for my ad campaigns, and how much budget should I allocate? Which products show up most often in abandoned carts?

These questions seem simple, but the answers behind them are worth a lot to any merchant.

What usually happens

On traditional platforms, you're stuck with preset, limited dashboards that give you a general overview but make it hard to dig into the details. Knowing exactly which category the products abandoned most often in carts belong to is a crucial piece of information, but if the platform doesn't surface it, getting a quick answer is nearly impossible.

That's why business intelligence tools exist: to query that data. But they come with two common problems:

You need to rely on an external service that increases your costs.
You need to export your data in a compatible format.

Whether it's a lack of skills to do a proper export or a desire to avoid paying for external consultants, merchants often end up relying on tools that only see part of the picture, compromising both the quality and quantity of answers they can get.

The problem grows with the store

When an e-commerce store has a short history or only a handful of products, keeping track of everything is relatively simple: you have a precise overview because there isn't much data, and there's no need to dig into details because there's no real pressure to.

But when a store grows into something large, with thousands of products, years of history, hundreds of categories and subcategories, and thousands of euros in ad budget, the need to understand what's happening across the parts of the catalog you don't monitor every day becomes increasingly urgent. At that point, a data analyst stops being a luxury and starts being a necessity.

So the question becomes obvious: what if your data analyst lived inside your e-commerce platform?

Webround Agent

Webround Agent approaches the problem of data analysis differently. It's an AI business assistant that lives directly inside Webround Commerce, with full knowledge of your store's data: catalog, sales, stock, categories, carts and more. It answers questions in plain language, with no technical knowledge required, no configuration needed, no external tools to integrate, and no need to know how to query a database.

It handles any question of a commercial nature: which products are performing best this month, which products have high stock but low sales, how sales are distributed across price ranges and categories, or how results compare to the previous month.

These are the questions every merchant asks constantly, and with Webround there's now a tool that answers them in seconds instead of making you spend hours navigating panels, filters, and exports.

How it works

At the moment, the agent is "just" a data analyst: it runs SQL queries against your data to surface the information it needs, but it doesn't publish anything, doesn't modify data, and doesn't manage your store. It's an assistant, not an automator, for now.

It doesn't have access to your live database or catalog: it works against a remote copy that syncs every hour. This means all data older than one hour is available and is completely read-only. The model never touches Webround's core infrastructure; it only accesses a copy of that specific merchant's data.

This might look like a limitation, but it's actually a strength: this is still an LLM, subject to hallucinations and prompt engineering. Even if it somehow decided to wipe an entire database, it would cause no damage at all, at least until the next sync.

Costs and credits

Webround Agent is built on a latest-generation open-source model with low costs and strong performance.

Usage is billed through a credit system with a small minimum per request, but every account starts with 2,000 free credits, enough for hundreds of questions.

As the system evolves, credits remain the central mechanism for additional usage. At the moment, there's no definitive plan and no way to purchase credits independently, but the price is around €0.50 per 1,000 credits, and consumption depends on the model used. Right now, a heavy request involving dozens of SQL queries costs no more than around thirty credits.

How to access it

Webround Agent is available directly inside Webround Commerce, on any plan, with no additional setup. On the very first request, the system may say there's no data available: don't worry, it's just the initial sync cycle running before your data becomes available for the first time. The conversation is already contextualized on your store, so there's nothing fundamental to explain and no service to connect.

That said, it's good practice to provide some context: for example, explaining how many ad campaigns are currently running, what the goals are for the next measurable period, the metrics you care about most, and some details about suppliers, costs, and margins.

Closing thoughts

Anyone who knows Webround knows I removed the AI builder from the editor: it was a tool with genuine potential that couldn't deliver reliability, and whose use case was easily covered by external tools like ChatGPT or Claude, which we all use anyway.

Webround Agent is something entirely different because it doesn't overlap with the store's logic and doesn't get between the merchant and the platform. It uses data that already exists to answer questions a store owner would ask regardless, just faster and with more precision.

Want to try it? Sign up at webround.com, create a draft, and enable a store: you'll have 2,000 credits ready from day one.

I built an AI website builder for Webround. Then I killed it.

Luca Siviero — Sun, 06 Sep 2026 11:05:51 +0000

I built an AI website builder for Webround. Then I killed it.

Since the early days of building Webround, I always imagined that at some point I would integrate an AI assistant capable of building an entire site from scratch, from a single prompt. Many companies today run marketing specifically around this kind of natively integrated feature, so the desire to introduce something similar in Webround kept growing.

I took advantage of the quieter summer weeks to build an AI builder that, in the end, I didn't release and decided to put on hold.

There was no unsolvable problem behind this decision. But, as I used the builder, some fundamental issues kept surfacing that made me question the entire integration. Webround is a headless platform with public APIs and a full React environment, so anyone can open Claude or ChatGPT, describe what they want, and get working code without me adding anything.

And since the integration was built on the same mainstream LLMs everyone already uses, the question became obvious: why use a proprietary integration that costs more when you can just use your own chat?

How it worked

Webround supports both a visual no-code editor for people who do not write code and a full React environment with Tailwind v4 and NPM support.

The idea behind the builder was simple but ambitious: build an AI service that analyzed the user's request and autonomously decided what to do, how to combine no-code and React, and how to use the wr prop of React components in Webround.

Worried about building an integration with a massive context, I decided to split the planning phase from the execution phase.

A first prompt collected all the data and requirements (copy, structure, color palette, what to change, what to add) and generated a multi-step flow to execute.

A second prompt received each step separately with the operations clearly defined. With strong typing and the right context files, the AI knew exactly what to do to apply each change in the Webround editor.

This approach gave me, in theory, two advantages: the user approves changes before the AI starts working, and each step was isolated and bound to a single prompt at a time, so the AI never ended up with a massive context trying to do everything at once. The results, though, were not what I expected.

No-code generation with AI produces mediocre results

Webround's no-code components are simple, typed, rigid structures. An image component takes a URL, an alt text, and some style properties. In practice, a component is generic React code that knows how to interpret the JSON tied to its configuration.

While it is nothing extremely complex, it still is not free-form HTML generation: the model has to produce output that respects the structure, otherwise every error translates into a missing style or a component that fails to load.

Through the UI this never happens because the user is constrained to editing interfaces that prevent mistakes: you cannot insert a number where a string is expected because the interface simply does not let you do so.

To make the AI understand all of this, you have to inject the entire component type system into the context, otherwise the model would just guess. In most cases the AI did not produce invalid output, and it was not a major problem when it did because I had built a validation system that discarded the output if the model did not respect the expected JSON schema.

The real problem was the visual quality of what got built. It was rarely acceptable because I kept ending up with layouts that made little sense, missed multi-device configurations, and styles that were visually ineffective. It was as if the AI was dropping pieces along the way.

So I started relying more heavily on generating sections entirely in custom React code.

A completely different story with React

When I told the AI to write React code, I realized how capable current models actually are at frontend development. Some of the output genuinely surprised me: beautiful landing pages, balanced colors, fonts, and copy coherent with the site's goal. We all know there is a difference between generating a nice landing page and building a solid frontend, but it was clear that site generation with React code worked well.

It is a task the AI has been trained on extensively, and I got exactly what I expected: correct components, good visual output, correct configurations. I had some occasional issues with unexpected characters breaking JSON formatting in the output validator, but those were identifiable and fixable problems.

At that point I thought the model was limiting the no-code section generation.

The models I used and the cost problem

For this integration I used two models: Gemini 3.5 Flash and Gemini 3.1 Pro Preview. I would have liked to integrate Claude, but I already had a complete Gemini integration ready and decided to reuse it. Honestly, the quality difference was barely noticeable: Gemini 3.5 Flash cost less than Gemini 3.1 Pro and performed just as well.

But, as I kept using the builder, two problems became hard to ignore.

First, output costs were high and I could not simplify them: the planning phase was cheap, but the actual code generation was a real issue. In most cases I was dealing with costs that made the whole thing extremely inefficient. Generating an entire site, which still produced output that required a significant amount of cleanup afterwards, would easily consume one or two euros in Gemini 3.5 Flash credits, depending on the level of detail in the prompt. Factor in the re-iteration a user would need to get exactly what they wanted and those costs could easily double.

Second, no-code generation was unsatisfying and highly inconsistent. Sometimes no-code sections came out well, other times they did not. The more reliable strategy was to rely on React, which is also more flexible and powerful. But then the question becomes obvious: why would anyone use a tool built into Webround, at a premium cost, to generate React code that Claude can generate perfectly well with a bit of Webround context provided?

The further I went, the clearer it became that I was building a system that, using the same models, would cost more and produce results roughly equivalent to what the user can already do on their own. Anyone using a website builder, even if they cannot code, probably already has access to Claude, Gemini, or ChatGPT. If no-code is unreliable and React is the sensible path, why not just give them the right context files and get out of the way?

I was building an AI website builder integrated into Webround that cost more to produce results equal to or worse than what users could get themselves. Not only is that indefensible as a product position, but it also meant maintaining an integration that adds to technical debt without adding real value.

I did not want to walk away empty-handed, though.

What I did instead

Without overthinking it, my questions had clear answers:

Does it cost more? Yes.
Is it better? Not necessarily.
Is it essential? No.
Can it be built later, or differently, from outside? Yes.

So the decision was straightforward: suspend the AI builder, but run one test with Claude.

I created a project, loaded a few context files, gave it clear instructions, and tried building something.

It went exactly as expected. Claude generates clean, good-looking, correct, working React code at a fraction of what it would cost making individual API calls to Gemini, Claude, or OpenAI.

So I wrote three Markdown files designed exactly for this purpose. They contain the information needed to point an AI in the right direction, prevent common mistakes, direct it to the official documentation, and explain the small details of the Webround ecosystem.

webround.md covers the core platform concepts: the difference between draft and store, the runtime architecture, and all the extensibility tools, Checkout Hooks, Edge Hooks, Webhooks and App Extensions, with a clear description of what each one does and when to use it.
webround-apis.md covers the four Webround API systems, Core, Commerce, Catalog and Checkout, with the authentication methods supported by each, the differences between JWT and API key authentication, specific use cases and the differences between the various API systems. It also includes the detail that draftId and storeId are always the same value: obvious to someone who knows the platform, but exactly the kind of thing that trips up a model that does not know the entire platform.
webround-frontend.md covers everything needed to write custom React components: how to structure a component with the wr prop, how to handle internal navigation in the shadow DOM, how to use Tailwind v4 and how to handle some basic functions.

I was starting to understand something simple: you do not need a proprietary AI editor system. You just need the right context to make the AI work correctly.

What I took away from this

The appeal of an AI website builder is real, especially when you see others building them and the marketing around these features keeps getting louder. But when a feature does not add real value beyond convenience at the expense of control and quality, it becomes clear that investing in it, at least right now, does not make sense.

The platform is already open enough that it does not need a proprietary AI intermediary: I was adding non-essential complexity in exchange for a credit system or cost premium that was not always justifiable.

At the moment, I have put development on hold without archiving the idea. There will probably be iterations on this in the coming months with more specific, more targeted details and more granular integrations. Part of me feels this feature is important, but maybe that is just FOMO. Another part knows I would have gained almost nothing from it except a slightly more convenient workflow.

For now, the context files are enough.

Download the context files for Webround

If you are building on Webround with an AI assistant, these files are ready to use:

If you need the full API specs or the complete frontend type definitions, these files are available too. I would not recommend pasting them directly into a chat message since you would burn through an enormous number of tokens. I use them as a knowledge base inside a Claude Project, which retrieves specific information without consuming too many tokens thanks to the tool use and the RAG it builds automatically over project files.

I migrated a 4 years old PrestaShop store. Here's how it went.

Luca Siviero — Tue, 25 Aug 2026 19:44:30 +0000

While looking for new clients for Webround, I reached out to a contact referred to me by word of mouth from a client I had already built a site for.

The situation was interesting: an e-commerce store with 4 years of order history, more than 4,000 product variants, and a solid organic SEO ranking backed by active advertising.

On paper, the store wasn't in bad shape because the site was running and sales were coming in. The problem was everything it couldn't do.

Over those 4 years of selling online, the client had gone through three marketing agencies, each with their own ideas and customizations. The developer who had originally built the store had long since left the project, and nobody inside the company could touch anything. Between plugins that couldn't be updated, a site that was starting to show its age and looking a bit rough around the edges, they were essentially stuck with a 2010-era interface and very little room to extend anything easily.

And the hosting didn't help: a server costing 250 euros a year doing everything at once. Between the site, the database, email, static assets with no CDN, and 20 GB of storage, they were running into unexpected errors and running out of space every three months.

The client didn't know what to do

His request was focused on the site itself, not the system behind it. He knew PrestaShop wasn't the best solution, but a basic interface refresh would have been enough for him.

The problem is that the real issues kept surfacing as we talked. Marketplace sync had broken because of abandoned plugins, changing any business logic was always complicated, analytics were a mess with no clear or organized metrics. In short, it was obvious the problem wasn't just cosmetic.

Customization on PrestaShop is one of those things that takes three times as long as it would on a normal system. Not only were things pretty limited in version 1.7, but the newer versions haven't made great strides either. Updates are tedious, between the unusual templating languages and plugins that inject themselves directly into the platform core, introducing bugs, vulnerabilities, and enormous technical debt.

PrestaShop 1.7 had also accumulated a backlog of missing security patches over time and, with the traffic the site was handling, including solid organic rankings and active Google Ads campaigns, it was impossible to ignore that the infrastructure wasn't holding up its end.

At that point, the reasoning was straightforward: either I upgrade everything, you buy a new theme, rebuy the plugins you already had, and we make some visual adjustments, or you migrate to Webround.

Worth noting: we're now on PrestaShop 9. Version 1.7 dates back to 2021 and isn't directly compatible with a one-click upgrade path. In practice, the migration was going to happen one way or another and, at that point, it made sense to do it on something better.

The server problem

This isn't a minor detail, because the machine running the site was responsible for the database, company email, all the store's images, and every plugin installation.

It sounds extreme, but it's not unusual: most PrestaShop installations are untouchable monoliths. One thing breaks and you risk taking everything down with it. A classic Single Point of Failure.

Webround is serverless for most of its operation. Its infrastructure is built so that no merchant ever has to manage a single machine to operate the core of the platform. On top of having a native CDN, the site itself runs on Cloudflare's edge network, so there's no loading latency for anyone visiting the site from anywhere.

With the current subscription, the client pays 32.50 € per month, but can you put a price on never having to update your e-commerce engine version again with the risk of losing data, losing access to company email, and losing all your site data? With full freedom to manage the site's appearance and functionality through React code and fully-documented APIs?

When the client found out that a complex feature was just an NPM package and a few hundred lines of code away, his eyes went wide.

That's when we decided to migrate to Webround.

The export problem

The first technical obstacle came before I even understood the full picture: I had no SSH access, and no way to enable it from the cPanel I had been given. For a bulk export, direct database access is a huge advantage but it wasn't an option here. So I had to improvise.

The solution was a PHP script uploaded via File Manager, executed once from the browser, and deleted immediately after. The script queries the PrestaShop database directly, collects all relevant tables into a single JSON file, and writes it outside public_html,so it's never publicly accessible. The file is then downloaded via FTP or the file manager interface and converted to a local SQLite database with a Node script.

The actual migration

I had already migrated some WooCommerce and PrestaShop sites before, so the pattern wasn't new to me. Classic ETL flow. But I used this as an opportunity to build something reliable and repeatable for all future PrestaShop migrations. Unfortunately, every PrestaShop installation is unique: different database names, custom table prefixes, and countless small differences that make a one-size-fits-all tool impractical to use directly. For the core data, though, there's always a standard way to extract what you need.

I built a series of scripts whose order is not arbitrary, designed to extract data from PrestaShop and import it into Webround via the APIs, in exactly the order and format that Webround requires.

The full sequence:

Tags and options: PrestaShop attribute groups become tags and options on Webround. Options reuse tags to define how products branch into variants, which PrestaShop calls combinations.
Collections: Categories are migrated level by level in a hierarchical fashion, preserving the structure and the filters that identify which products belong to each collection.
Products: Created in batch with specs, SEO details, shipping dimensions, and category and brand tag assignments.
Variants: Each Webround variant maps to a PrestaShop combination, with a unique slug and SKU, price, and stock level. Worth noting: in PrestaShop, combinations carry a price expressed as a delta from the base product price. In Webround, products don't have a price, only variants do.
Download images: Downloaded from the original server and saved in the environment running the scripts.
Upload images: Images shared across all variants of a product go on the product, while images specific to a single combination go on the variant.
PDFs: Attachments follow the same pattern as variants.
Upload PDFs: Exactly like images.
Tax zones: Each product is linked to the correct Webround tax zone based on its PrestaShop tax rules group.
Shipping: Shipping zones and methods applied to all products.
Customers: Deduplicated by email and imported as standard Webround customers. Login credentials are not transferred.
Promotions: PrestaShop cart rules become Webround promotions with discount type, usage limits, and expiry dates.
Orders: Full order history with line items, status mapping, and promotion usage tracking to prevent customers who have already used single-use promotions from reusing them after the migration.

Every script is idempotent: if a run is interrupted, the next one picks up from the saved state without duplicating anything. The one rule: don't delete the state files.

The 301 redirects

The site still ranks first on several relevant Google search queries today, thanks to a well-maintained, extensive catalog fully synced with Google Merchant Center, which also feeds the Google Shopping campaigns.

The migration scripts automatically generate a redirects.json file mapping every legacy PrestaShop URL to its Webround equivalent: this lets Webround serve the correct response on all previously indexed URLs without losing search ranking.

Important: this is not an optional step when the site has a meaningful Google history, otherwise rankings drop and Google is forced to re-crawl and re-index the entire site from scratch. To protect the SEO of your PrestaShop store after a migration, make sure all products remain reachable at their previous URLs. Returning a permanent 301 redirect to Google ensures a clean migration with no ranking loss.

Customers and passwords

Password migration is always tricky: every system has its own hashing mechanism and authentication strategy. With Webround, authentication is clearly possible, but the process is designed for customers, with an email verification and JWT authentication flow that isn't practical to replicate inside a migration script. The client and I agreed that the cleanest approach was to reset all credentials and add a notice on the login page. It's also a good opportunity to re-engage customers who haven't logged in for a while with the news of the new site, driving reliable traffic from day one.

Orders

Order history and line items are handled directly by the orders migration script. Thanks to Webround's authentication model, if a customer registers after having placed orders as a guest using the same email address, all previously associated orders are linked to the newly authenticated account. This guarantees that a returning customer, after registering, finds their full order history already there when they access their personal area.

The result

The client is entirely satisfied. His words show that the effort put into building a headless, React-based, API-first system pays off: "You're much faster than anyone who has ever touched this site." That might sound like a small thing, but it isn't.

At the same skill level, on PrestaShop, the same work would have taken three times as long, if not more. The project went on to require several additional integrations and business logic customizations, but the speed and freedom of working with Webround quickly turned into new requests for integrations and business flows, adding customer retention mechanisms, promotional advantages, and front-end personalizations that would have taken far longer to build on a legacy on-premise system that would have carried all the usual fragility that comes with it.

Resources

If you're also evaluating a migration from PrestaShop to Webround, or just want to see what I built, all the code is here.

GitHub: https://github.com/WebroundAdmin/wr-prestashop-migration

Syncing Webround and Brevo newsletter subscribers on Cloudflare Workers

Luca Siviero — Wed, 19 Aug 2026 13:03:35 +0000

When a client migrated their store to Webround, they already had an active Brevo account with about 3,000 newsletter contacts built up over multiple years.

However, their original integration had stopped working and had started accumulating a significant discrepancy between the contacts in their e-commerce and those registered on Brevo.

The requirement was straightforward: keep Webround and Brevo in sync without losing the existing list, add all the contacts accumulated over time that hadn't been synced, and make sure that an unsubscribe on either side reflects on the other.

This meant three things: a one-time bulk import of existing Webround subscribers into Brevo, a webhook from Webround to Brevo for new subscribes and unsubscribes, and a webhook from Brevo back to Webround for unsubscribes and contact deletions.

All of it runs on a single Cloudflare Worker.

The bulk import

Before setting up the real-time sync, the existing list needed to be aligned. Webround exposes a paginated /store-customers endpoint with an includeNewsletter=true filter, so the import script fetches all subscribers page by page and pushes them to Brevo in batches of 150, which stays within Brevo's import API limits.

async function fetchAllNewsletterContacts() {
    const contacts = [];
    let page = 1;
    let totalPages = 1;

    while (page <= totalPages) {
        const res = await fetch(
            `${WR_API_URL}/store-customers?page=${page}&limit=100&includeNewsletter=true&includeDeleted=false`,
            { headers: wrHeaders }
        );
        const data = await res.json();
        totalPages = data.pagination.totalPages;

        for (const c of data.data) {
            if (c.email) contacts.push({ email: c.email, displayName: c.displayName });
        }
        page++;
    }

    return contacts;
}

async function importToBrevo(contacts) {
    const BATCH = 150;

    for (let i = 0; i < contacts.length; i += BATCH) {
        const batch = contacts.slice(i, i + BATCH);

        await fetch('https://api.brevo.com/v3/contacts/import', {
            method: 'POST',
            headers: { 'Content-Type': 'application/json', 'api-key': BREVO_API_KEY },
            body: JSON.stringify({
                listIds: [BREVO_LIST_ID],
                updateExistingContacts: true,
                jsonBody: batch.map(c => ({
                    email: c.email,
                    attributes: { FIRSTNAME: c.displayName },
                })),
            }),
        });
    }
}

The updateExistingContacts: true flag handles deduplication natively: if a contact already exists on Brevo, Brevo updates it instead of creating a duplicate. No need to diff the lists manually.

The real-time sync

To avoid the original problem of having two out-of-sync contact lists, webhooks are essential. They let us listen to events instead of running periodic polling against both platforms.

The Worker listens on two endpoints: /webhook/wr for Webround events and /webhook/brevo for Brevo events.

Webround -> Brevo

Webround fires store.customer.newsletter.subscribed and store.customer.newsletter.unsubscribed events. The Worker validates the HMAC signature with a timestamp check to reject stale requests, then calls the Brevo import API to add the contact or the list remove endpoint to remove it. This way, all users who actively subscribe or unsubscribe on the storefront are kept in sync with Brevo.

Webround signs every webhook payload with HMAC SHA-256 using a shared secret, combined with a timestamp to prevent replay attacks:

export async function verifyWebroundWebhook(
    request: Request,
    secret: string
): Promise<{ valid: boolean; body: string }> {
    const signature = request.headers.get("X-Webhook-Signature");
    const timestamp = request.headers.get("X-Webhook-Timestamp");

    const ts = Number(timestamp);
    if (!Number.isFinite(ts) || Math.abs(Date.now() - ts) > 30_000) {
        return { valid: false, body: "" };
    }

    const body = await request.text();
    const key = await crypto.subtle.importKey(
        "raw",
        new TextEncoder().encode(secret),
        { name: "HMAC", hash: "SHA-256" },
        false,
        ["sign"]
    );
    const mac = await crypto.subtle.sign(
        "HMAC",
        key,
        new TextEncoder().encode(`${timestamp}.${body}`)
    );
    const expected = [...new Uint8Array(mac)]
        .map(b => b.toString(16).padStart(2, "0"))
        .join("");

    let diff = 0;
    for (let i = 0; i < expected.length; i++) {
        diff |= expected.charCodeAt(i) ^ signature!.charCodeAt(i);
    }

    return { valid: diff === 0, body };
}

The comparison uses a constant-time loop to avoid timing attacks.

Brevo -> Webround

Brevo doesn't sign payloads with HMAC. Instead, it sends webhooks from a fixed set of IP ranges and supports an optional shared secret header. The Worker validates both:

const BREVO_WEBHOOK_CIDRS = [
    { base: ip4ToInt("1.179.112.0"), mask: 0xFFFFF000 },
    { base: ip4ToInt("172.246.240.0"), mask: 0xFFFFF000 },
];

export function validateBrevoWebhook(request: Request, env: Env): boolean {
    const ip = request.headers.get("CF-Connecting-IP") ?? "";
    const secret = request.headers.get("x-brevo-secret") ?? "";
    return isBrevoIp(ip) && secret === env.BREVO_WEBHOOK_SECRET;
}

When Brevo fires an unsubscribe or contactDeleted event, the Worker looks up the customer on Webround by email and sets their newsletter field to false, so anyone who unsubscribes directly from an email link gets updated on Webround too:

export async function handleBrevoWebhook(
    body: { event?: string; email?: string },
    env: Env
): Promise<Response> {
    const { event, email } = body;
    if (!email) return new Response("Missing email", { status: 400 });

    switch (event) {
        case "unsubscribe":
        case "contactDeleted":
            return setNewsletterOnWebround(email, false, env);
        default:
            return new Response("ok", { status: 200 });
    }
}

The full Worker routing

export default {
    async fetch(request: Request, env: Env): Promise<Response> {
        const url = new URL(request.url);
        const path = url.pathname.includes("/apps/")
            ? "/" + url.pathname.split("/").slice(4).join("/")
            : url.pathname;

        if (path === "/webhook/wr" && request.method === "POST") {
            const { valid, body } = await verifyWebroundWebhook(request, env.WR_WEBHOOK_SECRET);
            if (!valid) return new Response("Unauthorized", { status: 401 });

            const envelope = JSON.parse(body) as {
                eventType: string;
                data: { email: string; displayName?: string };
            };

            if (envelope.eventType === "store.customer.newsletter.subscribed") {
                await addContacts(env, [{ email: envelope.data.email, displayName: envelope.data.displayName ?? envelope.data.email }]);
            }
            if (envelope.eventType === "store.customer.newsletter.unsubscribed") {
                await removeContacts(env, [envelope.data.email]);
            }

            return new Response("ok", { status: 200 });
        }

        if (path === "/webhook/brevo" && request.method === "POST") {
            if (!validateBrevoWebhook(request, env)) {
                return new Response("Unauthorized", { status: 401 });
            }
            const body = await request.json() as { event?: string; email?: string };
            return handleBrevoWebhook(body, env);
        }

        return new Response("Not found", { status: 404 });
    },
};

The path normalization at the top handles Webround App Extensions, which prefix the URL with /apps/{id}/... when the Worker is registered as an extension rather than called directly. In a standard Cloudflare Workers deployment, the URL format is different, but it's handled by the same normalization.

What this covers

A customer subscribes on the storefront: the Worker adds them to the Brevo list in real time. A customer unsubscribes from a Brevo email: the Worker sets their newsletter flag to false on Webround. A contact is deleted on Brevo: same result. The two systems stay consistent without any manual intervention or periodic batch jobs.

The full source is on GitHub: https://github.com/WebroundAdmin/wr-brevo-integration

Built on Webround, an API-first e-commerce platform: webround.com

Why I built a full PayPal checkout on Cloudflare Workers instead of using Stripe

Luca Siviero — Tue, 18 Aug 2026 16:37:15 +0000

When I migrated a 4-year-old e-commerce store to Webround, the client had one non-negotiable requirement: PayPal had to work. Their customers were used to it and removing it would have meant losing conversions from day one.

I assumed it would be straightforward, but it wasn't.

The Stripe Connect dead end

Webround uses Stripe Connect in standard mode: the platform takes a commission, but the merchant keeps their own Stripe account and receives payments directly. It's a clean architecture, keeps Webround out of non-technical matters and causes no issues.

Except with PayPal.

Stripe Connect in standard mode doesn't support PayPal unless you're a merchant of record, meaning you collect the money on behalf of your merchants and redistribute it yourself. It's a completely different business model, implying a whole set of responsibilities. It seemed strange enough that I had to confirm it with Stripe support. After a phone call (yes, Stripe calls you, wherever you are), I got confirmation that what my client needed required a change in Webround's internal responsibility model.

It wasn't a viable path, but fortunately, with Webround on my side, reaching a workaround wasn't difficult.

The PayPal equivalent

The second idea I had was to integrate PayPal's equivalent of Stripe Connect (PayPal Marketplace) at the platform level, so the merchant could connect their own PayPal account natively. In theory it made sense, in practice a bit less: there's an approval process, you need to talk to someone on the sales team, reach a minimum volume threshold, and go through a partner onboarding process that takes weeks. Not viable.

The standalone approach

Third option: build a standalone PayPal checkout flow that bypasses both Stripe and any Connect model entirely. The merchant uses their own PayPal account directly. In practice, a perfectly normal PayPal payment process to orchestrate correctly.

I've been relying on Cloudflare Workers for this kind of thing for a few years now: lightweight, distributed at the edge, perfect for stateless serverless integrations.

I published the full source on GitHub: github.com/WebroundAdmin/wr-paypal-integration. Feel free to use it as a starting point.

How the flow works

The customer clicks PayPal: the Worker validates the cart via the Webround API. It never trusts what the frontend says.
The Worker creates the Webround order (status: created) and the PayPal order.
The PayPal order ID goes back to the frontend, which opens the payment page.
The customer approves and the frontend captures the payment. We don't trust the frontend for the order status change. We use webhooks!
PayPal sends the signed webhook and the Worker verifies the HMAC signature.
The Worker updates the Webround order to paid.
Webround fires the order.paid event to your existing integrations.

Step 1. Validate the cart server-side

Never trust prices submitted by the client, because any request can manipulate them. When the customer initiates checkout, the Worker fetches the real net price, tax rate, and stock availability for every item directly from the Webround API.

const verifiedItems = await Promise.all(
  items.map(async item => {
    const { unitNet, taxRate, packageWeight } = await fetchVariantData( // Method that calls the Webround API
      env,
      item.variantId,
      item.productId,
      item.priceId,
      currencyCode,
      shippingAddress.countryCode
    );
    return { ...item, netAmount: unitNet, taxRate, packageWeight };
  })
);

Step 2. Calculate the total (and the rounding trap)

This is where things get interesting.

Stripe and PayPal calculate order totals differently:

Stripe:

unitGross = round(netAmount × (1 + taxRate/100) × 100) / 100
lineTotal = unitGross × quantity

PayPal:

lineTotal = round(netAmount × quantity × (1 + taxRate/100) × 100) / 100

This is an implementation detail: you could just send the total directly to the Stripe checkout session, but in Webround's native Stripe integration, the payment page shows the full cart breakdown: images, name, unit price, and line total. So Stripe, which works in cents when paying in EUR, needs to know the tax-inclusive total for a single unit before it can show the total across all quantities purchased.

On a single-unit purchase, the difference is zero. On a cart with mixed quantities and decimal prices, the totals diverge.

I discovered this in production. Not because a customer complained... the checkout worked fine from their perspective. I found it because the order export was recalculating totals server-side and the numbers weren't matching what PayPal had actually charged. Silent discrepancies in the accounting export.

Here's an example:

Take a product with a net price of €8.17 and a 22% VAT rate:
Exact gross: 8.17 × 1.22 = €9.9674

PayPal method: multiply first, round after:
9.9674 × 3 = 29.9022 → rounded: €29.90

Stripe method: round first, multiply after:
9.9674 → rounded to 2 decimals: €9.97
9.97 × 3 = €29.91

A difference of €0.01 per order. Silent, systematic, and impossible to catch in happy-path testing.

The fix: align PayPal's calculation to Stripe's method, which is Webround's native integration, so PayPal adapts.

const grandTotal = verifiedItems.reduce((sum, item) => {
  // Stripe-compatible rounding: round unit gross first, then multiply by quantity
  const unitGrossCents = Math.round(item.netAmount * (1 + item.taxRate / 100) * 100);
  return sum + (unitGrossCents / 100) * item.quantity;
}, 0);

Apply the same method when creating order items:

const unitGrossCents = Math.round(item.netAmount * (1 + item.taxRate / 100) * 100);
const unitGross = unitGrossCents / 100;
const unitNet   = item.taxRate > 0 ? unitGross / (1 + item.taxRate / 100) : unitGross;
const unitTax   = unitGross - unitNet;

Pick one method and apply it consistently everywhere. The mismatch is exactly what causes the bug.

Step 3. Create the Webround order and the PayPal order in parallel

const [wrCustomerId, paypalToken] = await Promise.all([
  ensureCustomer(env, customerEmail, billingAddress, customerId),
  getPayPalToken(env),
]);

const [wrOrder, paypalOrder] = await Promise.all([
  createOrder(env, wrCustomerId, customerEmail, currencyCode, grandTotalStr, shippingCostStr, billingAddress, shippingAddress),
  createPayPalOrder(env, paypalToken, grandTotalStr, currencyCode),
]);

We save the mapping between the PayPal order ID and the Webround order ID in a Cloudflare D1 table: we'll need it when the webhook arrives.

await Promise.all([
  createOrderItems(env, wrOrder.id, verifiedItems),
  saveOrderMapping(env, paypalOrder.id, wrOrder.id),
]);

The Worker returns the PayPal order ID to the frontend, which passes it to the PayPal JS SDK to open the payment page.

Step 4. Handle the webhook

After the customer approves and the frontend captures the payment, PayPal sends a signed webhook event. This is the authoritative signal that the payment succeeded. Never trust what happens on the client!

const body  = await request.text();
const token = await getPayPalToken(env);

const valid = await verifyWebhookSignature(env, request, body, token);
if (!valid) return new Response("Unauthorized", { status: 401 });

const event = JSON.parse(body) as { event_type: string; resource: any };

const wrStatus = WEBHOOK_STATUS_MAP[event.event_type];
// PAYMENT.CAPTURE.COMPLETED → "paid"
// PAYMENT.CAPTURE.DENIED    → "failed"
// CHECKOUT.ORDER.CANCELLED  → "canceled"

const mapping = await getOrderMapping(env, paypalOrderId);

await Promise.all([
  updateMappingStatus(env, paypalOrderId, wrStatus),
  updateOrderStatus(env, mapping.wr_order_id, wrStatus),
]);

When the Webround order status becomes paid, Webround fires the order.paid event to all registered webhooks: email confirmations, stock updates, CRM syncs, everything listens there. The PayPal flow plugs into an event system that runs parallel to Stripe's native one, thanks to Webround's architecture and its webhooks.

The frontend component

On the Webround side, this is a custom React component dropped into the built-in IDE, added to the cart page below the native checkout button.

export default function PayPalButton({ wr }: { wr: Wr }) {
    const [message, setMessage] = useState("");
    const currencyCode = wr.customer.cart.items[0]?.currencyCode ?? "EUR";

    const cartItems = wr.customer.cart.items.map((item) => ({
        variantId: item.variantId,
        productId: item.productId,
        priceId: item.priceId,
        quantity: item.quantity,
    }));

    const payload = {
        items: cartItems,
        currencyCode,
        customerEmail: wr.cart.customerEmail,
        customerId: wr.customer.isLoggedIn ? wr.customer.profile?.id : undefined,
        customerJwt: wr.customer.isLoggedIn ? wr.customer.accessToken : undefined,
        billingAddress: wr.cart.selectedBillingAddress,
        shippingAddress: wr.cart.selectedShippingAddress,
    };

    return (
        <PayPalScriptProvider options={{ clientId: PAYPAL_CLIENT_ID, currency: currencyCode }}>
            <PayPalButtons
                createOrder={async () => {
                    const res = await fetch(`${WORKER_URL}/api/orders`, {
                        method: "POST",
                        headers: { "Content-Type": "application/json" },
                        body: JSON.stringify(payload),
                    });
                    const data = await res.json();
                    if (data.id) return data.id;
                    throw new Error(JSON.stringify(data));
                }}
                onApprove={async (data, actions) => {
                    const res = await fetch(`${WORKER_URL}/api/orders/${data.orderID}/capture`, {
                        method: "POST",
                    });
                    const orderData = await res.json();
                    const errorDetail = orderData?.details?.[0];

                    if (errorDetail?.issue === "INSTRUMENT_DECLINED") return actions.restart();
                    if (errorDetail) throw new Error(errorDetail.description);

                    window.location.href = "/checkout/success?clean_cart=true";
                }}
            />
        </PayPalScriptProvider>
    );
}

What this unlocked

The Worker became the foundation for the client's entire payment layer outside Stripe. Clean separation: Stripe has its own isolated microservice, PayPal goes through the Worker. Both converge on Webround's order system and fire the same order.paid event downstream, with the difference that PayPal does everything from the outside via REST API.

The client now runs both payment methods in parallel, with full webhook coverage and correct event tracking on both sides.

The takeaway

If you're building on a platform that uses Stripe Connect in standard mode, don't assume PayPal is just a plugin away. It isn't. But it's also not impossible: it just requires owning the orchestration yourself.

Cloudflare Workers are a good fit for this use case because the logic is stateless, latency matters at checkout, and you get secrets management and D1 out of the box.

Test the rounding before you go live. It won't show up in happy-path testing. Explicitly compare totals between your platform's calculation and PayPal's, with real product data and mixed quantities, before you ship.

The full Worker source, React component, D1 schema, and wrangler config are on GitHub: github.com/WebroundAdmin/wr-paypal-integration

Built on Webround, an API-first e-commerce platform. All order, catalog, and checkout endpoints are publicly documented at docs.webround.com.

Why I built an API-first e-commerce platform

Luca Siviero — Tue, 07 Jul 2026 09:33:37 +0000

Hi! I'm Luca, from Italy, and I've spent the last two years building Webround: an API-first e-commerce platform.

This is something that started as a project of mine with a totally different target: I wanted a quicker way to update my portfolio because I was completing different projects every week. After a lot of headaches, early mornings, late nights and a ton of coffee, I had what I wanted: a way to no-code my portfolio and update it as I wanted.

But while I was completing the project, an idea of making it a headless platform started growing: why would you keep things static and limited to portfolios? AI's already great at doing that!

This idea started getting more serious, to the point that I fired myself from the previous job and after waaay more coffee, late nights, early mornings and a lot of building, breaking, changing, crying, it started to take shape as the product that is today.

While building the platform, I worked as a freelance dev for smaller businesses in town and I had the (very bad) privilege of seeing what they were doing with e-commerce platforms, website management, hosting and more. Nothing ever made any sense because every set-up started from a mix of old technology, forgotten stuff, weird hosting providers, on-premise setups, big ahh monoliths, hacked servers, random throwing errors systems and much more ugly stuff.

I never tried to force Webround into making sense. I've always wanted to be free (in general in my life) and as a developer, the fact that other platforms started feeling as a constraint rather than a tool when things started evolving, was throwing me off.

After working with other popular platforms, I realized that today's landscape is almost never about making things easier, rather about making users dependent on the platform so it's harder to go away.

Why Webround?

Before answering this question, we have to take a look at two examples.

Shopify: this is arguably the best go-to platform for immediate satisfaction. But you're not buying a website, you're buying an ecosystem and all the deriving things from it. Shopify has a great source of strength that is, at the same time, a great source of pain: the app store. Don't get me wrong, extensibility is huge, but usual customers on Shopify are smaller business owners that are chaotic, lack expertise and threat their website like it's a phone with apps. But a website is not a phone and needs real expertise to make it work correctly, so why would anyone keep finding workarounds to make something work with half-solutions to their unique problems? As a developer, working with Shopify never felt great with all the apps and the ecosystem they force. While merchants keep scaling requests to devs or agencies because they keep finding out that they bought a complex (and closed) ecosystem instead of a website.
WooCommerce, Medusa, Vendure, Prestashop: these tools are open-source and carry all the benefits of open-source solutions, but when you start working with these softwares, you enter a maze of weird stuff that you have to actually understand before you get productive at even writing a single line of code. Then you have to manage the infrastructure, without talking of the common issues that these platform have: poorly designed plugins, the "Plugin Hell" situation, non-existent backwards compatibility, monolithical architecture... well, this is not something that looks promising to build onto.

That's where Webround starts making sense.
Let me make you one question: what if you had a managed environment that lets you build natively, in a modern and standardized way, leveraging SDKs and APIs to build virtually anything, while keeping plugins and extensions as separated microservices that work with the core of the platform and not within the core of the platform?

Well, that's exactly what Webround is. A flexible solution to build virtually anything while keeping the developer at the center.

Who's the target user?

In Webround, the more you know, the more you can do. I have always developed the platform with three users in mind.

The no-code user. This person doesn't want or know how to write code and likes to keep things simple, without the risk of running custom implementations. There are limitations, because this user can only work within the boundaries of no-code components, but there is no room to break stuff, while keeping the flexibility to build any layout through a drag & drop editor.
The React developer. This user can speed up website creation by a lot, for a good reason: not only you can write React code inside an integrated IDE, but you can also install any NPM package and use Tailwind. Although, the real advantage lies in the built-in SDK. With a simple wr prop, you can access the underlying app's state and functions to leverage e-commerce functionalities straight from your custom React components. You can access these tools from the browser, without installing anything. Even builds are server-side.
The builder. Their attitude is simple: "Give me a bunch of APIs and I'll figure it out". Webround is an API-first platform that publicly exposes all the endpoints you need, both for the storefront and for managing the e-commerce, the authentication flow of its customers, the catalog system, the cart and the checkout flow. You can use Webround to build headless stores or even as a data layer for your own custom app! It's totally doable; all you need to do is read the docs at docs.webround.com and you're ready to go.

There's more

E-commerce is not just a storefront. Behind every store there are events to handle, data to sync, notifications to send, external systems to connect. The usual answer on other platforms is: open another app, install another plugin and pay another subscription.

With Webround, you have native tools for this.

Webhooks to react to platform events in real time.
Edge Hooks to inject secure runtime data before your pages render.
Checkout Hooks to manipulate the payment flow before it reaches Stripe (Webround partners with Stripe Connect).
App Extensions to build isolated micro-services that plug directly into the platform without touching the core.

This is a way bigger topic that needs to be analyzed in a separated session, so I'll just anticipate that these tools exist for now :)

Final thoughts

I'm not here to sell you anything. I'm looking for users. No-coders who want to explore a modern solution, React developers who want to speed up their work, and hardcore builders who just want a solid set of APIs and the freedom to do whatever they want with them.

If you want to reach out or give me some thoughts about Webround, what you like, what you don't like, what you think is a good or a bad idea, you're absolutely free to reach out!

Just a little anticipation: the website requires you to sign-up with email or google and to verify your account. But, apart from this, every function is basically free to use. Another thing, is that you'd need a subscription to call APIs from the outside (for publicly accessible data). You can either activate a trial, either contact me to request an activation: I'll be more than happy to welcome you here.

Finally, if you want to see my big face, I've created an introduction video to Webround, uploaded on the official channel, where you'll also find a set of tutorials to do the basic stuff with the no-code editor.

I'll leave the links to the official website and documentation, so you can know more about it!

webround.com
docs.webround.com