Update the Index - Bloomreach Experience - Open Source CMS

Update the Index

After sending your catalog data, you must trigger an Ingestion API call to inform Bloomreach about the new catalog data and to index that catalog.

If you have multiple PATCH requests that need to be indexed for the same content catalog, you only need to call the Ingestion API once to index all of them. If you want data to be uploaded in the order it was sent, then you should allow the PUT/PATCH jobs to finish before running the Ingestion API. 

Content from newly sent catalog data will not be searchable until you call the Ingestion API. Likewise, changes to make an attribute searchable or not searchable will not be applied until you call the Ingestion API. If you have recently sent content catalog data or configured your attributes but your content search isn’t working as expected, try running the Ingestion API again.

Update the index

Generate and publish index for catalog:


https://api.connect.bloomreach.com/dataconnect/api/v1/accounts/{account ID}/catalogs/{catalog name}/indexes



Bearer {API key}

This will return a Job ID that can be used to query for status.


After this job is successful, your catalog item data will be available to query in the Product Search API endpoint after Bloomreach caches have cleared. This may be anywhere from 1-5 minutes.

Bloomreach processes the index requests sequentially, so there may be a delay before you can see the results. This depends on the amount of data and Index API requests you have queued.

Index updates more frequent than every 15 minutes may be rate limited.

Catalog and Job Management

List Job Status for a Job ID:


https://api.connect.bloomreach.com/dataconnect/api/v1/jobs/{job ID}



Bearer {API key}

This will return information about the specific ingestion job, including its status.

  "account_id": 9999,
  "attempts": 0,
  "created_at": "1586911454615",
  "started_at": "1586911525950",
  "status": "success",
  "stopped_at": "1586911530597",
  "message": "",
  "error_code": ""

For now, only the status, started_at, stopped_at properties should be considered stable.

Values for status property:

  • creating

  • queued

  • running

  • success

  • failed

  • skipped

  • killed

Values in bold are the ones that will typically be encountered.

Did you find this page helpful?
How could this documentation serve you better?
On this page
    Did you find this page helpful?
    How could this documentation serve you better?