Package com.adobe.aco.client

Interface Client

  • All Known Implementing Classes:
    ClientImpl
    public interface Client

    • Method Detail

      • createCategories

        ProcessFeedResponse createCategories​(List<FeedCategory> data)
        Create categories Create new categories with hierarchical structure and slug-based paths. Categories organize products into logical groups and support nested hierarchies. When creating categories: - Each category requires a unique `slug` and `source`. - Use the `slug` field in a hierarchical format like men/clothing/pants' to create parent-child relationships - The category `slug` string can contain only lowercase letters, numbers, and hyphens. - Use the `name` field to define the display name for the category. - Use the optional `families` field to associate categories with product families for enhanced organization. To update existing categories, use the update operation.
        Parameters:
        data - payload of type List
        Returns:
        ProcessFeedResponse indicating the result of the ingestion.
        Throws:
        RuntimeException - if the API request fails

      • deleteCategories

        ProcessFeedResponse deleteCategories​(List<FeedCategoryDelete> data)
        Delete categories Delete categories and all their associated children

        Cascading Deletion

        When you delete a category: * **Child categories**: All child categories in the hierarchy are deleted automatically * **Hierarchy Impact**: The entire branch below the deleted category is removed

        Recovery Options

        If a category is deleted by mistake: * **Time Window**: You have up to one week to restore deleted categories * **Restoration Method**: Recreate the top-level deleted category using the [update operation](#operation/createCategories) * **State Recovery**: Categories are restored to their exact state from the time of deletion, including all metadata, family associations, and hierarchy relationships * **Hierarchy Reconstruction**: The entire hierarchy is rebuilt from the restoration payload
        Parameters:
        data - payload of type List
        Returns:
        ProcessFeedResponse indicating the result of the ingestion.
        Throws:
        RuntimeException - if the API request fails

      • updateCategories

        ProcessFeedResponse updateCategories​(List<FeedCategoryUpdate> data)
        Update categories Update existing product categories with new values. When the update is processed, the merge strategy is used to apply changes to `scalar` and `object` type fields. The replace strategy is used to apply changes for fields in an `array`.
        Parameters:
        data - payload of type List
        Returns:
        ProcessFeedResponse indicating the result of the ingestion.
        Throws:
        RuntimeException - if the API request fails

      • createProductMetadata

        ProcessFeedResponse createProductMetadata​(List<FeedMetadata> data)
        Create product attribute metadata To ensure product data is indexed for discovery, create or replace existing product attribute metadata resources before creating products. For each Commerce project, you must define metadata for the following attributes for each catalog source (`locale`): - `sku` - `name` - `description` - `shortDescription` - `price` Also, you can define metadata for custom attributes. When creating product attribute metadata: - Each product attribute requires a unique `code` and `source`. - Use the `dataType` field to define the data type for the product attribute. - Use the `visibleIn` field to define where the product attribute is displayed on the storefront. - Use the `filterable`, `sortable`, and `searchable` fields to define how the product attribute is used for filtering, sorting, and searching. - Use the `searchWeight` field to define the search weight for the product attribute. - Use the `searchTypes` field to define the search type for the product attribute. To update existing product attribute metadata, use the update operation.
        Parameters:
        data - payload of type List
        Returns:
        ProcessFeedResponse indicating the result of the ingestion.
        Throws:
        RuntimeException - if the API request fails

      • deleteProductMetadata

        ProcessFeedResponse deleteProductMetadata​(List<FeedMetadataDelete> data)
        Delete product attributes metadata Remove product attribute metadata resources from the catalog data.
        Parameters:
        data - payload of type List
        Returns:
        ProcessFeedResponse indicating the result of the ingestion.
        Throws:
        RuntimeException - if the API request fails

      • updateProductMetadata

        ProcessFeedResponse updateProductMetadata​(List<FeedMetadataUpdate> data)
        Update product attribute metadata Update existing product attribute metadata with new values. When the update is processed, the merge strategy is used to apply changes to `scalar` and `object` type fields. The replace strategy is used to apply changes for fields in an `array`.
        Parameters:
        data - payload of type List
        Returns:
        ProcessFeedResponse indicating the result of the ingestion.
        Throws:
        RuntimeException - if the API request fails

      • createPriceBooks

        ProcessFeedResponse createPriceBooks​(List<FeedPricebook> data)
        Create price books Create or replace existing price books with support for hierarchical pricing structures.

        Creating Base Price Books

        Base price books are the foundation of your pricing hierarchy: * **Required Fields**: `priceBookId`, `name`, `currency` * **Currency Definition**: Sets the currency for the entire branch of child price books * **No Parent**: Base price books cannot reference a parent price book * **Unique ID**: Must have a unique `priceBookId` across all price books

        Creating Child Price Books

        Child price books inherit from their parent and can extend the hierarchy: * **Required Fields**: `priceBookId`, `name`, `parentId` * **Parent Reference**: Must reference an existing parent price book * **Currency Inheritance**: Automatically inherits currency from parent * **Hierarchy Depth**: Can create up to 3 levels of nesting

        Hierarchy Management

        * **Parent Assignment**: Once a `parentId` is assigned, it cannot be changed via update operations * **Restructuring**: To change parent-child relationships, delete and recreate the child price book * **Validation**: The system validates parent references and hierarchy depth limits Use the [update price books operation](#operation/updatePriceBooks) to modify existing price book names or base price book currencies.
        Parameters:
        data - payload of type List
        Returns:
        ProcessFeedResponse indicating the result of the ingestion.
        Throws:
        RuntimeException - if the API request fails

      • deletePriceBooks

        ProcessFeedResponse deletePriceBooks​(List<FeedPriceBookDelete> data)
        Delete price books Delete price books and their associated pricing data with cascading effects on the hierarchy.

        Cascading Deletion

        When you delete a price book: * **Child Price Books**: All child price books in the hierarchy are automatically deleted * **Associated Prices**: All prices assigned to the deleted price book and its children are removed * **Hierarchy Impact**: The entire branch below the deleted price book is removed

        Deletion Scenarios

        * **Base Price Book**: Deletes entire pricing hierarchy and all associated prices * **Child Price Book**: Deletes the specific price book and its children, but preserves sibling price books * **Leaf Price Book**: Deletes only the specified price book and its associated prices

        Recovery Options

        If a price book is deleted by mistake: * **Time Window**: You have up to one week to restore deleted price books * **Restoration Method**: Recreate the top-level parent price book using the original create payload * **State Recovery**: Price books and prices are restored to their state when deleted * **Hierarchy Reconstruction**: The entire hierarchy is rebuilt from the restoration payload

        Best Practices

        * **Backup Strategy**: Keep copies of price book configurations for recovery * **Validation**: Verify hierarchy structure before deletion * **Impact Assessment**: Review associated prices before deleting price books
        Parameters:
        data - payload of type List
        Returns:
        ProcessFeedResponse indicating the result of the ingestion.
        Throws:
        RuntimeException - if the API request fails

      • updatePriceBooks

        ProcessFeedResponse updatePriceBooks​(List<FeedPricebook> data)
        Update price books Update existing price books with limitations on hierarchical changes.

        Updatable Fields

        * **Name**: Can be updated for both base and child price books * **Currency**: Can only be updated for base price books (affects entire hierarchy) * **Parent ID**: Cannot be updated - use delete and recreate to change hierarchy

        Update Restrictions

        * **Parent Assignment**: Cannot change `parentId` via update operations * **Hierarchy Changes**: To restructure the hierarchy, delete and recreate child price books * **Currency Inheritance**: Child price books automatically inherit currency changes from parent * **Validation**: System validates that `parentId` references exist and hierarchy depth is maintained

        Update Strategies

        * **Base Price Books**: Update name and currency as needed * **Child Price Books**: Include correct `parentId` in request (will be ignored if different) * **Hierarchy Restructuring**: Delete child price book and recreate with new parent reference
        Parameters:
        data - payload of type List
        Returns:
        ProcessFeedResponse indicating the result of the ingestion.
        Throws:
        RuntimeException - if the API request fails

      • createPrices

        ProcessFeedResponse createPrices​(List<FeedPrices> data)
        Create prices Create or replace existing product prices with support for regular pricing, discounts, and tiered pricing.

        Pricing structure

        Each price record can include: * **Regular Price** - The base price for the product SKU * **Discounts** - Percentage or fixed amount discounts applied to the regular price * **Tiered Pricing** - Quantity-based pricing for bulk purchases

        Discount configuration

        Discounts can be configured in two ways: * **Fixed Amount Discounts** - Use `price` field to specify a fixed discount amount (e.g., 10.00 for $10 off) * **Percentage Discounts** - Use `percentage` field to specify a discount percentage (e.g., 20 for 20% off) Each discount requires a unique `code` identifier to distinguish between different discount types.

        Tiered pricing

        Tiered pricing offers different prices based on purchase quantity: * **Tier Fixed Prices** - Use `price` field with `qty` to specify quantity-based fixed prices * **Tier Percentage Discounts** - Use `percentage` field with `qty` to specify quantity-based percentage discounts Tier quantities must be greater than 1.

        Pricing for configurable products

        Because configurable product price is calculated based on the price of the selected product variant, you don't need to send the price data for configurable product SKUs. Sending price data for these SKUs can cause incorrect price calculations.
        Parameters:
        data - payload of type List
        Returns:
        ProcessFeedResponse indicating the result of the ingestion.
        Throws:
        RuntimeException - if the API request fails

      • deletePrices

        ProcessFeedResponse deletePrices​(List<FeedPricesDelete> data)
        Delete prices Delete existing product prices
        Parameters:
        data - payload of type List
        Returns:
        ProcessFeedResponse indicating the result of the ingestion.
        Throws:
        RuntimeException - if the API request fails

      • updatePrices

        ProcessFeedResponse updatePrices​(List<FeedPricesUpdate> data)
        Update prices Change existing product prices, discounts, and tiered pricing. When the update is processed, the merge strategy is used to apply changes to `scalar` and `object` type fields. For `array` type fields, a new value can be appended to the existing list. For an object list, you can update a specific object by matching on a key field. The following fields are supported: * `discounts` - match on `code` * `tierPrices` - match on `qty`

        Update strategies

        * **Regular Price** - Updated using merge strategy * **Discounts Array** - Updated using the append or merge strategy * **Tiered Pricing Array** - Updated using the append or merge strategy

        Discount and tier pricing updates

        When updating discounts or tiered pricing: * Include all desired discounts/tiers in the array * The entire array replaces the existing configuration * To remove all discounts/tiers, send an empty array * To add new discounts/tiers, include both existing and new items

        Best practices

        * Always include the complete array of discounts/tiers when updating * Use descriptive discount codes for easier management * Ensure tier quantities are in ascending order * Test updates in a development environment first
        Parameters:
        data - payload of type List
        Returns:
        ProcessFeedResponse indicating the result of the ingestion.
        Throws:
        RuntimeException - if the API request fails

      • createProducts

        ProcessFeedResponse createProducts​(List<FeedProduct> data)
        Create or replace products You can create different types of products, such as simple products and configurable products. When creating products: - Each product requires a unique SKU identifier. - Products must have a defined catalog source, for example `locale`. - Add values for the required `name`, `slug`, and `status` fields. - Define optional fields such as descriptions, images, and custom attributes as needed. - Use the `links` field to define relationships between products, such as linking a product variant to its parent configurable product. - You can create multiple products in a single request, and also create product variants for configurable products in the same request.

        Simple products

        Create products or replace existing products with specified `sku` and `source` values. Use the [update operation](#operation/updateProducts) to modify values for an existing product.

        Configurable products

        A configurable product is a parent product that allows customers to select from multiple predefined attributes such as color, size, and material. Each unique combination of these attribute values (for example, `color=green`, `size=large`) represents a product variant. Each variant is treated as a distinct child product with its own SKU, price, and inventory. These variants are stored as separate entities in the database and linked to the parent configurable product. The configurable product itself acts as a container or abstraction layer, enabling a unified frontend experience while maintaining granular control over each variant on the backend. To create a configurable product, you need the following: * Product attributes—Create product attributes (for example, \"color\", \"size\") that will be used to differentiate product variants. These attributes must be registered in the system before they can be referenced in product definitions. * Configurable product—Define the parent product and include a [configurations](#operation/createProducts!path=configurations&t=request) array that specifies the selectable options and maps each option to a set of possible values. Each value must include a [variantReferenceId](#operation/createProducts!path=configurations/values/variantReferenceId&t=request), which links to a specific variant. * Product variants—Define a product variant for each valid combination of attribute values. Each variant must: * Include relevant attribute values in an [attributes](#operation/createProducts!path=attributes&t=request) array. * Reference the parent configurable product using variantReferenceId. * Include a [links](#operation/createProducts!path=links&t=request) array with a link of type `VARIANT_OF` pointing to the configurable product. For example: 
            {     \"sku\": \"pants-red-32\",     \"attributes\": [       {         \"code\": \"color\",         \"values\": [\"Red\"],         \"variantReferenceId\": \"pants-color-red\"       }     ],     \"links\": [       {         \"type\": \"VARIANT_OF\",         \"sku\": \"pants\"       }     ]   }
        Each product variant links back to the configurable product through its `variantReferenceId`, which corresponds to specific `configurations[].values[].variantReferenceId` in the configurable product. To unassign a product variant from a configurable product, do one of the following: - Use [Delete Product API](#operation/deleteProducts) to delete the product variant. - Use [Update Product API](#operation/updateProducts) to set the [\"variantReferenceId\"](#operation/createProducts!path=attributes/variantReferenceId&t=request) to `null` and unassign the product variant from the configurable product by removing the [\"links\"](#operation/createProducts!path=links&t=request) association.

        Bundle products

        A bundle product combines several simple products into one sellable unit. Items within the bundle can be categorized into logical groups like `tops`, `bottoms`, and `accessories`. Each group can have multiple items, and shoppers can select items from each group to create a customized bundle. To create a bundle product, you need the following: * Bundle product—[Define the parent product](#operation/createProducts) and include a [bundles](#operation/createProducts!path=bundles) array that specifies the groups and items included in the bundle. Each group must define: * `group` - Name of the group (for example, \"tops\", \"bottoms\") * `required` - Whether a selection from this group is mandatory * `multiSelect` - Whether multiple items can be selected * `items` - List of products that can be selected from this group * Simple products—Define each simple product to include in the bundle. Each product must: * Include a [links](#operation/createProducts!path=links) array with a link of type `IN_BUNDLE` pointing to the bundle product * Be created separately using the [create product API](#operation/createProducts) Note: A simple product can be included only once in each bundle. If the same item is specified in multiple groups, the API returns a `Duplicate SKU found in bundle items` error. To update a bundle product, do one of the following: * Use the [Update products API](#operation/updateProducts) to modify the groups and items in the bundle * Use the [Delete products API](#operation/deleteProducts) to remove items from the bundle
        Parameters:
        data - payload of type List
        Returns:
        ProcessFeedResponse indicating the result of the ingestion.
        Throws:
        RuntimeException - if the API request fails

      • deleteProducts

        ProcessFeedResponse deleteProducts​(List<FeedProductDelete> data)
        Delete products Delete products with specified `sku`` and `source`` values
        Parameters:
        data - payload of type List
        Returns:
        ProcessFeedResponse indicating the result of the ingestion.
        Throws:
        RuntimeException - if the API request fails

      • updateProducts

        ProcessFeedResponse updateProducts​(List<FeedProductUpdate> data)
        Update products Update products with specified `sku` and `source` values to replace existing field data with the data supplied in the request. When the update is processed, the merge strategy is used to apply changes to `scalar` and `object` type fields. For `array` type fields, a new value can be appended to the existing list. For an object list, you can update a specific object by matching on a key field. The following fields are supported: * `attributes` - match on `code` * `images` - match on `url` * `routes` - match on `path` * `links` - match on `type` and `sku` * `bundles` match on `type` and `group` * `configurations` match on `type` and `attributeCode` * `externalIds` match on `type` and `origin`
        Parameters:
        data - payload of type List
        Returns:
        ProcessFeedResponse indicating the result of the ingestion.
        Throws:
        RuntimeException - if the API request fails