Upsert
The upsert operation inserts or replaces the entire contents of a product record in Searchspring. Use this operation to insert new records, or replace existing records with new data.
Note: There is a separate partial update operation for a couple of fields for an already existing record.
Request URL
https://[Site ID]:[Secret Key]@[Site ID].a.searchspring.io/api/index/upsert.json- Site ID: The identifier for your site. It can be found on the My Account page of the Searchspring Management Console.
- Secret Key: The secret key for your live indexing API. Do not share this. Please contact [Searchspring Support](https://help.searchspring.net/hc/en-us) for your secret key.
Request Body
The request body should be a JSON encoded string with the following attributes. Note there is a 3MB limit on the size of the request body. If you wish to upsert more products than will fit in 3MB, you will need to split your products up into multiple batches.
- feedId: The identifier for your data feed. Please contact [Searchspring Support](https://help.searchspring.net/hc/en-us) for your Feed ID.
- records: An array of objects representing items in your Searchspring search database that you wish to create/update. See example below.
{
"feedId": 42,
"records": [{
"product_id": "1",
"name" : "Blue Nike Shirt",
"price" : 17.99,
"categories" : ["Clothing", "Shirts"],
"image" : "http://www.mystore.com/images/blueshirt.jpg",
"thumbnail" : "http://www.mystore.com/thumbs/blueshirt.jpg",
"url" : "http://www.mystore.com/blue-shirt.html",
"in_stock" : true,
"rating" : 4.5,
"brand" : "Nike",
"color" : "Blue",
"popularity" : 9
},{
"product_id": "2",
"name" : "Red Volcom Shirt",
"price" : 19.99,
"categories" : ["Clothing", "Shirts"],
"image" : "http://www.mystore.com/images/redshirt.jpg",
"thumbnail" : "http://www.mystore.com/thumbs/redshirt.jpg",
"url" : "http://www.mystore.com/red-shirt.html",
"in_stock" : true,
"rating" : 4.2,
"brand" : "Volcom",
"color" : "Red",
"popularity" : 7
},{
"product_id": "3",
"name" : "Green Adidas Shoes",
"price" : 49.99,
"categories" : ["Shoes", "Sale"],
"image" : "http://www.mystore.com/images/greenshoes.jpg",
"thumbnail" : "http://www.mystore.com/thumbs/greenshoes.jpg",
"url" : "http://www.mystore.com/green-shoes.html",
"in_stock" : false,
"rating" : 5,
"brand" : "Adidas",
"color" : "Green",
"popularity" : 10
}]
}Update
Updates partially update an existing product record. Examples include updating the price of an item and marking a product as out of stock.
Request URL
https://[Site ID]:[Secret Key]@[Site ID].a.searchspring.io/api/index/update.json- Site ID: The identifier for your site. It can be found on the My Account page of the Searchspring Management Console.
- Secret Key: The secret key for your live indexing API. Do not share this. Please contact support@searchpspring.net for your secret key.
Request Body
The request body should be a JSON encoded string with the following attributes. Note there is a 3MB limit on the size of the request body. If you wish to update more products than will fit in 3MB, you will need to split your products up into multiple batches.
- feedId: The identifier for your data feed. Please contact support@searchspring.net for your Feed ID.
- records: An array of objects representing items in your Searchspring search database that you wish to update. Each record must include your Searchspring ID field. You may update more than one field at a time. See example below.
Example:
{
"feedId": 42,
"records": [{
"product_id": "1",
"price": 79.99,
"in_stock" : true
},{
"product_id": "2",
"price": 149.99,
"in_stock" : false
}]
}Delete
Deletes products from the Searchspring search database. This uses the same endpoint as the Upsert command, but uses the DELETE HTTP method instead of POST.
Request URL
https://[Site ID]:[Secret Key]@[Site ID].a.searchspring.io/api/index/upsert.json- Site ID: The identifier for your site. It can be found on the My Account page of the Searchspring Management Console.
- Secret Key: The secret key for your live indexing API. Do not share this. Please contact [Searchspring Support](https://help.searchspring.net/hc/en-us) for your secret key.
Request Body
The request body should be a JSON encoded string with the following attributes. Note there is a 3MB limit on the size of the request body. If you wish to delete more products than will fit in 3MB, you will need to split your products up into multiple batches.
- feedId: The identifier for your data feed. Please contact [Searchspring Support](https://help.searchspring.net/hc/en-us) for your Feed ID.
- records: An array of IDs of the products in the Searchspring search database that you wish to delete. These must match the values in your Searchspring ID field. You may delete more than one product at a time. See example below.
Example:
{
"feedId": 42,
"records": ["1","2","3"]
}Use Cases & Caveats
(From Jake)
At the moment, live indexing should only be used for updating the index in between bulk runs. So just as long as a bulk feed is still the primary way to index data, and a client is providing their own data for things that we usually attach in a supplemental fashion (google analytics, external feeds), on that same feed, then live indexing is able to be used.
Requirements
Full record live indexing “upserts”:
- Always have a bulk feed available for indexing. Can’t be a url to the original feed that never gets updated
- All live indexing request data from client, should be included in next bulk feed
- Can’t have supplemental feeds (ga doc filter; external fields doc filter; any review/rating doc filter). This data would need to already be in their bulk feed
Partial live indexing “updates”:
- All the above
- No doc filter(s) that requires data. In general it’s just safer to have no dock filters, but it is possible for certain doc filters to behave in a manner to allow partial updates.
Caveats:
- Live indexing endpoints only acknowledge when data is successfully “queued”, which doesn’t mean much from the client’s perspective. There is no guarantee that the requests will be indexed (even eventually). There is no way for a client to know if a request indexed, and no way for them to see error messages or reasons. We of course are able to do this through sumo, but currently it’s a manual process.
- Even when requests are successfully indexed, there is no guarantee of order of operation. (exception: newer data for the same record already in queue, will always replace older da
- If there is some problem on our side, and requests which should have succeeded, but did not because of infrastructure issues, those request are lost. (thus the requirement for a recently updated bulk feed)
It probably sounds unreasonable to just stop advertising live indexing …. but with the requirements/caveats, it’s usually only fit for those clients that have the ability to keep their feed up-to-date, and the ability to provide all their own data, without our features that join it for them.
Comments
0 comments
Please sign in to leave a comment.