Shop and stock

Your shop has the products. Google Shopping still shows last week's stock

Selling on Google Shopping, Bol, Amazon or Meta catalog means maintaining a product feed that is never wrong for long — price, stock, GTIN, shipping label, image URL. Your WooCommerce shop already has that data; the feed is a translation layer each channel reads differently.

Channable is a Dutch feed management platform built for that translation: import from the shop, apply rules, export to dozens of channels. The integration work is making the import reliable and the rules honest — so a sale at nine appears in Merchant Center before ads send traffic to the old price.

  • WooCommerce to Channable import on schedule or webhook
  • Rules for GTIN, shipping and channel-specific fields
  • From €1,700 plus service fees
The tool

What Channable is, and where it sits between shop and ads

Channable imports product data from WooCommerce, Shopify, Magento and other sources, lets you map and transform fields with rules — concatenate title parts, calculate margin, exclude out-of-stock SKUs — and exports XML or CSV feeds to Google Merchant Center, Meta, Amazon, Bol and many others. It is widely used in the Netherlands and increasingly abroad for the same reason: one place to fix feed problems instead of one broken export per channel.

Google Shopping and marketplace policies are strict about identifiers, landing page match and availability. A missing GTIN, a price mismatch between feed and page, or shipping cost that does not match checkout will disapprove products silently until someone notices performance drop. Channable's value is catching those rows before export; the integration's value is feeding Channable data that is current without manual CSV uploads.

Channable is not a shop and not an ad platform — it does not hold orders or take payments. It is the hygiene layer between catalog truth in WooCommerce and what channels are allowed to show. When that layer lags, ad spend goes to products that cannot convert.

What goes wrong

Three things that go wrong with product feeds left on manual export

The shop is usually right. The feed is a copy nobody refreshed, or rules nobody updated when the catalog changed.

Sale prices in ads, full prices on the product page

Marketing launches a weekend discount. The feed still exports list price until someone re-runs an export Monday. Shoppers click, bounce, and Google learns the landing page does not match — disapprovals follow, and recovery takes days even after the feed is fixed.

What you see instead

Sale price and availability pull from WooCommerce on a short interval or on change, with a rule in Channable that blocks export when page price and feed price disagree.

Half the catalog disapproved for missing GTINs nobody knew were required

Google tightened identifier requirements for a category. The feed still sent blank GTIN fields because WooCommerce never stored them. Performance craters on best sellers until someone opens Merchant Center diagnostics and spends a week fixing rows one by one.

What you see instead

Required fields validated at import — flag products missing GTIN, brand or MPN before they reach any channel export, with a report merchandising can act on.

Each marketplace gets a manually tweaked CSV with its own typos

Bol wants Dutch titles, Amazon wants bullet points, Google wants structured data — so three people maintain three spreadsheets copied from the shop. One typo in shipping weight duplicates across channels, and returns spike on a product that advertised the wrong dimensions.

What you see instead

One Channable project with channel-specific rules and a single WooCommerce import — change the title rule once, every export inherits it.

The bill for doing it by hand

What bad feeds cost in ad spend and merchandising time

Disapproved products still burn setup time: someone reads Google's error message, finds the SKU, fixes the shop or the rule, waits for re-crawl. At fifty SKUs that is a day; at five hundred it is a standing weekly task.

Stale feeds cost clicks: you pay for traffic to offers that are out of stock or mispriced. The ROAS drop shows up in ads before anyone connects it to a feed timestamp from three days ago.

  • Weekly hours fixing Merchant Center disapprovals by hand.
  • Ad spend on products the feed marked available when the shop did not.
  • Duplicate title and attribute work per marketplace.
  • Campaign pauses while waiting for someone to re-export CSV.
What we build

We build the thing on the other end too

Channable projects succeed or fail on field mapping in WooCommerce first — if GTIN and shipping data are not in the shop, no feed tool invents them reliably.

A connection needs two ends. Plenty of agencies will build you the API call and hand you a JSON payload; that is the easy half. The harder half is what the data lands in — a website, a webshop, a portal your customers log into, an internal tool that replaces a spreadsheet. JKC builds both ends, which is why the connections we build tend to keep working: nothing about the receiving side is a black box to us.

API integrations

The connection itself: authentication, field mapping, rate limits, retries and a queue that survives the other system being down for an hour. Built against the documented API where there is one, and against whatever the vendor really offers where there is not.

Websites

WordPress sites that read from your systems instead of repeating them by hand: a careers page fed by your HR system, a team page that follows your payroll, prices and availability that are the real ones.

Webshops

WooCommerce shops where the order is the last time anyone types it: it becomes an invoice in your accounting package, a label at your carrier, a stock mutation in your warehouse, and a line in your CRM, on its own.

Web applications

When the process does not fit any standard product: a customer portal, a quoting tool, a planning board, a dashboard that reads three systems at once. Built on your data, with your systems as the source instead of a copy of them.

What can be connected

What we connect between WooCommerce and Channable

Import reliability and rule design matter more than adding another export format — Channable already speaks most channels.

  • Product, variant and stock data into Channable (out of the tool)

    SKU, title, description, price, sale price, availability, images, categories, GTIN, brand, weight and custom attributes — on schedule or triggered when stock or price changes.

  • Rules for channel-specific titles and exclusions (both ways)

    Exclude B2B-only SKUs from consumer channels, append size to titles for Google, map WooCommerce shipping classes to feed shipping labels — documented so merchandising can adjust without a developer.

  • Exports to Google Merchant Center and Meta catalog (out of the tool)

    Validated feeds with alert when disapproval rate spikes — often the first channels before adding marketplaces.

  • Error and disapproval feedback into a report or ticket (into the tool)

    So the person who owns catalog quality sees which SKUs broke which rule yesterday, not only when ads stop performing.

Start with one import and one Google export. Add Meta and marketplaces when the base mapping is stable — adding channels to a broken import multiplies the brokenness.

How it works

How a connection gets built at JKC

The same four steps every time, whichever tool it is. Nothing here is a workshop you pay for: step one exists because scoping a connection wrong is the single most expensive thing that can happen to it.

  1. 1. We look at what is actually being retyped

    Not "which fields exist" but "which fields does somebody currently move by hand, how often, and what breaks when they get it wrong". Most projects turn out to need two or three flows, not a full two-way sync of everything. That conversation is what keeps the quote where it is.

  2. 2. We pick the route, and say why

    A maintained connector from the vendor, a platform like Make or Zapier, or a custom integration against the API. Cheapest first, not custom first: if a supported plugin does exactly what you need, that is the answer and we will tell you so. Custom is for the cases where the off-the-shelf option would need so much configuring that it becomes the fragile option.

  3. 3. We build it to survive the other system

    Every connection ships with retries, a queue and an idempotency key, so an order that arrives while the other side is down is delivered later rather than lost, and a retry does not create a second invoice. On a test environment first where the vendor offers one, so the first thing your real administration sees is a working connection.

  4. 4. We hand it over with the failure modes written down

    Which alerts you will get, what each one means, what to do about it, and who to call. Plus the credentials in your own name, in your own vault — not in ours. A connection nobody but us can maintain is a connection you do not own.

After it goes live

A connection that fails silently is worse than no connection

This is the part most quotes leave out. A connection that stops working without telling anyone is worse than manual work, because with manual work at least somebody notices when it does not get done. Every connection JKC builds is monitored, and the monitoring is not an upsell — it is in the service fee.

An alert per failed message, not a monthly report

A message that does not get through raises an alert the same hour, with the record it was about. Not a dashboard you have to remember to look at.

Replay, not re-enter

Anything that failed sits in a queue and can be sent again once the cause is fixed, in order. Nobody goes back through yesterday to find the four orders that did not land.

We watch the vendor's changes, so you do not have to

APIs get versioned, deprecated and rate-limited. When a vendor announces a change that affects your connection, adjusting to it is part of the service fee, not a new project.

What it costs

From €1,700, and the biggest variable is who built the other end

Channable's own WooCommerce connector covers basic import for many shops. Custom work earns its place on webhooks for stock, complex variant mapping, validation before export, and tying feed health to someone's actual workflow.

A connection starts from €1,700 plus a monthly service fee, which covers the monitoring, the queue and keeping up with the vendor's API changes. Work outside a fixed scope is €95 per hour.

What moves the number is not the tool — it is how well the system on the other end is known. If JKC built your website, your webshop or your web application, we already know its data model, its edge cases and where its stock numbers really come from, and a connection into it is mostly configuration and testing. If it is a system we have never opened, we start with a short technical check of both sides and quote after that, so you are not paying hourly for us to work out the basics.

Two more things that move it, in our experience more than anything else: whether the tool has a real API or only a CSV export, and whether the sync has to go both ways. One-way is roughly half the work of two-way, because two-way means deciding, per field, which system wins when they disagree — and that decision is the expensive part, not the code.

Questions

Questions we hear about Channable and product feeds

WooCommerce can export CSV; Google and marketplaces each want different columns, update frequencies and error handling. Channable is the layer that makes one shop export many valid feeds.

If you sell on one channel only and export twice a week without disapprovals, you may not need it yet. The moment a second channel or daily price changes appear, manual export usually breaks.

Free, 10 minutes

Not sure where the manual hours actually go?

That is what the Growth Scan is for. Ten minutes, no sales call attached: you get back where the double work sits, which connection would pay for itself first, and which one honestly would not.