This article consolidates the known limitations of the Shopware integration into a single authoritative list, drawn from the individual mapping collection descriptions and mapping documentation. These limitations are inherent to the current design of the integration and to the capabilities of the Shopware Admin API. They are documented so subscribers or their MiSP can plan their configuration accordingly, and they apply to all subscribers at the time this documentation was written.
Platform Scope and Tested Versions
The integration connects Shopware 6 to iPaaS.com through the Shopware Admin API, and has been tested end-to-end against Shopware 6.6.10.4. For details on the Admin API, refer to Shopware's Admin API documentation.
Several capabilities depend on Shopware commercial or extension features:
B2B Company and employee synchronization requires the Shopware Commercial (B2B Suite) extension. Without it, B2B Company, B2B Company Address, and B2B Employee functionality is not available.
Warehouse-level and multi-warehouse inventory requires Advanced Stock Management, a premium Shopware capability. Subscribers without it track stock only at the parent product or variant level.
Certain order-delivery behaviors depend on the Partial Delivery extension, and sales-channel-specific product content depends on the Sales Channel Specific Content extension.
Webhook-driven automatic transfer workflows can only be created on Enterprise editions of Shopware. On other editions, subscribers should rely on Manual Sync or bulk Initialization instead.
Not built for: This integration is built for Shopware 6 self-hosted stores reachable through the Shopware Admin API. It is not built for Shopware 5 or earlier, and it has not been validated against Shopware Cloud (the hosted SaaS edition), whose API surface and extension availability differ from a self-hosted Shopware 6 store. If Shopware releases a separate product line or a materially different major API version in the future, this integration will not automatically support it.
When a transfer fails, the error is recorded in the iPaaS.com Dashboard under Integration Monitoring / Error Logs.
Limitations
1. Bulk Initialization Scope
Initialization is a one-time bulk backfill that loads existing reference data into iPaaS.com when the integration is first set up. It is supported for exactly four reference data types, all transferred TO iPaaS.com:
Payment Methods
Shipping Methods
Warehouses
Warehouse Groups
All other entities (including Customers, B2B Companies, Products, and Orders) and all flows running FROM iPaaS.com are not initialized. Those records transfer through webhook events, inbound transfers, or Manual Sync rather than through bulk Initialization.
What this means for you: You cannot pre-load your existing Customers, Products, Orders, or any FROM iPaaS.com data in one bulk pass. Plan to seed those records through Manual Sync or by letting normal webhook and transfer activity populate them over time, and only rely on Initialization for the four reference data types above.
2. Full-Record Replace on Update (Unmapped Field Overwrite Risk)
The iPaaS.com API performs a full record replace on every Update transfer. For any combined Add/Update collection running TO iPaaS.com, a standard iPaaS.com field that is left unmapped is overwritten with an empty value each time an Update transfer runs.
To preserve an existing value, split the combined Add/Update collection into separate Add and Update collections, and in the Update collection add a Dynamic Formula mapping that uses the DestinationValue function to carry the existing iPaaS.com value forward (for example, DestinationValue.Comment mapped to the iPaaS.com Comment field). The DestinationValue function reads the current value from the destination record before the replace and writes it back into the outgoing record.
The standard fields left unmapped in the default template — and therefore at risk on Update — are, per collection:
Add/Update Shopware Customer TO iPaaS.com: Comment
Add/Update Shopware Customer Address TO iPaaS.com: Type
Add/Update Shopware B2B Company TO iPaaS.com: AccountNumber, Department, Description, FaxNumber, ParentCompanyId, PhoneNumber, TaxIdNumber, Url
Add/Update Shopware B2B Company Address TO iPaaS.com: Company, PhoneNumber, Type
Add/Update Shopware B2B Company Relationship (B2B-Employee) TO iPaaS.com: StartDate, EndDate, IsPrimary
Add/Update Shopware Order Line Item TO iPaaS.com: DiscountPercent, EstimatedTaxAmount, QtyShipped, Weight
Add/Update Shopware Order Payment TO iPaaS.com: MethodInfo
Add/Update Shopware Order Excise Tax TO iPaaS.com: OriginalAmount, TaxPercent
Add/Update Shopware Order Address TO iPaaS.com: ShipDate, ShippingAmount, ShippingMethodDescription
Add/Update Shopware Order Return TO iPaaS.com (parent return): CompanyId, DiscountAmount, ShippingAmount, TransactionCreatedDateTime
Add/Update Shopware Order Return Line Item TO iPaaS.com: DiscountPercent, EstimatedTaxAmount, QtyShipped, Weight
Add/Update Shopware Order Return Excise/Calculated Tax TO iPaaS.com: OriginalAmount, TaxPercent
Add Shopware Order Deposit Address TO iPaaS.com (Add-only today; at risk only if later paired with an Update collection): ShipDate, ShippingAmount, ShippingMethodDescription
Add Shopware Order Deposit Line Item TO iPaaS.com (Add-only today; at risk only if later paired with an Update collection): DiscountAmount, DiscountPercent, EstimatedTaxAmount, QtyShipped, Weight
The parent Add/Update Shopware Order TO iPaaS.com collection has no unmapped subscriber-writeable fields (its remaining fields are server-managed by iPaaS.com), and the Warehouse, Warehouse Group, Shipping Method, and Payment Method TO iPaaS.com collections map all of their standard fields in the default template, so none of those carry an unmapped field at risk. If you introduce a new standard field on any of those collections, apply the same DestinationValue mitigation.
What this means for you: If you let the default Add/Update collection run Updates, the fields listed above will be wiped on every update unless you take action. Before relying on any of those fields holding a value in iPaaS.com, split the collection into Add and Update collections and add the DestinationValue mappings so existing values are carried forward instead of blanked out.
3. Deletions
Delete behavior is not uniform across entities:
Deletions that are propagated FROM iPaaS.com to Shopware: Product, Product Variant, Customer Group, Catalog Category, and Order Delivery. Each of these ships with a dedicated Delete collection. A Product, Variant, or Order Delivery delete has no effect when the iPaaS.com record is not linked to an existing Shopware record; in that case there is nothing to delete and an error is recorded.
Deletions that are not propagated: Customers, B2B Companies (including their addresses and employees), Orders, Order Returns, Payment Methods, Shipping Methods, Warehouses, and Warehouse Groups. Removing one of these records in either system does not delete the corresponding record in the other.
What this means for you: Only the five entities listed above will mirror a deletion across systems. For everything else, deleting a record on one platform leaves the matching record in place on the other, so you must remove it manually. If you need delete propagation for an entity that does not support it, validate an approach in a staging environment before relying on it in production.
4. Warehouse-Level Stock Is a Premium Capability
Warehouse-level inventory requires Advanced Stock Management. Subscribers without it cannot create, update, or maintain Shopware warehouses or warehouse groups, and track stock only at the parent product or variant level. For these subscribers, the inventory mapping must use the parent-level stock path (the UpdateParent option) so that stock reaches the parent product or variant; a warehouse-level adjustment is otherwise not reflected in their stock until a full product update runs.
Stock and inventory writes always bypass the indexing-deferral option (the Index Behavior Header setting), so stock refreshes do not defer Shopware re-indexing.
What this means for you: If your Shopware plan does not include Advanced Stock Management, do not configure warehouse-level inventory. Use the UpdateParent option so stock lands on the parent product or variant, and expect every stock write to trigger Shopware re-indexing immediately.
5. B2B Features Require the Commercial (B2B Suite) Extension
B2B Company, B2B Company Address, and B2B Employee collections all depend on the Shopware Commercial (B2B Suite) extension. A B2B company is created only when it has at least one valid employee relationship (an iPaaS.com Company Relationship of type Employee whose related customer has an email, first name, and last name); companies without a qualifying employee are not created. Employee Management must remain enabled on a B2B company so employees can be created and maintained.
What this means for you: If you do not have the B2B Suite extension installed, the B2B collections will not transfer data. When you do use them, make sure each company has at least one complete employee (email, first name, last name) and that Employee Management stays enabled, or the company will not be created.
6. Lookups and Related Records That Must Pre-Exist
Many fields resolve a Shopware record by name or ID at transfer time. Where the referenced record does not exist, the value resolves to nothing and, depending on the field, the transfer either leaves the value empty or fails. The following must pre-exist in the target Shopware store:
Shipping-method delivery time is lookup-only and is not created automatically; the named delivery time must already exist or the transfer fails.
Component products, related (cross-sell) products, and warehouses referenced by SKU or name must already exist and be linked in Shopware. A related-product link whose target does not yet exist is skipped; a kit component whose SKU does not resolve fails the transfer unless an optional filter is configured to skip unresolved components.
Named tax, currency, sales channel, customer group, language, payment method, and Shopware order states referenced by required fields must exist. If a required lookup finds no match, creation or update fails.
For Order Returns, the original Shopware order and the original order line for each returned SKU must both exist and be linked in iPaaS.com; returns and return lines that cannot be resolved are skipped. For Order Updates and Order Delivery updates, the target Shopware order must already exist and be linked.
What this means for you: Set up the referenced records (delivery times, tax rates, currencies, sales channels, customer groups, languages, payment methods, order states, component and cross-sell products, and warehouses) in Shopware before you run the mappings that point at them. If a required lookup cannot find its match, the transfer will either leave the field empty or fail outright.
7. Circular and Bidirectional Update Risk
Several entities have both a TO iPaaS.com and a FROM iPaaS.com collection — including Customer, Customer Address, B2B Company, Order, Order Return, Shipping Method, and Warehouse. When opposite-direction collections are active at the same time with default mappings, a change made in one system can echo back to the other and propagate back and forth.
What this means for you: Before enabling collections in both directions, decide which system is the source of truth for each entity and scope the mapping collection filters accordingly. For Order and Order Delivery in particular, leave the order-header-level status mappings unmapped when the corresponding status-update child collections are in use, to avoid conflicting updates.
8. Auto-Create and Name-Match Behavior Can Create Duplicates
Some lookups auto-create a missing record rather than failing, which means an inexact name can produce a duplicate:
Property groups and option values are matched by name (or the configured match field) and auto-created when no match is found. A name that does not exactly match an existing record — including differences in spelling or case — creates a new group or option rather than reusing the existing one, and the variant is then defined by the newly created record.
Scale units are matched by name only and auto-created when missing, with a short code derived from the name. Two slightly different spellings of the same unit (for example "Kilogram" and "Kilograms") resolve to, or create, two separate Shopware units.
Catalog categories use the Product Category Duplicate Checking By and Product Category Duplicate Matching By settings (by name, by description, or by a named custom field) to detect duplicates. Inconsistent naming, or a missing match custom field, can cause duplicate categories or a failed transfer.
What this means for you: Keep names consistent between the two platforms so the intended record is matched and reused. Small differences in spelling or case will silently create a duplicate group, option, scale unit, or category rather than reusing the existing one.
9. Custom-Field Names Must Match Exactly
The integration reads each custom field by its exact name, so the custom-field name configured on the source must match the name referenced in the mapping exactly. A missing or misnamed custom field disables the feature it drives rather than failing the whole transfer, except where a preset makes the value required (in which case the transfer errors). Features driven by specific custom-field names include the catalog-category duplicate-match field, the Shopware Category Tags field, the Shopware Tax Type field on shipping methods, sales-channel content fields, and the kit-component grouping field.
What this means for you: Double-check that every custom-field name in your mappings exactly matches the technical name configured in Shopware. A typo will usually disable the feature quietly (so it simply will not work), and where the value is required, the transfer will error.
10. Extension-Gated Product Content and Kit Behavior
Per-channel product content requires both the Product Content Processing setting and the Sales Channel Specific Content extension, plus correctly named content and image custom fields. With the setting enabled but the content-entity name missing, transfers error.
A product or variant cannot carry both related products and a kit at the same time in the default native cross-selling mode; writing a kit replaces the related-product configuration. The two coexist only when the Transfer Kits using API Extension setting is enabled, which requires a bundle extension installed on the Shopware instance.
Native cross-selling transfer is limited to the "productList" cross-selling type as provided.
What this means for you: If you need per-channel content or want a product to carry both related products and a kit, confirm the required extensions and settings are in place first. Without them, you can use either related products or a kit on a product (not both), and only "productList" cross-selling is supported.
11. Order and Return Processing Constraints
Promotion line items are excluded from transfer; order-level promotions are summed and applied at the order header level rather than as individual lines. Per-line discount amounts are not native to Shopware and require a customized Admin API with a line-item discount extension; without it, discount amounts are empty.
Excise and calculated tax rows are created only when their summed totals are non-zero, and are carried as a single combined row per order or return rather than per line.
Refund amounts on returns are determined automatically by Shopware from the original order data; custom, partial, or shipping-only refund amounts from iPaaS.com are not applied.
Order state and return state names are language-dependent. Stores configured in a language other than English or German may need the status mapping extended, or the affected records default to Pending.
Returns for custom or manually-added order lines are not supported. When a return is sent from iPaaS.com, each return line is matched back to a line on the original Shopware order by that order line's product, not by the SKU stored on the order line. An order line that was added to the original order as a custom or manual line item carries a SKU but is not linked to a Shopware product, so it has no product to match against and its return line cannot be associated with the original order line. This happens even when the SKU and a matching product both exist in Shopware — the blocker is that the specific order line was never linked to a product. Only product-linked order lines can be returned through this flow at the time this documentation was written. A return line that cannot be matched is rejected, and the message "This order line sku does not exist in Shopware for this order" is recorded in Dashboard / Integration Monitoring / Error Logs.
What this means for you: Expect promotions to appear as an order-header total rather than per line, expect tax to be combined into a single row, and expect Shopware to set refund amounts itself. If you operate in a language other than English or German, extend the status mapping so records do not default to Pending. And only product-linked order lines can be returned — returns against custom or manually-added lines will be rejected.
12. Child Collections Cannot Be Triggered Independently
Child collections — including customer and company addresses and relationships, and order, return, and deposit addresses, line items, payments, and taxes — cannot be triggered on their own from the Manual Sync page. Transfer the parent record to move its child records. Likewise, variants, property groups, option values, scale units, related products, and kit components are transferred only as part of their parent product transfer and have no independent transfer trigger.
What this means for you: To move an address, line item, payment, tax row, variant, or other child record, transfer its parent record (the customer, company, order, return, deposit, or product). There is no way to sync a child record by itself from the Manual Sync page.
13. Automatic Dependency Transfers on Orders
When an order or return is transferred from Shopware to iPaaS.com, the associated customer or B2B company is transferred automatically to capture the party on the order, even if the customer or B2B company webhooks are disabled. If a dependent customer or company record cannot be created, the order or return transfer fails. To prevent records from being created or updated during order transfers, disable the customer and B2B company mapping collections.
What this means for you: Be aware that transferring an order or return will also create or update the customer or B2B company on it, even with those webhooks off. If you do not want order transfers touching customer or company records, disable those mapping collections — and note that a customer or company that fails to create will also fail the order or return.
14. Temporary API Unavailability
If the Shopware or iPaaS.com API is temporarily unavailable when a transfer is triggered, the transfer fails and an error is recorded in Dashboard / Integration Monitoring / Error Logs. The record can be retried by triggering a new webhook event, using Manual Sync, or triggering a new transfer.
What this means for you: A transfer is not automatically queued for retry when an API is briefly down. Check the Error Logs for the failed record and re-run it through a new webhook event, Manual Sync, or a new transfer once the API is available again.
15. Large Jobs and Throttling
The subscription exposes configurable API throttle and concurrency controls. Subscribers or their MiSP should stagger large manual jobs and rely on the configured throttle limits when transferring many records at once, to avoid overwhelming the Shopware API.
What this means for you: When you need to move a large volume of records, break the work into smaller batches and let the configured throttle and concurrency limits pace the transfers, rather than triggering one very large job that could overwhelm the Shopware API.
Placeholder Values to Replace Before Go-Live
The shipped mapping templates include example, test, and environment-specific values that must be replaced or removed during implementation. The following are flagged across the individual mapping documents:
Payment Method TO iPaaS.com: the PaymentType mapping is a Static example value "Cash" applied to every payment method. Replace it with values appropriate to each payment method, or all transferred payment methods share the same type.
Shipping Method FROM iPaaS.com: the delivery-time lookup uses the example name "1-2 Wochen". Replace it with a delivery time name that exists in the target store, or the transfer fails.
Customer and B2B Company FROM iPaaS.com: example payment method, sales channel, fallback customer group, and fallback language names (for example "Vorkasse", "PayPal", "Food & Beverage", "Snowboard Store", "B2B", "Club Member", "English"), and the example B2B employee static values, must be replaced with values that exist in the target store or removed.
Customer Address FROM iPaaS.com: the hardcoded "US" country ISO code and "US-NY" state short code in the address formulas are examples. Replace them with values driven dynamically from the iPaaS.com address data so each address resolves to its own country and state.
Order Update FROM iPaaS.com: the example shipping-cost statics (unit price, total price, calculated taxes, list price, and discount) are placeholders. Replace them with correct shipping costs or remove the mappings.
Order Delivery FROM iPaaS.com: the default unit-price fallbacks and the arrival-date offset defaults are soft defaults. Replace the unit price with a production value and adjust the date offsets to match fulfillment timelines.
Order Return FROM iPaaS.com: the example return-state name and language, and the static reason content and reason-key values, must be replaced with real values or removed before enabling. (The internal-comment statics ship with sensible defaults — "Return created by iPaaS.com" and "Line return created by iPaaS.com" — which subscribers can keep or customize.)
Catalog Category FROM iPaaS.com: the leftover test custom-field mapping ("Test data from mappings") must be removed or replaced, and the commented-out filter block contains an example top-level category ID that must be replaced with a valid ID from the target store before it is uncommented.
Product family (FROM iPaaS.com): example tax, currency, warehouse-group, sales-channel, and category names and IDs, the SEO URL language identifier, and static example values (such as discount amount, position, and cross-selling type) are placeholders that must be replaced with values that exist in the target store before the collection is enabled.
Across all collections: example custom-field technical names (such as "customer comments" and the various sample custom-field mappings) should be replaced with the technical names of the fields to transfer, or removed if not needed.
Summary
This article documents 15 consolidated limitation sections that apply to the Shopware integration at the time this documentation was written, together with the placeholder values subscribers or their MiSP must replace before go-live. For the detailed technical documentation behind each limitation, consult the individual mapping collection descriptions for the affected entity. Subscribers should validate the affected behaviors in a staging environment before relying on them in production.