Allegro and your own store: how not to sell the same item twice

The risky minute: when the same item sells in two channels at once

Imagine this: a customer on Allegro buys the last piece of a product, and at the same moment another customer places an order on your website. The system doesn't see that the item was just sold elsewhere. Both transactions go through, and you have to cancel one. The customer who gets told the item is out of stock after paying leaves a negative rating. This isn't theory — the risk appears whenever you sell in more than one channel without automatic inventory sync.

Why does this happen? Because manual inventory updates can't keep up with the pace of sales. Within a minute, several transactions can happen across different platforms. Without a system that sees every sale as an event and reacts immediately, double selling is a matter of time, not luck.

The costs of no synchronization

Each cancelled transaction isn't just a lost sale. It's also time spent handling complaints, a negative Allegro rating, potential loss of search ranking, and damage to future customer trust. Over a month, with dozens of such situations, costs multiply.

One truth about inventory: the central source of stock levels

The solution starts with data architecture. Instead of maintaining separate stock levels in Allegro, your online store, and a spreadsheet, you need a single source of truth. All sales channels should read stock from one place and only report events there — sale, return, correction.

Where can this live? It depends on your infrastructure:

• CRM or ERP system — if you already use one, inventory should be there, and Allegro and the store just read and report changes.
• Database — a simpler solution where one table holds current stock levels, and automation updates platforms.
• Spreadsheet — works for small scale but requires manual handling and doesn't scale to thousands of products.

The key principle: inventory is the source, sales channels are just consumers and event producers. No one manually enters "10 pieces" — every change becomes an event: sale, goods receipt, inventory correction.

What Allegro offers: event log and bulk stock changes

Allegro provides a rich API that lets you not only read and modify offers but also track all changes to them. Through the GET /sale/offer-events endpoint you can retrieve the event history for your offers. The system returns, among others:

• OFFER_STOCK_CHANGED — change in the number of items in an offer, also returned after a purchase. This key event lets you detect when someone bought an item.
• OFFER_PRICE_CHANGED — price change, useful for tracking discounts and promotions.
• OFFER_ENDED — offer ended, for example when a product was manually sold out.

You can filter events by type and date. This allows your system to react to each change in near-real-time, not wait for periodic checks.

Allegro also offers the ability to bulk-change price and quantity across many offers at once. If you have hundreds of products and want to update their stock after an inventory or import from a wholesaler, you don't have to do it one by one.

How it works in practice

You set up automation that at regular intervals (or in near-real-time via webhooks, if Allegro provides them) fetches events of type OFFER_STOCK_CHANGED. When the system detects that stock has decreased, it sends that information to your central inventory source. That in turn updates stock in your online store and other channels.

Allegro orders: when the item is really gone

A stock change in an offer isn't the end of the story. Tracking orders and their statuses is equally important. The GET /order/events endpoint returns all order-related events: purchase, delivery form filled, payment cancelled, and many more.

The most important status is READY_FOR_PROCESSING. It means the customer filled in the delivery option form and finalized the payment (or chose payment on delivery or personal pickup). Only at this point does the order go to fulfillment and can you physically reserve the item. Earlier statuses like FILLED_IN (customer filled in data but hasn't paid yet) shouldn't trigger inventory reservation.

Why READY_FOR_PROCESSING is so critical

Many sellers incorrectly react to the first purchase signal, the BUY event. However, a customer can fill in the form and then cancel payment or simply not complete the transaction. Only READY_FOR_PROCESSING means the transaction is truly confirmed and the item should be removed from inventory.

Also remember that multiple events can appear for a single order. You may receive several READY_FOR_PROCESSING messages if the customer made several purchases. That's why you should always base your logic on the order identifier in the checkoutForm object.

Store side: Processing status as a signal to reduce stock

In WooCommerce and most popular store platforms, the order status "Processing" means payment has been received and inventory has already been reduced — as explained in the WooCommerce documentation. It's a signal for the owner or warehouse to prepare and ship the order.

WooCommerce order statuses work as follows:

• Pending payment — order placed but not yet paid.
• Processing — payment received, stock reduced, order awaiting fulfillment.
• Completed — order fulfilled and shipped.
• Refunded — fully refunded by the administrator.

When an order moves to Processing status, your system should generate a stock reduction event in the central inventory. This event automatically updates stock in Allegro and other channels. This way, every subsequent customer, whether buying through Allegro or your store, sees current stock.

Connecting channels: event is the common language

The principle is simple: regardless of where a sale happens, one inventory reduction event is created. When a customer buys on Allegro, the system records the purchase via OFFER_STOCK_CHANGED and reduces stock in the central inventory. When a customer pays in the online store, the Processing status in WooCommerce generates the same reduction event. Both paths lead to the same inventory management center and update the second channel within seconds.

Update frequency: why once a day isn't enough

Many store owners think: "I'll update stock once a day, in the morning before work." This approach works as long as you have large inventories and infrequent transactions. The problem appears with the last few items of products that are bought often and quickly.

Imagine a product with only five pieces left. Within an hour, six transactions can happen on Allegro and in your store. If you update stock once a day, the last of those transactions will end in cancellation. The customer gets "sorry, product unavailable" after they've already paid.

There are two solutions to this problem:

• Near-real-time updates — every time a new event appears, you immediately update stock in all channels.
• Safety buffer — for popular products you keep extra stock (for example 2-3 pieces) that's not visible in sales. When visible stock reaches zero, the product automatically disappears from sales in all channels.

The buffer is a business decision you make yourself: how many potential customers you're willing to lose due to unavailability versus how much you can lose from cancelled orders.

Event table: from source to destination

The following table shows typical events and information flow between systems:

The table helps show that regardless of event source, the flow is always the same: source generates event, central inventory processes it, all channels receive updated stock.

Do it yourself: manual control and simple protections

If you don't have an integrated system yet, you can implement simple protections that reduce the risk of double sales:

1. Identify low-stock products — once or twice a day check products with 1-3 pieces left. If you see such a product was recently bought, temporarily disable it in one of the channels.
2. Disable duplicate offers — on Allegro list only one offer per product. Don't create many variants with the same item, because it makes tracking stock difficult.
3. Keep a cancellation journal — record every situation where you had to cancel an order due to lack of stock. After a month you'll see the scale of the problem and can better assess whether investing in automation pays off.
4. Set alerts — check whether your store platform lets you enable low-stock notifications, and set the threshold at 1–3 pieces.

These actions won't solve the problem one hundred percent, but they'll give you time and information needed to decide on full automation.

How it looks with a system: automatic synchronization

When you connect sales channels with a central inventory management system, the entire process looks like this:

This means that when a customer buys a product on Allegro, your online store will see reduced stock within seconds and show "last item" or "unavailable". And vice versa: a purchase in the store immediately updates stock on Allegro.

The system doesn't guarantee zero cancellations — borderline situations can still happen, like when a customer buys in the same millisecond in two channels. But it significantly reduces the risk and eliminates the vast majority of such cases.

See how Aura handles Allegro integration with online store and automatic inventory synchronization: Integrations, Online Stores, API, Admin Panels, Dashboards.

Also read about why it makes sense to think about process automation in a company and when ready-made SaaS solutions work better than custom integration: Process automation: what a system can handle, Custom automation vs ready-made SaaS, n8n vs Make: the cost of one scenario, CRM or ERP: which layer comes next, Online orders for restaurants.

Frequently asked questions

Do I have to use Allegro API to synchronize stock?

You don't have to, but without API you're limited to manual methods. You can export stock to a spreadsheet and manually update offers, but that's time-consuming and prone to errors. API lets you automate this process and react to changes in near-real-time.

What if a customer buys on Allegro but doesn't pay?

In that case the order status stays at FILLED_IN and won't move to READY_FOR_PROCESSING. As long as payment isn't finalized, the system shouldn't reserve the item in inventory. That's why it's so important for your logic to be based on READY_FOR_PROCESSING status, not just the fact of purchase.

Can I use the same solution for multiple Allegro accounts?

Yes, provided each account has its own API credentials. Your central system must handle multiple connections and distinguish which account an event comes from. In practice, this means each Allegro account will have its own OAuth token.

What if a product has variants (size, color)?

Variants in Allegro are separate offers with their own stock. You need to map them to corresponding variants in your inventory system. If you sell multi-variant products, make sure your integration handles this logic — otherwise you might sell size M when only L is left in inventory.

How often should I fetch events from Allegro?

Optimally every few minutes, and best in near-real-time via webhooks (if Allegro provides them). With a high number of transactions, once per hour may not be enough for low-stock products. For high-stock products, less frequent checks suffice.

Can I synchronize stock without a programmer?

Partially. Some store platforms offer plugins for Allegro integration that work without writing code. However, advanced scenarios like handling multiple accounts, custom buffer rules, or advanced reporting usually require a custom solution.