Mr. Andrzej runs a company that produces custom-made windows. There are 847 separate offers on Allegro: each is a different variant of dimensions, color, muntins, and glass package. When he changed the price list for 5%, he manually updated 200 offers and forgot about the rest. For two weeks he sold at the old prices. When a customer bought a window in his own store, the last of which he had previously sold via Allegro, he received a return and a negative opinion. This is not a story about indiscipline. This is a story about the lack of a system.
Why Allegro and a customizable product are a difficult marriage
Allegro was designed for products that exist as ready-made SKUs: this specific model, this color, this size. Variants can be grouped in one ad, but the limit is 500 combinations. For a simple product with two parameters, this is enough. For a configurable product, where the customer chooses from several dimensions, several colors, and several additional options, it ends quickly.
The „forced” solution means hundreds of separate advertisements. Each has its own sales history, its own reviews, its own ranking. When you want to change the price list or description, you must do it in each of them separately. When one variant runs out of stock, you need to manually update the stock. And when you add a new variant, you create a new ad from scratch, without history and without position in the search engine.
In addition, there is an Allegro commission, usually 7-9% on the selling price depending on the category. If you use the same price as in your own store, each transaction via Allegro is less profitable by this commission. If you raise prices manually, sooner or later you will forget to update the next time your base price list changes.
One configurator as a hub for all channels
The solution is not to organize Excel better. The solution is one system that knows your product catalog, configuration rules and pricing rules, and then „speaks” to each sales channel separately in its language. Allegro gets what the Allegro API expects. Your own store receives the product in the WooCommerce format. The B2B portal sees a price list with customer discounts. Each channel has an up-to-date version of the same truth.
This architecture solves the problem at its source: instead of synchronizing data between several places, you have one place where the data lives. Synchronization is a derivative, not a goal.
What You Really Need to Sync (More Than You Think)
Most companies that think about synchronization between channels focus on inventory levels. This is important, but it's just the beginning of the list. Here's what really requires consistency:
- Stock levels with real-time updates via webhook, no hourly polling
- Prices per channel with rules including commission, loyalty discounts and promotional campaigns
- Descriptions and photos in a format accepted by each channel (Allegro has its own length limits and photo requirements)
- Shipping time declared in the offer, because Allegro Smart requires meeting timeliness thresholds under pain of losing the badge
- Order statuses and shipment tracking numbers, because Allegro expects updates after each stage
- Returns and complaints related to a specific order configuration
Missing any of these elements leads to problems. Lack of synchronization of shipping times means loss of Allegro Smart and worse positioning of offers. Lack of automatic statuses means manual work and errors. The lack of per-channel rules means margin erosion.
Three problems that grow with each new sales channel
PROBLEM 01
Hundreds of ads instead of one configurator
Allegro allows you to combine variants into one ad, but the limit is 500 combinations. With a product with 4 parameters and several options each, you quickly exceed it. The result: hundreds of separate offers that have to be updated manually every time the price list changes.
Window company: dimensions (8) x color (5) x mullions (2) x glass package (3) = 240. Plus handles and frame colors: 240 x 4 = 960. Allegro limit: 500. Without the system: 2 offers, both out of date.
PROBLEM 02
Overselling because synchronization works once an hour
Customer buys through store at 2:01 p.m. Synchronization with Allegro polls every hour, so Allegro will know about it at 3:00 p.m. At 2:30 p.m. someone buys the same thing on Allegro. You have two orders for one product, a return and a negative review.
Typical scenario when integrating via BaseLinker with the default schedule. Instead of polling, a webhook solves the problem structurally, without having to scratch your head after the fact.
PROBLEM 03
The price on Allegro does not include the 7-9% commission
Allegro charges a commission on the sales price. The company sets the same price as in the store and discovers after a month that all transactions via Allegro were loss-making. Or he raises prices manually and forgets the next time he updates the price list.
The configurator with per-channel rules counts: allegro_price = base_price / (1 - commission). Automatically. Each time the price list changes. Without the „allegro_ceny_v7_FINAL.xlsx” sheet.
How it works from the inside: multichannel configurator architecture
The central element of the system is the product model, which is not tied to any channel. It defines: what parameters the product has, what combinations are possible, what is the base price, what pricing rules apply (discount for quantity, price per B2B customer, margin thresholds). This is one source of truth.
Channel adapters are connected to this model. The Allegro adapter translates the product model into the format required by the Allegro REST API, maps parameters to Allegro attributes, monitors the limit of 500 combinations and divides the product into separate offers if it exceeds it, sets the price including the commission. The own store adapter generates a WooCommerce variable product. The B2B adapter applies a per-customer price list.
Key architectural decision: updating the existing offer on Allegro instead of creating a new one. Allegro counts the history of each offer: sales, reviews, clicks. This history affects your search engine rankings. If you create a new ad every time you change the configurator, you're starting from scratch. The system that updates an existing offer via PATCH /sale/product-offers/id preserves the history. This is the difference between the first and third page of results.
Below you can see what the flow looks like after placing an order via Allegro, step by step. This is the part that is not visible on Allegro, but which determines whether the company operates efficiently or puts out fires.
Allegro API: what is worth knowing before you start
A few technicalities that are not included in the official Allegro documentation and that appear during implementation:
Limit of 5,000 requests per hour per OAuth token. If you have 1,000 products and want to update prices and stock every day, you need to do it in batches and over time. You cannot send 1000 requests at once. The system must have a throttling job queue.
Webhook vs polling is not a matter of preference. Allegro Event Journal delivers events within seconds of purchase. Polling every 5 minutes gives you a 5-minute window for overselling. In a category where the same product can sell multiple times in an hour, 5 minutes is too long.
Allegro Smart: timeliness criteria are measured per offer. If you ship on time in 95% cases globally, but a specific offer has 88%, that offer loses Smart and drops in ranking. The configurator must ensure timeliness per product, not per company.
Photos have a limit of 8 per listing and a minimum resolution requirement. If your catalog has photos per variant, you need to plan how to map them to Allegro. The system must do it automatically, because it is impossible to do it manually with hundreds of offers.
These limitations are not obstacles, they are context. Knowing them before implementation, you can design an architecture that respects them. By ignoring them, you will get a system that „almost works” and generates exceptions once every few days. We wrote about similar dynamics at automation in wholesale trade, where batch sync every 4 hours was described as „real-time” until it caused overselling in the promotion.
When does it make financial sense?
A multichannel configurator is an investment with a specific return structure. It consists of three streams:
Recovered operating time. If managing offers on Allegro, updating price lists and manual synchronization of orders takes a full time, it is PLN 8,000-12,000 per month of labor costs which the system eliminates or reduces by 70-80%. A similar calculation for traders' time is available in CPQ calculator, which shows the actual cost of manual bidding.
Margin recovered. Systematic lowering of the margin due to incorrect prices on Allegro, sales below the minimum due to „forgotten” updates, is a cumulative loss that is measurable considering the scale of several dozen transactions per week. A system that enforces pricing rules consistently has no good days or bad days.
Increased conversions through better availability of offers. Allegro offers with current status, correct price and Allegro Smart convert better than offers with "contact us for availability". Companies that switch from manual management to the system report an increase in sales through Allegro by 20-40% only due to the improvement in the quality of the offers.
How to implement it (and what not to do)
The biggest mistake when implementing a multichannel configurator is trying to map all channels simultaneously from day one. Companies that do this spend 6 months designing and implementing a system that tries to handle every edge case. Meanwhile, they are manually managing four channels and the frustration is growing.
A more effective approach: start with one channel and one product category. Your own store and configurator are usually the first phase. You add Allegro as a second channel when the product model is already stabilized. B2B portals and other marketplaces come later as adaptations of existing logic.
At jsoncrew, we build the configurator according to this model: iteratively, starting with a core that delivers value in 6-8 weeks, and then expanding based on how the system is actually used. If you want to see what it looks like for your product and your channels, describe the situation to us, we will come back with a specific scope proposal and schedule.
In short
The configurator connected to Allegro and other channels is not an integration "just in case". This is a system that eliminates a class of problems: overselling due to unsynchronized stock, margin erosion due to manual pricing, operational time to update hundreds of offers. It requires a well-thought-out architecture, knowledge of Allegro API limitations and an iterative approach to implementation. Companies that do this well gain not only time, but also data, because all orders from all channels flow through one place.
