Shopwre Installation Instructions

Client Credentials Grant: This method is ideal for machine-to-machine communication. It uses a client ID and a client secret to generate an access token. The token is valid for 10 minutes and must be regenerated with the same request after it expires. This method does not generate a refresh token.

Resource Owner Password: This method is commonly used by the admin panel and requires a username and password. The access token is also valid for 10 minutes but includes a refresh token. This allows for continuous access by regenerating the token with the refresh token after the initial 10 minutes, without needing the username and password again.

Base URL: Must match the instance the client wants to interact with.

Grant Type: Set to client_credentials for the Client Credentials Grant method or password for the Resource Owner Password method.

Credentials:

Enter the Grant Type for your subscription, either client_credentials or password. See Before You Begin for more information.

Enter the ClientID and ClientSecret you retrieved from the Shopware Admin panel.

Enter your ShopwareUsername and Password.

Enter values for the following fields.

Transfer Category: If enabled, product categories will be transferred as a prerequisite of product transfers when a product category assignment is detected, and the product transfer will error if the product category cannot be created or found. When disabled, product categories will not be processed as a prerequisite of product transfers to Shopware.

Additional Error Hide: This preset controls whether additional properties from the

error response are included in the error log. When set to false, all extra properties from the error response will be logged along with the standard error details. When set to true, only the default error information will be recorded, and any additional properties will be excluded from the log.

Product Content Processing:
Controls whether product content is preprocessed and transformed before being stored or published in the system.

Product Category Duplicate Checking By: The ProdCategoryDuplicateCheckingBy preset defines which field is used to identify duplicate product categories. It supports matching by name, description, or a custom field specified dynamically per client. If set to "name", the system checks for duplicates based on the category name; if set to "description", it uses the category description; and if a custom field name is provided, the system retrieves the value of that field for duplicate detection. This field specifies the iPaaS.com field name used for duplication checks in product categories.

Product Category Duplicate Matching By: The ProdCategoryDuplicateMatchingBy preset defines the field in Shopware that is used to align and match product categories with iPaaS.com records. It works in conjunction with the ProdCategoryDuplicateCheckingBy preset, which specifies the iPaaS.com field used for duplicate detection. The value of the field defined in ProdCategoryDuplicateCheckingBy is matched against the corresponding Shopware field specified in ProdCategoryDuplicateMatchingBy. By default, matching is performed using the category name if not explicitly defined. Together, these presets enable flexible, client-specific control over how product categories are compared and synchronized between systems, supporting both standard and custom field-based matching logic.

Transfer Kits Using API Extension:
The Transfer Kits Using API Extension setting controls how product kits (bundled items) are transferred between systems. When enabled (true), the system uses the /api/bundle/upsert endpoint from the API extension to transfer kits as structured bundles. This approach allows for more flexible and accurate handling of bundled products, including the ability to define component relationships, quantities, and pricing within a single bundle entity. When disabled (false) or not set, the system defaults to using the standard /api/product-cross-selling endpoint to transfer kit components instead. In this case, each kit component is processed as a cross-selling relationship rather than a bundle, which is suitable for environments that do not support the bundle API extension. Enabling this option ensures that product kits retain their hierarchical structure and intended configuration during synchronization, while disabling it maintains compatibility with systems relying on standard cross-selling relationships.

Property Group Match Fields & Property Group Option Match Field: These settings define how product properties and their options are matched and aligned during synchronization between systems. They are used when handling product option groups (e.g., CBD Strength) and product option values (e.g., 100 mg, 200 mg, etc.) to ensure correct linkage and grouping.

Transaction Poll Search Days: The Transaction Poll Search Days setting defines how many days back the system looks when searching for new transactions. This setting is only applied during the initial polling process or when the last poll date is empty or unavailable. In such cases, the system uses the specified number of days to determine the historical range for fetching transactions. For example, if set to 7, the system will look back seven days from the current date to retrieve transactions. After the first successful poll, subsequent runs will only fetch transactions created or updated since the last recorded poll date, ensuring efficient and incremental synchronization.

Order Status Post Transaction Add: Sets the order status that's applied after a transaction is successfully added.
​Example: Pending, Active etc.

Do Not Update Order Delivery Statuses: The Do Not Update Order Delivery Statuses setting prevents the system from automatically updating order delivery statuses that match any of the specified values. When configured, any delivery whose current status matches one of the defined statuses (e.g., Pending, Active, etc.) will be excluded from automatic status updates during synchronization or processing. This ensures that certain orders remain in their existing state and are not modified by automated workflows, allowing users to maintain control over deliveries that require manual management or special handling.

Do Not Update Order Payment Statuses: The Do Not Update Order Payment Statuses setting prevents the system from automatically updating order payment statuses that match any of the specified values. When configured, any order whose current payment status matches one of the defined statuses (e.g., Pending, Active, etc.) will be excluded from automatic payment status updates during synchronization or processing. This ensures that orders in specific payment states remain unchanged, allowing for manual review, exception handling, or custom business workflows without interference from automated updates.

Tracking Update Default Delivery: The Tracking Update Default Delivery setting controls how tracking information is applied to order deliveries in Shopware. When enabled (true), transaction tracking records transferred from iPaaS.com are automatically assigned to the first or default delivery associated with the order. As a result, the Shopware UI will display tracking information only for that first/default delivery, even in cases where multiple delivery records exist for the same order. When disabled (false), tracking updates are not automatically assigned to the default delivery, allowing for more granular or manual control of tracking data across multiple deliveries. This setting ensures consistent handling of tracking information, especially in environments where only the primary delivery record is visible in the Shopware interface.

Returns Core or Proxy API: The Returns Core or Proxy API setting determines which API endpoint is used to process return transactions transferred from iPaaS.com. When set to proxy, the system uses the Proxy API to create returns through the endpoint POST /api/_proxy/order/{orderId}/return, which provides extended flexibility and supports additional business logic for handling order returns. When set to core, the system instead uses the Core API endpoint POST /api/order-return to create standard return records directly in Shopware. This preset allows administrators to choose between using the native Shopware return flow (Core API) or the enhanced proxy-based method (Proxy API) depending on their integration and functional requirements.

Company Addresses as Subsidiaries: The Company Addresses as Subsidiaries setting controls how company and address data are transferred from Shopware to iPaaS.com. When enabled (true), each Shopware company address is treated as a separate subsidiary company in iPaaS.com. During transfer, the system creates an individual Company record in iPaaS.com for each address, along with the appropriate Company Relationship records that link these subsidiaries back to the primary (parent) company. This allows each address to be managed independently while maintaining a structured relationship hierarchy. When disabled (false), the default behavior is applied — a single Company record is created in iPaaS.com with multiple associated addresses, preserving the standard one-to-many relationship between a company and its addresses without generating separate subsidiary entities.

Translations Enabled: When enabled, the Translations Enabled setting ensures that custom fields defined for language specific values (such as marketing text, descriptions, or custom field values) are processed according to the custom field naming convention and language–specific requirements. This feature supports cases where Product, Product Variant, Product Option, Product Option Value, or Product Category content must be differentiated for multiple languages, based on user-defined custom field names that follow a structured naming convention.

Index Behavior Header: The Index Behavior Header preset controls how the system updates its search and listing index after changes like product or category updates. It helps improve performance during data syncs or bulk imports by allowing you to delay indexing until all updates are complete. This ensures faster processing and avoids unnecessary system load. If indexing is skipped, you can trigger it manually later to reflect changes on the storefront. Using a preset value helps keep this behavior consistent across your integrations.
​Example: "use-indexing-queue"

Transfer Category: If enabled, product categories will be transferred as a prerequisite of product transfers when a product category assignment is detected, and the product transfer will error if the product category cannot be created or found. When disabled, product categories will not be processed as a prerequisite of product transfers to Shopware.

Additional Error Hide: This preset controls whether additional properties from the error response are included in the error log. When set to false, all extra properties from the error response will be logged along with the standard error details. When set to true, only the default error information will be recorded, and any additional properties will be excluded from the log.

Product Content Processing:Controls whether product content is preprocessed and transformed before being stored or published in the system.

Product Category Duplicate Matching By: The ProdCategoryDuplicateMatchingBy preset defines the field in Shopware that is used to align and match product categories with records. It works in conjunction with the ProdCategoryDuplicateCheckingBy preset, which specifies the iPaaS.com field used for duplicate detection. The value of the field defined in ProdCategoryDuplicateCheckingBy is matched against the corresponding Shopware field specified in ProdCategoryDuplicateMatchingBy. By default, matching is performed using the category name if not explicitly defined. Together, these presets enable flexible, client-specific control over how product categories are compared and synchronized between systems, supporting both standard and custom field-based matching logic.

Transfer Kits Using API Extension: The Transfer Kits Using API Extension setting controls how product kits (bundled items) are transferred between systems. When enabled (true), the system uses the /api/bundle/upsert endpoint from the API extension to transfer kits as structured bundles. This approach allows for more flexible and accurate handling of bundled products, including the ability to define component relationships, quantities, and pricing within a single bundle entity. When disabled (false) or not set, the system defaults to using the standard /api/product-cross-selling endpoint to transfer kit components instead. In this case, each kit component is processed as a cross-selling relationship rather than a bundle, which is suitable for environments that do not support the bundle API extension. Enabling this option ensures that product kits retain their hierarchical structure and intended configuration during synchronization, while disabling it maintains compatibility with systems relying on standard cross-selling relationships

Transaction Poll Search Days: The Transaction Poll Search Days setting defines how many days back the system looks when searching for new transactions. This setting is only applied during the initial polling process or when the last poll date is empty or unavailable. In such cases, the system uses the specified number of days to determine the historical range for fetching transactions. For example, if set to 7, the system will look back seven days from the current date to retrieve transactions. After the first successful poll, subsequent runs will only fetch transactions created or updated since the last recorded poll date, ensuring efficient and incremental synchronization.

Order Status Post Transaction Add: Sets the order status that's applied after a transaction is successfully added. For example, Pending, Active etc.

Do Not Update Order Delivery Statuses:The Do Not Update Order Delivery Statuses setting prevents the system from automatically updating order delivery statuses that match any of the specified values. When configured, any delivery whose current status matches one of the defined statuses (e.g., Pending, Active, etc.) will be excluded from automatic status updates during synchronization or processing. This ensures that certain orders remain in their existing state and are not modified by automated workflows, allowing users to maintain control over deliveries that require manual management or special handling.

Do Not Update Order Payment Statuses: The Do Not Update Order Payment Statuses setting prevents the system from automatically updating order payment statuses that match any of the specified values. When configured, any order whose current payment status matches one of the defined statuses (e.g., Pending, Active, etc.) will be excluded from automatic payment status updates during synchronization or processing. This ensures that orders in specific payment states remain unchanged, allowing for manual review, exception handling, or custom business workflows without interference from automated updates.

Tracking Update Default Delivery: The Tracking Update Default Delivery setting controls how tracking information is applied to order deliveries in Shopware. When enabled (true), transaction tracking records transferred from iPaaS.com are automatically assigned to the first or default delivery associated with the order. As a result, the Shopware UI will display tracking information only for that first/default delivery, even in cases where multiple delivery records exist for the same order. When disabled (false), tracking updates are not automatically assigned to the default delivery, allowing for more granular or manual control of tracking data across multiple deliveries. This setting ensures consistent handling of tracking information, especially in environments where only the primary delivery record is visible in the Shopware interface.

Returns Core or Proxy API: The Returns Core or Proxy API setting determines which API endpoint is used to process return transactions transferred from iPaaS.com. When set to proxy, the system uses the Proxy API to create returns through the endpoint POST /api/_proxy/order/{orderId}/return, which provides extended flexibility and supports additional business logic for handling order returns. When set to core, the system instead uses the Core API endpoint POST /api/order-return to create standard return records directly in Shopware. This preset allows administrators to choose between using the native Shopware return flow (Core API) or the enhanced proxy-based method (Proxy API) depending on their integration and functional requirements.

Company Addresses as Subsidiaries:The Company Addresses as Subsidiaries setting controls how company and address data are transferred from Shopware to iPaaS.com. When enabled (true), each Shopware company address is treated as a separate subsidiary company in iPaaS.com. During transfer, the system creates an individual Company record in iPaaS.com for each address, along with the appropriate Company Relationship records that link these subsidiaries back to the primary (parent) company. This allows each address to be managed independently while maintaining a structured relationship hierarchy. When disabled (false), the default behavior is applied — a single Company record is created in iPaaS.com with multiple associated addresses, preserving the standard one-to-many relationship between a company and its addresses without generating separate subsidiary entities.

Translations Enabled: When enabled, the Translations Enabled setting ensures that custom fields defined for language specific values (such as marketing text, descriptions, or custom field values) are processed according to the custom field naming convention and language–specific requirements. This feature supports cases where Product, Product Variant, Product Option, Product Option Value, or Product Category content must be differentiated for multiple languages, based on user-defined custom field names that follow a structured naming convention.

Index Behavior Header: The Index Behavior Header preset controls how the system updates its search and listing index after changes like product or category updates. It helps improve performance during data syncs or bulk imports by allowing you to delay indexing until all updates are complete. This ensures faster processing and avoids unnecessary system load. If indexing is skipped, you can trigger it manually later to reflect changes on the storefront. Using a preset value helps keep this behavior consistent across your integrations.

Documentation: API Introduction

Support Portal: https://support.ipaas.com/en/

Contact Information: Contact iPaaS.com