Why Actindo plus WooCommerce is a powerful duo
WooCommerce is flexible. You can quickly get a shop live, and you can customize themes, plugins, and checkout processes. However, things can get chaotic as soon as you add many products, variations, and channels. That's when you need a system to bring order to the chaos.
Actindo can take on the role that WooCommerce doesn't want to be: the central ERP and PIM hub. It manages product data in one place, distributes it to the shop, and collects orders. This saves time and reduces errors. And yes, it also saves a lot of stress, especially if you don't want to manually adjust prices and stock levels every day.
Typical goals you can achieve with it
- Uniform product data, even with many attributes and variants
- Clean inventory, even with multiple warehouses or delivery times
- Automatic pricing logic, B2B pricing, tiered pricing, promotional pricing
- Order sync without copy and paste, including status, shipping and cancellation.
Things you need to clarify before starting, otherwise it will be expensive later.
Before you talk about interfaces, webhooks, and cron jobs, clarify two things. First, which system is dominant? Second, which data actually needs to be synchronized? If you skip this, you'll build a synchronization machine that runs, but spits out nonsense.
System leadership, who has the last word?
In most setups, Actindo is the primary system for product data, pricing, and inventory. WooCommerce then serves as the sales channel. This makes sense because it provides you with a single source of truth. One.
When it comes to orders, it's usually the other way around. WooCommerce creates the order, and Actindo handles the processing. Again, you define where status changes occur. Otherwise, your order will bounce between systems like a rubber ball.
Scope, what are you actually syncing?
Make a list, a real list. Products, variants, categories, attributes, images, prices, stock levels, customers, addresses, orders, shipping methods, payment methods, coupons, returns, invoices. Then prioritize.
My advice: start small. First, products, inventory, and orders. Then prices, then customers, and finally special cases like returns and partial deliveries. Otherwise, you'll spend months testing everything at once and wonder why it all feels so clunky.
If you want to get an overview of Actindo, use the official website as a starting point: Actindo platform overview in German
.
This will help you with terms, modules, and typical areas of application.

Woocommerce actindo connector – ERP-CRM integration – 🔌Connecting Actindo, ERP and PIM to WooCommerce: data synchronization works without any headaches.🔄
Data model first, integration afterwards
Integration rarely fails due to technical issues. It fails due to data. It sounds dramatic, but it's true. If you don't structure your PIM data properly, WooCommerce will later turn it into a jumbled mess. And then you'll start patching things up in your shop instead of solving the problem at its source.
Product ID, SKU and slug: three things you shouldn't mix up.
Define a clear identity for each product. In WooCommerce, SKU and product ID are not the same. SKU is your business key. The product ID is technical. And the slug is for the frontend and SEO.
- Use SKU as a stable key across both systems
- Allow WooCommerce IDs to be assigned automatically, and save the mapping in Actindo.
- Generate slugs in WooCommerce from names, but do so in a controlled manner to avoid duplicates.
Variants, attribute logic, not everything is an attribute
WooCommerce variants work well if you define them clearly. Color and size are classic variant drivers. But a technical characteristic like material, wattage, or connector size is often better as a filter attribute, not as a variant driver.
In Actindo, you define which features constitute variants and which are only for search and filtering. If you force everything into variants, your number of variants explodes. If you make everything into attributes, you can't order them cleanly. Balance.
Categories and taxonomies: keep it streamlined in the shop.
A PIM system encourages you to stack categories. WooCommerce can do this too, but the navigation quickly becomes cluttered. Plan your categories so that customers can easily navigate them. And plan your attributes so that filters are truly helpful.
My trick is to focus on the customer perspective first, then the data model. Not the other way around. Otherwise, you'll build a category that looks technically nice, but nobody will click on it.
Images and media; no integration without rules
Images are often the hidden source of errors. Sometimes a URL is missing, sometimes a file contains special characters, sometimes an image is huge, sometimes it's created twice. Define rules.
- File names without umlauts and without spaces
- A clear sequence: main image, gallery, detail images
- Manage alt text centrally, ideally in the PIM, and transfer it to WooCommerce.
- Standardize sizes and formats, otherwise loading time will suffer.
If you're already more deeply involved, also check out this internal article that explains Actindo integrations and data sync from a practical perspective. Integrate Actindo into your online shop, sync data
.
Technical architecture, this is how the sync becomes stable
Now things get more concrete. You basically have two options: you can use an existing connector, or you can build a custom integration using APIs. Both approaches are fine. The crucial factors are your setup, your data volume, and your need for custom logic.
Option 1, Connector or Middleware
A connector is convenient. You get standard mapping and common processes. That's great if you can work closely with the standard. But always check if it can handle your specific needs: product variants, B2B pricing, multiple tax classes, multiple warehouses, partial deliveries. If you're already feeling nervous just reading about it, test it very early on.
Option 2, Custom Integration via WooCommerce REST API
WooCommerce offers a REST API. This allows you to create and update products, set stock levels, retrieve orders, and manage customers. You need a robust authentication concept and robust error handling. And you need a queue if you don't want your sync to time out.
Push, pull or hybrid
You can push data, meaning send it from Actindo to WooCommerce. Or you can pull data, meaning WooCommerce is queried. In practice, a hybrid approach is often best.
- Push products, prices, and stock levels from Actindo into your shop
- You pull orders regularly or receive them via events.
- Depending on the process, you can mirror status changes in both directions.
Batching instead of continuous fire
If you have 30.000 products, don't send 30.000 individual requests in one go, without a break. Work in batches. Set limits. Use retries with backoff. Otherwise, you'll block the API or cause load spikes that your shop won't like.
Mapping practice: how to translate Actindo data into WooCommerce logic
Mapping sounds dry, but it's the core concept. You build a translation table, field by field, with rules and examples. If you just collect field names, you'll lack the logic later.
Products, mandatory fields and typical pitfalls
In WooCommerce, you need at least a name, type, status, and pricing logic. For variants, you need a parent product, attributes, variation values, and often a unique SKU for each variant.
- Standard product, simple product, available for direct order
- Variant product, variable product, variants separately
- Virtual product if there is no delivery
- Download the product if you are delivering files.
Check early on whether you're using net or gross prices in your shop, and whether Actindo does the same. An integration can be technically sound, but still deliver incorrect prices if your tax logic isn't synchronized.
Inventories, warehouse logic and reservations
Stock synchronization is often the reason why you connect to an ERP system in the first place. So treat it with respect. Define whether the shop sees actual stock levels or available stock after reservation. And define how you will handle backorders.
- Current inventory, what is physically present
- Available, stock minus reservations
- Delivery time if not available
- Backorders, yes or no?
Orders, status mapping, without ping pong
Orders come from WooCommerce. Actindo processes them. Now you define the status. In WooCommerce, for example, there are statuses like pending payment, processing, on hold, completed, cancelled, and refunded. In Actindo, you often have your own statuses, such as released, packed, shipped, and invoiced.
Build a status matrix. Define which status is set in which system. And which status changes are reflected back. Otherwise, this is what happens: Actindo sets "sent," Sync sets "WooCommerce completed," the WooCommerce plugin sets something else, and you're sitting there quietly saying "ouch."
Shipping and tracking
If you have tracking numbers, import them back into WooCommerce. This reduces support tickets . Customers don't want to wait; they want to click. And preferably immediately. If you have multiple shipping providers, include a field for the carrier code and tracking link.
If shipping is tricky for you, for example with bulky goods, surcharges or mixed baskets, this internal article can help you. Integration of complex shipping methods
.
For a solid WooCommerce foundation, including basic information on updates, compatibility and plugin setup, the Wordpress A good, neutral starting point is the plugin page: WooCommerce on WordPress.org in German
.
Tests you really need to do, otherwise your customer will test them for you
I'm saying this politely because I'm nice. If you launch an integration without testing, your support inbox will be flooded. Testing isn't optional; it's mandatory.
Test data, build yourself a mini universe
Create a small product world that covers everything. A simple product. A variant product with three attributes. A product with tiered pricing. A product with a sale price. A product without an image. Yes, even that. Then test the import. And check in the frontend whether everything looks as intended.
Order flow, from A to Z
Test orders with different payment methods. Test shipping. Test coupons. Test cancellations. Test refunds. Test partial refunds. If you have a B2B business, test net prices, VAT ID, billing address, and different shipping addresses. This is where most integrations falter.
Errors occur because they are guaranteed to happen.
Simulate timeouts. Simulate API errors. Simulate an existing SKU. Simulate invalid characters in attributes. Your system must respond cleanly. Log. Retry. Or write to an error log. The main thing is that it doesn't silently ignore anything.
Performance and stability, so your shop doesn't lag.
An integration shouldn't slow down your shop. You can achieve this by decoupling sync processes. You push data into a queue. You process it asynchronously. You avoid heavy jobs in the middle of the day when traffic is high.
Timing: when do you sync what?
- Stock is replenished more often if you sell out quickly, otherwise less frequently.
- Prices are regularly quoted, but not every minute.
- Product texts and pictures are better taken at night because there is a lot of data involved.
- Orders near real-time, because fulfillment matters
Delta Sync instead of Full Sync
Sync only what has changed. This sounds trivial, but it's a game-changer. If you send everything every time, you'll see performance issues later. Use modification timestamps. Use hashes. Use flags like `needs export`. Anything is better than running in circles at full speed.
Monitoring so you can see problems before your customer sees them
Build yourself a dashboard. It can be simple: number of successful sync runs, number of errors, last runtime, average runtime. Additionally, a list of the last 50 errors with payload excerpts. This will help you identify patterns.
And please, don't just send bug reports to the log and leave it at that. Forward them to a channel, email, Slack, or whatever you use. Otherwise, you won't notice the bug until someone asks why product X is gone.
Typical special cases and how to solve them cleanly
Now we come to the points where integrations tend to fail. Not because it's impossible, but because no one has defined the rules beforehand.
Multilingual support
If you have multiple languages, you need clear field mapping for each language: product name, short description, description, SEO title, and meta description. Plan this early on. Otherwise, you'll end up creating a translation layer later, which is twice the work.
B2B prices and customer-specific conditions
If you're doing B2B, prices are often stored in your ERP system. WooCommerce can map B2B prices via plugins. Your mapping then needs to know which price group belongs to which customer and how to keep price lists synchronized. This is doable, but you need clear rules; otherwise, the price in the shopping cart won't be correct.
Taxes and rounding
Tax rates and rounding rules must match. Check whether Actindo displays net prices and WooCommerce shows gross prices, or vice versa. Check rounding at the item level and on the total. Otherwise, you'll have a cent difference on every other invoice , and that cent will bother you more than it should.
Cleanup and restart if you have old shop data
Sometimes you start with an old WooCommerce store where products have grown haphazardly. In that case, it helps to clean up the store and then import everything cleanly. If you plan to do this, read the internal article on the topic to ensure you do it correctly. Delete all products in WooCommerce, controlled via the database.
.
ERP Integration as a complete picture
If you're not just thinking about Actindo, but rather ERP, CRM, and WMS in general, then looking at typical integration patterns will help. Here's an internal overview that often provides good ideas, especially when multiple systems are involved.ERP integration, patterns, interfaces and typical projects
.
To ensure your setup remains stable in the long term, you need a clean update procedure. WordPress updates aren't exactly glamorous, but they'll save your day-to-day work.Official guide, updating WordPress
.
Rollout and operation: how to go live without drama
A good go-live feels boring. Yes, boring. Don't panic. No surprises. You need a plan for that.
Staging first, always
Build the integration in a staging environment. Import a subset. Test the frontend and backend. Have business units check whether product descriptions, variants, and prices are correct. Only proceed once the staging environment is clean.
Cutover plan: who does what, when
Decide when to pull the latest data. Decide when to briefly freeze the shop, if necessary. Determine how to handle orders that come in during the cutover. And schedule time for a rollback, even if you don't think you'll need it. It's like an umbrella: if you have one, it often doesn't rain.
After going live, the first week is observation time.
During the first week, you'll check your monitoring daily. You'll review error lists. You'll conduct spot checks on orders. You'll monitor inventory levels. And you'll adjust sync intervals if you notice something is running too often or too infrequently.
Tell me, how do you do that? I want to hear real examples.
Now it's your turn. Tell me in the comments what your setup looks like. How many products do you have? How many variations? What are your prices? Is it B2C or B2B? And what's your biggest pain point: inventory, pricing, copy, or order status?
And I'm asking you three questions because I'm curious and because it helps others.
- Which data should come from Actindo, and which should remain in the shop?
- How often do you want to synchronize inventory and prices?
- What special cases do you have, such as returns, partial deliveries, multiple warehouses, or customer-specific pricing?
If you like, I can also derive a short mapping checklist from your answers. No fluff. Just concrete fields.
Who wrote this post
Storetown Media is a WooCommerce agency based in Tornesch near Hamburg, connecting online shops to inventory management systems since 2012. We've integrated Actindo, JTL-Wawi, Xentral, SAP Business One , and Oracle NetSuite – but the questions that truly matter are rarely technical: Who manages the inventory? What happens if a transaction is canceled? Who resolves conflicts between two systems?






















{% endif %} {% if title and title != "" %}
{{ title }}
{% endif %} {% if excerpt and excerpt != "" %}