Forem: Nventory

I Just Launched a Free WooCommerce Multi-Channel Inventory Plugin on WordPress.org

Nventory — Mon, 04 May 2026 10:51:39 +0000

After months of building, testing, and breaking things on staging stores, Nventory is officially live on the WordPress.org plugin directory.
🔗 Install it here
🌐 Project site: nventory.io
This post is the honest launch story, what the plugin does, why I built it, what it doesn't do (yet) and what I'm hoping to learn from the dev.to community.

The Problem I Built It For
If you've ever run a WooCommerce store that sells on more than one channel — Amazon, eBay, Walmart, Etsy, TikTok Shop, Shopify, anywhere — you already know the pain.

You list the same SKU in five places. You sell one unit on Amazon at 11:47 AM. Fourteen minutes later, your sync plugin finally polls all the channels and updates them. By then, two more customers have bought that "available" unit on eBay and Walmart. You issue refunds, write apology emails, and get an Amazon account health warning for your trouble.
The existing solutions in this space are mostly:

Plugin stacks — install one plugin per channel, watch them fight each other over the WooCommerce stock table, end up with silent data corruption Polling-based sync tools work fine in demos, fail under real volume because 5–15 minute intervals aren't fast enough
Enterprise platforms overpowered and overpriced for stores doing under $1M ARR

I wanted something built specifically for the WooCommerce-plus-marketplaces use case, with webhook-driven sync, native channel integrations and a free tier that's actually usable, not a marketing funnel.
So I built Nventory.

What the Plugin Actually Does
The free WordPress.org plugin connects your WooCommerce store to a webhook-driven sync platform that handles:

Real-time stock sync across Amazon, eBay, Walmart, TikTok Shop, Etsy, Shopify and 30+ other channels
Variation-level tracking — every size/color/configuration gets its own SKU and its own sync rules
Bidirectional updates — sales on any channel reduce stock everywhere else in under 5 seconds
Order import — orders from every connected channel land in one operational view
Buffer stock configuration — reserve units per SKU as a safety net against sync delays
Audit logging - every webhook event, every stock change, fully traceable

What separates it architecturally from older plugins is that the heavy lifting (sync logic, retry handling, channel API coordination) runs on dedicated infrastructure, not on your WordPress hosting account. Your WooCommerce admin stays fast, even at 5,000+ SKUs.

What's in the Free Tier
I want to be specific about this because "free" means very different things from different vendors.
Free tier includes:

Multi-channel sync to all 30+ supported channels
Real-time webhook-driven updates
Variation-level SKU tracking
Order import from connected channels
Standard support via the WordPress.org forum

No credit card required. No 14-day countdown that crippleware-locks the plugin. The free tier is built to be a real product for small-to-mid-volume stores, not a 14-day demo.

Paid tiers add multi-warehouse routing, advanced fulfillment workflows, custom reporting, and priority support. Most stores under 1,000 orders/month don't need any of it.

*The Architecture *
Since this is dev.to, here's the technical short version.
The plugin hooks into WooCommerce's native action system to capture stock change events:
phpadd_action('woocommerce_product_set_stock', 'nventory_handle_stock_change', 10, 1);
add_action('woocommerce_order_status_changed', 'nventory_handle_order_change', 10, 4);
Stock changes fire non-blocking webhooks to the Nventory platform, which fans them out to every connected channel in parallel. The platform handles the complexity that makes multi-channel sync hard: idempotency keys, exponential-backoff retries, HMAC signature verification, out-of-order event handling, and channel-specific API quirks (Amazon's SP-API throttling rules alone could be its own blog post).

The plugin itself stays lightweight. It doesn't poll. It doesn't run heavy cron jobs on your hosting. It listens for events and forwards them. Total plugin footprint is small, intentionally.

**What It Doesn't Do (Yet)
**I'd rather be honest about this than oversell.

No native ERP integration yet. If you need NetSuite or SAP-level workflows, this isn't your tool today.

B2B-specific features are limited. Wholesale pricing tiers, complex tax exemption logic, and BOM tracking aren't first-class features yet.

Some marketplace integrations are deeper than others. Amazon, eBay, Walmart, Shopify, and WooCommerce are very mature. Some of the smaller channels (specific regional marketplaces) are less battle-tested under high volume.

The roadmap is being shaped publicly based on user feedback. If something's missing that would unblock you, the WordPress.org support forum and nventory.io contact channels are both monitored.

What I'm Hoping the dev.to Community Will Help With
A few specific asks for anyone who reads this far:

Try it on a staging store. If you run a WooCommerce store that sells on multiple channels, install on staging, connect a sandbox marketplace, and tell me what breaks. Real-world feedback from technical operators is the only way this gets better.
Tell me what your current setup looks like. I want to understand what plugin stacks people have ended up with, what's working, what's not. Drop it in the comments.
Be brutal in feedback. This is launch day. Issues you find now save real stores from headaches later. The harsher the feedback, the more useful it is.
Suggest integrations. If there's a specific channel, 3PL, or accounting tool that would unlock your stack, I want to know. Why Launch on dev.to

Most launch posts go to Product Hunt, Twitter, or LinkedIn. I'm posting here because dev.to readers actually evaluate technical claims. I'd rather get torn apart by 50 thoughtful developers than upvoted by 500 people who didn't read past the headline.

If you've built or operated something similar, your perspective is what I'm here for.
🔗 Plugin install: wordpress.org/plugins/nventory
🌐 Platform site: nventory.io
Thanks for reading. Open to questions, criticism, war stories from your own multi-channel sync nightmares — all of it.

The Engineering Problem Nobody Talks About When You Sell on Multiple Platforms

Nventory — Wed, 01 Apr 2026 09:19:57 +0000

I want to tell you about a bug that isn't a bug.
It doesn't throw an error. It doesn't crash your server. It doesn't show up in your logs.
But it costs businesses thousands of dollars a month, and most of them never trace it back to the root cause.
Here's the scenario.
A seller runs an online store across Amazon, Shopify, and Flipkart. They have 10 units of a product in their warehouse. All three platforms show 10 units available.
At 2:14pm, someone buys 10 units on Amazon.
At 2:17pm — three minutes later — someone buys 3 units on Shopify.
At 2:19pm — five minutes after the Amazon sale — someone buys 2 units on Flipkart.
Total orders: 15 units. Actual stock: 10 units. 5 orders that cannot be fulfilled.

No error was thrown. The database didn't corrupt. Every system did exactly what it was told.
The bug is the three-minute gap.

Why this is actually an architecture problem

Most multichannel ecommerce platforms are built with a polling model. Every N minutes, the system checks each connected channel and updates stock levels accordingly.
This made total sense in 2012. API rate limits were strict. Webhooks weren't standard. Batch jobs were the norm.
But in 2026, polling-based inventory sync is a design liability.
Here's what polling looks like under the hood:
// Simplified polling approach
setInterval(async () => {
const stock = await warehouse.getStockLevel(skuId);

await Promise.all([
amazon.updateListing(skuId, stock),
shopify.updateInventory(skuId, stock),
flipkart.updateStock(skuId, stock),
]);
}, 1000 * 60 * 15); // every 15 minutes
Looks fine. Works fine. Until two channels sell the same last item in the gap between polls.

The event-driven alternative

The fix is treating every stock change as an event — not a state to be periodically checked.
// Event-driven approach
stockEventEmitter.on('stock.changed', async (event) => {
const { skuId, newQuantity, source, timestamp } = event;

// Propagate to all channels except the source
const targets = channels.filter(c => c.id !== source);

await Promise.all(
targets.map(channel =>
channel.updateInventory(skuId, newQuantity, {
idempotencyKey: ${skuId}-${timestamp}
})
)
);
});

When a sale happens on Amazon, it fires a stock.changed event immediately. Every other channel gets updated within seconds — not at the next poll interval.

But wait — what about race conditions?

This is the part that gets interesting.
What if two channels sell the last item simultaneously? You fire two stock.changed events at essentially the same time. Both channels try to update each other. You end up with -1 stock.
This is where you need optimistic locking at the inventory level:
async function decrementStock(skuId, quantity, channelId) {
const result = await db.query(UPDATE inventory SET quantity = quantity - $1, version = version + 1, last_modified_by = $2 WHERE sku_id = $3 AND quantity >= $1 -- prevent negative stock RETURNING quantity, version, [quantity, channelId, skuId]);

if (result.rowCount === 0) {
// Stock wasn't available — trigger oversell prevention
throw new InsufficientStockError(skuId, quantity);
}

// Emit event with new quantity
await stockEventEmitter.emit('stock.changed', {
skuId,
newQuantity: result.rows[0].quantity,
source: channelId,
timestamp: Date.now(),
version: result.rows[0].version
});
}
The WHERE quantity >= $1 clause is the guard. If two channels try to sell the last item simultaneously, only one database write succeeds. The other throws InsufficientStockError and the order gets flagged before it's confirmed.
No oversell. No negative inventory. No angry customer.

The three layers that actually make this production-ready
After building this system, here's what we learned:

Idempotency keys everywhere Channel APIs get called multiple times on network failures. Without idempotency keys, a retry creates a second inventory update that corrupts your counts.
Version vectors for conflict resolution If Channel A updates stock to 8 and Channel B updates stock to 7 in the wrong order, you need a version number to know which update is canonical.
Dead letter queues for failed propagations Sometimes a channel API is down. You need a queue that retries failed updates, not a system that silently drops them and leaves your channels out of sync indefinitely.

What this looks like at scale

When we built this out for Nventory — a multichannel inventory platform — the results were measurable immediately:

Sync lag dropped from 15 minutes average → under 5 seconds
Oversold orders went from 15–30/month → 0
Manual reconciliation time: 4–6 hrs/week → zero

The architecture wasn't complex. The concepts aren't new. Event-driven systems have existed for decades.

The problem was that most ecommerce tooling was built before this pattern was standard — and nobody went back to fix it.

The broader lesson
Polling is a smell.

Any time you're checking state periodically instead of reacting to changes, ask yourself: what's the worst-case cost of the gap?
For a weather dashboard, a 15-minute lag is fine. For inventory that's selling across 5 platforms simultaneously during a flash sale — it's catastrophic.

The right architecture matches the cost of latency in your domain. In inventory, that cost is high. So latency has to be near-zero.
That one reframe changed how we designed everything.

Curious if anyone else has hit this in other domains — booking systems, ticket availability, seat reservations. It's the same problem wearing different clothes.

Would love to hear how others have handled concurrent writes at the inventory/availability layer.

The Distributed State Problem Nobody Talks About in Ecommerce

Nventory — Tue, 31 Mar 2026 05:08:07 +0000

If you've ever built integrations for a multichannel ecommerce platform, you've hit a problem that looks simple on the surface and gets deeply interesting the moment you put it under load.
Every marketplace — Shopify, Amazon, eBay, Walmart, Flipkart — maintains its own completely isolated inventory record. They were each designed to be the center of a seller's universe, not one participant in a larger synchronized system.
When you're building a platform that connects all of them, you inherit a distributed state problem: the same piece of data (available quantity for a SKU) exists in N independent systems simultaneously, with no native coordination mechanism between them.
Here's how that problem behaves in production, and the architecture we settled on after learning the hard way.

Why the naive approach fails
The first implementation most teams reach for is a scheduled sync job. Every N minutes, read the master count and push it to every connected channel.
This works at low volume. It fails in specific, predictable ways at high volume.
The polling window is your exposure window. A 15-minute sync cycle means every channel has a 15-minute window where it can sell stock that no longer exists. During a demand spike — a flash sale, a viral product moment, or an AI shopping agent recommending your product to millions of users simultaneously — you can sell the same unit on five channels before a single sync propagates. The data on this is clear — real-time sync consistently outperforms batch updates in every high-velocity scenario.
Last-write-wins corrupts state. If two channels both decrement their local count between sync cycles, the next polling run overwrites one of those decrements with a stale value. You don't just fail to prevent the problem — you actively undo a correct update.
Polling doesn't scale gracefully. As SKU count and channel count grow, sync jobs take longer. A job that runs in 8 minutes on a 15-minute cycle is no longer a 15-minute sync — it's a continuous operation that never fully completes.

The event-driven model
The architecture that actually works treats every sale as an event that must immediately propagate to every connected channel.
When a sale fires on any channel:

Webhook received — acknowledge immediately
Payload queued for async processing
Idempotency check — has this event ID been processed before?
Atomic conditional decrement against master inventory
Fan-out to all connected channels
Event ID stored as processed
Hourly reconciliation catches anything the event stream missed

Each step handles a specific failure mode.

Atomic decrements — the race condition fix
A standard decrement is not safe under concurrent load. If two orders arrive simultaneously from different channels for the last unit, both read quantity = 1, both decrement, you're at -1 with two confirmed orders.
The fix is a conditional decrement that only executes if the guard condition is met:
sqlUPDATE inventory
SET quantity = quantity - 1
WHERE sku = $1 AND quantity > 0
RETURNING quantity
If this returns no rows, the sale fails cleanly as out-of-stock. If it returns a row, the sale succeeded. No race condition possible regardless of concurrency.

**Idempotency — the retry problem
Platforms retry webhooks on failure. Shopify retries 19 times over 48 hours. Amazon SNS can retry up to 100,000 times with exponential backoff.
Without idempotency, a single network hiccup becomes 19 duplicate inventory decrements.
Every event needs a unique identifier. Every processed event ID needs to be stored. Before processing, check whether you've seen the ID before. If yes, return cached result. If no, process and store.
sqlINSERT INTO processed_events (event_id, channel, sku)
VALUES ($1, $2, $3)
ON CONFLICT (event_id) DO NOTHING
RETURNING event_id;
If this returns a row — new event, process it. If it returns nothing — already processed, skip it.

**Webhook reliability variance
Every platform has different delivery guarantees and different retry behavior.
Shopify gives you 5 seconds to acknowledge or it retries. Any synchronous processing that exceeds 5 seconds triggers retries for successfully-processed events. Handler must return 200 immediately and process asynchronously.
Amazon SNS retries up to 100,000 times with default configuration. Idempotency is non-negotiable here.
WooCommerce has no retry mechanism at all. Silent failures are possible. Reconciliation catches what webhooks miss.
TikTok Shop's webhook implementation changed twice during our integration period. Plan for API changes in your version management strategy.
The abstraction that helps: normalize every incoming webhook into a canonical internal event format before it touches any business logic. Platform-specific handling lives in the ingestion layer. Everything downstream sees a consistent event schema.

Rate limits under load
One sale triggering simultaneous API calls to five channels — each with their own rate limit budget — can exhaust your quota across all channels simultaneously during a demand spike.
The fix: queue updates and batch them intelligently within each channel's rate limit budget. A small buffer between the event and the outbound API call gives you rate limit management without sacrificing meaningful latency. The tradeoff is a small increase in propagation time — typically under 30 seconds under high load — in exchange for not exhausting API quotas during the exact moments when you most need them.

Reconciliation — the safety net
Even with all of the above, events get missed. Network partitions. Deployment windows. Platform outages. Over time small discrepancies accumulate.
Hourly reconciliation compares the master record against each channel's reported count and corrects any drift. The master record wins — always. Channels that drift get corrected from it, never the other way around.
In practice, reconciliation catches roughly 2-3% of events that the webhook layer misses. Small enough that the system is reliable. Large enough that you'd notice immediately if reconciliation stopped running.

The result
We run this architecture across 34 marketplace integrations at Nventory — Shopify, Amazon, Flipkart, WooCommerce, TikTok Shop, and more. Sub-10 second propagation under normal load. The reconciliation layer handles the edge cases the event stream misses.
If you're evaluating platforms for multichannel ecommerce operations, you can see the full list of integrations and pricing starting from $25/month here.
The pattern isn't ecommerce-specific. It's the same distributed state problem that shows up in any system where the same data lives in multiple independent stores simultaneously. The specific mechanics are ecommerce-flavored. The underlying architecture is just distributed systems.
If you're building something similar or have hit different failure modes, I'd genuinely like to compare notes in the comments.

How We Built Real-Time Inventory Sync for Multi-Channel E-Commerce

Nventory — Tue, 17 Feb 2026 11:55:30 +0000

Managing inventory across multiple sales channels is one of the hardest operational problems in e-commerce — and it gets even tougher at scale.

At Nventory, we faced this firsthand while working with brands selling on Shopify, Amazon, eBay and more. Each platform has its own API behavior, rate limits, and inventory logic. That’s where the idea for real-time inventory sync came from.

🧠 The Problem

Most sellers rely on:

Native integrations that refresh stock every few minutes
Spreadsheets and manual reconciliation
Disconnected systems for orders and shipping

These cause:

Overselling
Stock mismatches
Fulfillment delays
Manual work that steals engineering time

🔧 Our Solution

We built a system that:

Syncs inventory in real time across all channels
Centralizes order management in one dashboard
Automates fulfillment and routing
Supports multi-warehouse operations
Integrates with major carriers

🧵 Technical Highlights

Event-driven architecture for instant updates
Webhooks + API sync to minimize delay
Horizontal scaling for growing catalogs
Configurable workflows and routing logic

🚀 Why It Matters

Real-time sync isn’t just about accuracy — it’s about:

Preventing revenue loss from oversells

Reducing operational overhead

Freeing up teams to build, not fix

If you’re building tools for commerce or solving similar distributed state challenges, I’d love to hear your approaches!