Search
Personalized search. The results are based on the search query and the preferences of a particular user.
Search Items
Personalized search. The results are based on the provided searchQuery and also on the user's past interactions (purchases, ratings, etc.) with the items (items more suitable for the user are preferred in the results).
All the string and set item properties are indexed by the search engine.
This endpoint should be used in a search box on your website/app. It can be called multiple times as the user is typing the query in order to get the most viable suggestions based on the current state of the query, or once after submitting the whole query.
The returned items are sorted by relevance (the first item being the most relevant).
Besides the recommended items, also a unique recommId is returned in the response. It can be used to:
- Let Recombee know that this search was successful (e.g., user clicked one of the recommended items). See Reported metrics.
- Get subsequent search results when the user scrolls down or goes to the next page. See Recommend Next Items.
It is also possible to use GET HTTP method - body parameters then become query parameters.
Parameters
ID of your database.
ID of the user for whom personalized search will be performed.
Search query provided by the user. It is used for the full-text search.
Number of items to be returned (N for the top-N results).
Scenario defines a particular search field in your user interface.
You can set various settings to the scenario in the Admin UI. You can also see the performance of each scenario in the Admin UI separately, so you can check how well each field performs.
The AI that optimizes models to get the best results may optimize different scenarios separately, or even use different models in each of the scenarios.
If the user does not exist in the database, returns a list of non-personalized search results and creates the user in the database. This allows, for example, rotations in the following recommendations for that user, as the user will be already known to the system.
With returnProperties=true, property values of the recommended items are returned along with their IDs in a JSON dictionary. The acquired property values can be used to easily display the recommended items to the user.
Example response:
{
"recommId": "ce52ada4-e4d9-4885-943c-407db2dee837",
"recomms":
[
{
"id": "tv-178",
"values": {
"description": "4K TV with 3D feature",
"categories": ["Electronics", "Televisions"],
"price": 342,
"url": "myshop.com/tv-178"
}
},
{
"id": "mixer-42",
"values": {
"description": "Stainless Steel Mixer",
"categories": ["Home & Kitchen"],
"price": 39,
"url": "myshop.com/mixer-42"
}
}
],
"numberNextRecommsCalls": 0
}Allows specifying which properties should be returned when returnProperties=true is set. The properties are given as a comma-separated list.
Example response for includedProperties=description,price:
{
"recommId": "a86ee8d5-cd8e-46d1-886c-8b3771d0520b",
"recomms":
[
{
"id": "tv-178",
"values": {
"description": "4K TV with 3D feature",
"price": 342
}
},
{
"id": "mixer-42",
"values": {
"description": "Stainless Steel Mixer",
"price": 39
}
}
],
"numberNextRecommsCalls": 0
}Logic specifies the particular behavior of the recommendation models. You can pick tailored logic for your domain and use case. See this section for a list of available logics and other details.
The difference between logic and scenario is that logic specifies mainly behavior, while scenario specifies the place where recommendations are shown to the users.
A dictionary of ReQL expressions that will be executed for each recommended item. This can be used to compute additional properties of the recommended items that are not stored in the database.
The keys are the names of the expressions, and the values are the actual ReQL expressions.
Example request:
{
"reqlExpressions": {
"isInUsersCity": "context_user[\"city\"] in 'cities'",
"distanceToUser": "earth_distance('location', context_user[\"location\"])"
}
}Example response:
{
"recommId": "ce52ada4-e4d9-4885-943c-407db2dee837",
"recomms":
[
{
"id": "restaurant-178",
"reqlEvaluations": {
"isInUsersCity": true,
"distanceToUser": 5200.2
}
},
{
"id": "bar-42",
"reqlEvaluations": {
"isInUsersCity": false,
"distanceToUser": 2516.0
}
}
],
"numberNextRecommsCalls": 0
}Responses
Successful operation.
userId does not match ^[a-zA-Z0-9_-:@.]+$, count is not a positive integer, searchQuery is not provided, filter or booster are not valid ReQL expressions, filter expression does not return boolean, booster does not return double or integer.
userId not found in the database and cascadeCreate is false. If there is no additional info in the JSON response, you probably have an error in you URL.
Search Item Segments
Personalized search that returns Segments from a Segmentation. The results are based on the provided searchQuery and also on the user's past interactions (purchases, ratings, etc.).
Based on the used Segmentation, this endpoint can be used for example for:
- Searching within categories or brands
- Searching within genres or artists
For example if the user is searching for "iPhone" this endpoint can return "cell phones" category.
You need to set the used Segmentation the Admin UI in the Scenario settings prior to using this endpoint.
The returned segments are sorted by relevance (first segment being the most relevant).
It is also possible to use GET HTTP method - body parameters then become query parameters.
Parameters
ID of your database.
ID of the user for whom personalized search will be performed.
Search query provided by the user. It is used for the full-text search.
Number of segments to be returned (N for the top-N results).
Scenario defines a particular application of recommendations. It can be, for example, "homepage", "cart", or "emailing".
You can set various settings to the scenario in the Admin UI. You can also see the performance of each scenario in the Admin UI separately, so you can check how well each application performs.
The AI that optimizes models to get the best results may optimize different scenarios separately or even use different models in each of the scenarios.
If the user does not exist in the database, returns a list of non-personalized recommendations and creates the user in the database. This allows, for example, rotations in the following recommendations for that user, as the user will be already known to the system.
Boolean-returning ReQL expression which allows you to filter recommended segments based on the segmentationId.
Number-returning ReQL expression which allows you to boost recommendation rate of some segments based on the segmentationId.
Logic specifies the particular behavior of the recommendation models. You can pick tailored logic for your domain and use case. See this section for a list of available logics and other details.
The difference between logic and scenario is that logic specifies mainly behavior, while scenario specifies the place where recommendations are shown to the users.
A dictionary of ReQL expressions that will be executed for each recommended Item Segment. This can be used to compute additional properties of the recommended Item Segments.
The keys are the names of the expressions, and the values are the actual ReQL expressions.
Example request:
{
"reqlExpressions": {
"countItems": "size(segment_items(\"categories\", 'segmentId'))"
}
}Example response:
{
"recommId": "a7ac55a4-8d6e-4f19-addc-abac4164d8a8",
"recomms":
[
{
"id": "category-fantasy-books",
"reqlEvaluations": {
"countItems": 486
}
},
{
"id": "category-sci-fi-costumes",
"reqlEvaluations": {
"countItems": 19
}
}
],
"numberNextRecommsCalls": 0
}Responses
successful operation
userId does not match ^[a-zA-Z0-9_-:@.]+$, count is not a positive integer, searchQuery is not provided, filter or booster is not valid ReQL expressions, filter expression does not return boolean, booster does not return double or integer.
userId not found in the database and cascadeCreate is false. If there is no additional info in the JSON response, you probably have an error in your URL.
Synonyms
Define that some words or phrases should be considered equal by the full-text search engine.
Add Search Synonym
Adds a new synonym for the Search items.
When the term is used in the search query, the synonym is also used for the full-text search.
Unless oneWay=true, it works also in the opposite way (synonym -> term).
An example of a synonym can be science fiction for the term sci-fi.
Parameters
ID of your database.
A word to which the synonym is specified.
A word that should be considered equal to the term by the full-text search engine.
If set to true, only term -> synonym is considered. If set to false, also synonym -> term works.
Default: false.
Responses
Successful operation. Returns data about the added synonym (including id).
Missing a field, or a field has a wrong type.
synonym and term pair already exists in the database. In many cases, you may consider this code a success – it only tells you that nothing has been written to the database.
List Search Synonyms
Gives the list of synonyms defined in the database.
Parameters
ID of your database.
The number of synonyms to be listed.
Specifies the number of synonyms to skip (ordered by term).
Responses
Successful operation.
Delete All Search Synonyms
Deletes all synonyms defined in the database.
Parameters
ID of your database.
Responses
Successful operation.
Delete Search Synonym
Deletes synonym of the given id. This synonym is no longer taken into account in the Search items.
Parameters
ID of your database.
ID of the synonym that should be deleted.
Responses
Successful operation.
Synonym with the given id does not exist.