Use the Bulk Product Upload (BPU) process to add, update, or remove multiple products or product combinations. The BPU process creates categories based on the provided category path. The BPU process is an inbound event.
The BPU uses the Bulk Import to add, update, or remove products.
Bulk import XML file
The following example shows the smallest possible Bulk Import XML file:
Note: BPU is non-interactive. When the BPU process finishes, there is no required notification response. When the BPU process finishes, the presence of a BulkImportResponse file indicates the bulk file upload has finished.
When using Bulk Import to import categories, consider the following tips:
Ensure all categories are listed in the file before products. Follow the sequence in the schema.
A category path cannot be empty.
Define the loaderType to Add or Update the category, if the noOverwriteIfEmptyData flag is not set.
If you run an incremental upload and the category action is REMOVE, then categories with subcategories or products in a predeployed state will not be deleted.
If you run a full catalog upload, all categories that are not in the import file will be removed.
Bulk import response XML file
The BPU Import process creates the Bulk Import Response file after the Bulk Import process completes. The Bulk Import Response file reports when the BPU Import process successfully adds, updates, or retires a product. If an error occurs during the import, The BPU Import process adds the error and stackTrace elements to provide more information.
The BPU process uses externalReferenceId to identify products. It frees clients from the need to consume and store Digital River product IDs. When using this field to identify products, ensure the externalReferenceId is unique across the product-owning company.
locale in prices
The locale in the price node is not tied to the locale of the enclosing product node. To use locale-specific prices, specify the locale at the price level.
noOverwriteIfEmpty
This value should be set to true. Setting this value to false can result in undesired side effects.
productConfigType
While appearing in the schema, this complex type is not consumed by the BPU process. It does not affect the BPU process when you include it in the XML.
retiring products
The “remove” action for products works slightly differently for products with multiple locales than those with a single locale. For products with multiple locales, “remove” deletes that locale from the product. If only a single locale exists, the “remove” action will retire the product.
Schemas
Version
Schema Components Table
Raw Schema
Sample XML
7 (Current)
Not available
6
5
Product association feed
Use the Product Association Feed to add, modify, or remove product associations. Product Associations allow users to associate one product with one or more other products. The Product Associations framework is generic.
The Product Association Feed is a webhook event.
Details
The Product Association Feed Integration is the automated mechanism through which Digital River adds, modifies, and deletes product associations in an Association Group.
The following list describes when you cannot create an association.
The owning product is not deployed. You can only create associations (via the feed) when the owning product is deployed.
The associated product is not deployed. You can only create an association group when the product you want to associate with the owning product is deployed.
The locale of the owning product in the feed is not a valid locale for that product.
Note: If you create an association group that includes deployed products in the association, the created association group will not include the undeployed products. The locale for the owning product in the feed is not a valid locale for that product.
The following table describes the request and response types for exporting and importing product association details.
Task
Request Type
Response Type
View the existing product association details by exporting the product association details
ProductAssociationFeedExportRequest
ProductAssociationFeedExportResponse
View the existing product association details by exporting the product association details
ProductAssociationFeedImportRequest
ProductAssociationFeedImportResponse
A Product Association Type defines the behavior of a specific type of product association. The behavior defined by the type includes but may not be limited to the following:
Enforcement of cardinality between parent and child products.
Example: one-to-one (1:1) or one-to-many (1:M)
State-dependent behavior, including whether you can:
Display the association on a shopper site
Add the products to the association
Modify the association name
State transition rules
Each Product Association Type is associated with a collection of one or more Categories specific to that type. The Categories are company-specific, and you must create them before you create specific Product Associations.
Example: Categories you could create for a Related Items Type include "Related Trial Ware" and "Related Products".
Each Category appears as a separate panel or container in an administrator interface. Associations of that Type and Category will be managed entirely within that panel.
Also, the Product Association Type and Category combine to allow site designers to display certain association Groups at certain locations on the shopper site.
A Product Association Group defines a relationship between a single Parent Product and a collection of Child Products. The Group links the Parent Product with the Child Products. Also, the Group inherits behavior defined by the Product Association Type and, to a lesser extent, by the Category within that type. Groups can be sorted within a Category.
You can give the Product Association Group a localized Group Name. When you create a localized Group Name, you must:
Associate each Group Name with a specific Locale.
Define one Group Name as the default.
You can add additional Group Names for other locales. A Client may ask for the name of a Group by Locale. If a localized name matches the Locale in the request, that name is provided; otherwise, the default name is provided. Group Name may be optional for some Product Association Types.
The Parent Product is the Key Product in an Association Group. It drives the maintenance and display of Product Associations. You cannot remove a Parent Product from a Group.
A Group contains a collection of Associated Products in relative sort order. You can add or remove Associated Products from a Group if its state allows it.
The Product Association Tag is a display API that provides Product Association Group information that you can use in shopper-side views.
You can send a productAssociationFeedImportRequest and expect a productAssociationFeedImportResponse in real-time.
You can send a productAssociationFeedImportRequest and expect a productAssociationFeedImportResponse at a later point.
The following example shows the request and response for adding an Associated Product and Associations.
The Action Result denotes whether or no the action succeeded. The possible results are as follows:
SUCCESSFUL
FAILED
If the request failed, the following table describes the possible response codes associated with the failure:
Response Code
Error Name
Message
100
ERR_INVALID_ACTION
Unrecognized action. The association group was not created.
110
ERR_NO_GROUP_FOUND
The product does not contain an association.
120
ERR_INVALID_CATEGORY
The company has no category, and Product Association was not created (updated or deleted).
130
ERR_ASSOCIATION_PARTIAL
Association was created, but errors occurred.
140
ERR_NOT_CREATED
Errors occurred, the association was not created.
200
ERR_GROUPDATA_ADD
Error in adding groupData.
210
ERR_NO_GROUPDATA_FOUND
The association does not contain locale.
220
ERR_GROUP_NOT_EDITABLE
Association cannot be modified: Group is not tied to the latest parent version.
230
ERR_NO_MODIFICATION
Errors occurred, the association was not modified.
300
ERR_CHILD_ADD
Could not add the associated product: product could not be found.
310
ERR_NO_CHILD_FOUND
Association does not contain a child product.
320
ERR_INVALID_CHILD
The child product can not be found. The child was not removed/updated.
400
ERR_INVALID_PARENT
Parent product can not be found. Product Association was not added/modified/deleted.
Schemas
Version
Schema Components Table
Raw Schema
Sample XML
1 (Current)
Channel bulk loader
Use the Channel Bulk Loader to import company information, payment details, channel contract agreement details, and other product information.
The Channel Bulk Loader process imports products, companies, contracts, payment disbursement, pricing, and other objects necessary to sell products in the marketStream business model of Digital River.
You can use the Channel Bulk Loader to add, update, or remove companies, products, and payment disbursement.
The following example shows additional company attributes. These attributes indicate the product owner's channel contract acceptance date and email address.
Use the Order Create API to submit an order to Digital River for fulfillment. The business process uses XML and HTTPS since the APIs are real-time.
Details
After you import the product catalog into the client’s eCommerce system, you can enable the order to create a business process. For this business process, the client will process the following items implemented via their eCommerce solution:
The transaction performing payment authorization
The fraud check
Other client-specific transaction processing functions
After processing these items, the client knows the customer, and the order is acceptable. The client then uses the Order Create API to submit the order to Digital River for fulfillment. For a digital product, this fulfillment information consists of a Digital River-hosted download URL that the client delivers to the customer who placed the order. The customer uses this URL to download the product they purchased. Sometimes, products require a serial number or unlock code and the download URL so the customer can install the product properly. In this case, the Order Create business process returns this information to the client, and the client displays the information to the client on the customer service interface and sends the information in an email notification to the customer.
The business process uses XML and HTTPS since the APIs are real-time. Clients should consider coding in a timing feature so that, in the very rare case where the call to the Digital River servers takes over 10 seconds or so, they return a page to the customer that says they will send the information the customer requires to get the product they purchased later.
The following table shows the business process specifics.
Characteristics
Specification
Business process type
Real-Time
Communication protocols
HTTPS
Available data formats
XML
The following diagram shows an overview of the Order Create business process.
Multiple orders per request are not supported at this time.
Suppose the Client inadvertently submits the same order twice (the same external order ID and line items). In that case, Digital River will accept the request and return the same information via the Order Create Response that it did in the previous order submissions. If one or more line items have pending digital rights, Digital River will try to obtain the digital rights before sending the response.
Occasionally, Digital River deactivates products as part of product catalog maintenance. If Digital River deactivates a product that appears in a Client's catalog, the return response contains an error code.
When Digital River receives a fulfillment request, Digital River provides an immediate response to this call. This response's XML format follows a specific XML schema.
The following table shows the values for status return codes. There are two types of return codes:
Return code for the order fulfillment itself
Return code for each line item quantity unit in the order
For unsuccessful orders with multiple products, the line item order status allows the client to pinpoint the product in the order that caused the failure. Line items in pending status will be resubmitted every hour for up to 30 days.
Requirement: The client is responsible for resubmitting 202/503 status code combinations to verify the order fulfillment status.
Code Types
Codes
Order Status Codes
201 - Success: All line item units completely fulfilled
202 - Partial success: Order was valid, but some line items could not currently be fulfilled
400 - Bad request: The server could not understand the request due to malformed syntax
401 - Unauthorized: See Error! Reference source not found.
409 - Unfulfillable: One or more the line items cannot be fulfilled. Details are provided in corresponding line item status codes (404)
500 - Temporary service outage: Retry later (we could set a Retry-After header)
Line Item Status Codes
201 - Success: The unit will contain licenses, actualPrice, and downloadUrl
404 - Not Found: The requested product is permanently unavailable.
503 - Unavailable: Not all of the licenses could be generated at this time, but some will become available in the future. The fulfillment/status/code will be 202.
The following example shows a return response for the example order request provided earlier in the document. The earlier request contained two copies of the same product. This fulfillment response shows a license and an unlock code for the first product and a pending digital rights response for the second product.
Note: Each line item quantity has a fulfillment unit.
Use the Order Return API when a client needs to reverse a customer's order due to a customer service issue. The business process uses XML and HTTPS since the APIs are real-time.
Details
You can use the Order Return API to reverse the transaction on the Digital River-side. The Order Return API notifies Digital River to disable the customer's download URL.
Note: If you send an order that previously resulted in a 202/503 error, Digital River will submit an order cancellation.
The Order Return business process works similarly to the Order Create business process in that it leverages XML and HTTPS and has a request and response message-passing sequence.
The following table shows the business process specifics.
Characteristic
Specification
Business process type
Real-Time
Communication protocols
HTTPS only
Available data formats
XML
The XML format for the Order Return's response follows a specific XML schema provided in the Order Return schemas. The following example shows the order return responses sent to a client.
<?xml version="1.0" encoding="UTF-8"?>
<ns1:returnReceipt
returnRequestUri="http://dealer.acme.com/order/1636395390/1”
uri=" https://drh1sys.digitalriver.com/integration/job
/request/DRRWS?r=returnLiID/4562889"
xmlns:rws="http://integration.digitalriver.com/2005/10/RetailWebService"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance>
<status>
<code>201</code>
<message>The return unit request has been submitted successfully.</message>
</status>
</ns1:returnReceipt>
<?xml version="1.0" encoding="UTF-8"?>
<ns1:returnReceipt
returnRequestUri="http://dealer.acme.com/order/1636395390/1”
uri=" https://drh1sys.digitalriver.com/integration/job/request
/DRRWS?r=unit/6353179490-0"
xmlns:rws="http://integration.digitalriver.com/2005/10/RetailWebService"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance>
<status>
<code>201</code>
<message>The return unit request has been submitted successfully.</message>
</status>
</ns1:returnReceipt>
