Getting Started

This page describes the fundamental knowledge that you need in order to use the Displayable Content Export (DCE).

DCE HTTP Service and DCE data sets

The DCE differs from a traditional "REST" style API in that it consists of two distinct components which are described below:

DCE HTTP service
The DCE HTTP service refers to the HTTP interface that is used to interact with the DCE. Requests to the DCE HTTP service will return 302 redirects to precomputed UGC data files, instead of dynamically calculated resources.

DCE data sets
The DCE data sets are the UGC data files returned by the DCE. Unlike a traditional "REST" style API, these data sets are pre-calculated on a regular basis.

This hybrid architecture allows for speed at the cost of some flexibility. For example, we encourage you to perform multiple concurrent requests to the DCE HTTP service. However, the DCE does not offer filters or sorting options common to "REST" style APIs, because the data sets consist of pre-computed files.


The DCE supports the following environments:

Staginghttps://stg.api.bazaarvoice.comUsed while developing your application. The data in staging is not derived from real end-users.
Productionhttps://api.bazaarvoice.comUsed when your application is complete. The data in production is consumer generated content submitted by real end-users.

Data set types

DCE data sets are provided as either full or incremental and are described below.

1. Full

Files in a full data set contain a complete snapshot of all publicly displayable data. You should use full data sets to populate your data store. When new full data sets become available, you should erase any existing data and completely recreate your data store.

Full data sets are available in the following intervals:

stagingTo facilitate development, we will generate full data sets every Tuesday, Thursday & Saturday.
productionWe will generate new data sets once a week, every Monday.

2. Incremental

Files in an incremental data set are generated in response to new, modified and deleted content. Each item of incremental data (ex: a review, a question) represents a complete item. New content should be added to your existing data store. Existing content should be completely replaced with the latest version in the incremental data. Removed content should be erased from your data store.

Incremental data sets are available in the following intervals:

staging / productionWe will generate incremental data sets daily, except on days when a full data set is generated.


Data sets will be available approximately 24 hours after access to the DCE API Key has been approved for the first time.


The following required credentials will be provided by Bazaarvoice:

PasskeyA unique per-environment identifier included with each request. You will receive two passkeys, one for staging and one for production.
SecretkeyAvailable along with Passkey in developer tools. Used to encrypt the access signature. Known only to you and Bazaarvoice. You will receive two secrets, one for staging and one for production. Across this documentation it is mentioned as shared secret key.


The DCE exposes two version types: One for the DCE HTTP Service and another for the DCE Data Sets. This allows you to retain control over how you interact with the DCE and decouples your implementation from future changes to the DCE until you are ready to upgrade.

This table shows all versions:

Version Release Date Deprecation Date Status

DCE service version (identifies the structure of the URL path, query string parameters and headers)

v1 (Beta) Invite only May 2017 Deprecated
v2 May 2017 TBD Active
v3 August 2017 TBD Latest

DCE data version (identifies the structure of the data returned by the DCE)

v1 (Beta) Invite only May 2017 Deprecated
v2 May 2017 TBD Latest

These versions should not be expected to return data and/or may experience service degradation. Documentation specific to these versions may no longer be available. Bazaarvoice will provide advance notice before deprecating an API version.

A deprecation date has been announced for these versions. Until that date they will continue to function. Applications using these versions should be upgraded to the latest version before the deprecation date to ensure continued functionality. New applications should NOT use these versions.

Active versions continue to function, but applications using these versions should be upgraded to the latest version when possible to take advantage of new features and bug fixes. New applications should NOT use these versions.

This is newest version. Feature development is focused on future versions, but we may perform backwards compatible bug fixes. New applications SHOULD use this version.