context
parameter to the contents endpoints which helps customers by giving them more control and flexibility over how their data is logged. Now, customers can include context in their requests, just like with the POST /search
endpoint. This means they can adjust logging to better fit their needs, leading to more accurate data, better customization, and more relevant insights.
As part of a common effort to improve the security and performance of Inbenta products, we have upgraded the technology behind the Knowledge API.
We added a new dynabs parameter to the Knowledge API's POST /search
endpoint, that allows to refuse dynamic abstract information in a request, decreasing response times. The value for that parameter should be boolean.
entered
key as the associated log, which caused discrepancies in the total amount of clicks for specific dates between the Reporting API and the Dashboard. This is now fixed and the click event is logged with the correct date value (that means, the date the event occurred).
GET /contents/{contentId}
now accepts a new parameter autocompleterClick
that allows you to log clicks on autocompleter results.
Feature: The endpoint GET /user-types
now also returns the user type names along with the IDs. For further information, refer to the Knowledge API Routes documentation. Note that you have to publish the instance to Production for the endpoint to return the user type names.
POST /inbtrck/events
endpoint to allow customers to track their conversion events to calculate their own conversion rates. This was a requirement for the development of a new conversion events report in Knowledge instances.
We changed the HTTP status code returned by the Knowledge API’s endpoint GET /content/slug/slug
when the content is found using an old title instead of the current one. From now on, it will be considered a 301 Redirection, so integrations can react to this event. See API Routes for more info.
Fixed: An additional Direct Access click was logged when users rated a content suggested via Semantic Autocompleter in addition to the Autocomplete click. This is now fixed and only the initial Autocomplete click is logged.
Fixed: If the x-inbenta-env
, x-inbenta-user-type
, x-inbenta-source
and x-inbenta-session
headers are set in the request but with no value, we now use the defined default values in
the documentation.
The endpoint GET /contents/{contentId}/cross-selling
now returns forced cross selling contents via the parameter isForced
.
We added a new parameter withContentData
to the /categories
endpoints. This parameter allows to chose whether the response payload should include information about how many contents the categories have and their children. This allows to improve performance when this information is not required.
Feature: We added the parameter logUserInfo
to the contents endpoints and to GET /categories/{categoryId}/contents
to register a context for clicks. This option already existed for content searches. Now when a click context is set, clicks on contents are also registered with user data, which will appear in the "User Information" column of the Sessions > Details Dashboard.
We added a new boolean property hasCrossSelling
to contents returned by the Knowledge API. This property indicates if a content has cross selling items linked to them.
The Knowledge API now uses the following aliases for tracking routes so that ad blockers do not automatically block requests: POST /inbtrck/session
for POST /tracking/session
, POST /inbtrck/session/user
for POST /tracking/session/user
and POST /inbtrck/events
for POST /tracking/events
. The original endpoints remain active but are now marked as deprecated in the Developers Portal documentation, and the Knowledge SDK will start to use the new routes.
Fixed: The Knowledge API’s searchContents
endpoint was sometimes returning no results with a 422 error when there were indeed results found, but one of those results was missing information in a required field. This is now fixed and the API will no longer return the content without the required information and we will log an error report in our internal error reporting system.
The Knowledge API’s new GET /contents/slug/{slug}
endpoint allows you to obtain a content even if its title and slug have changed. The API remembers previous content slugs and returns the new content together with the new content slug with an HTTP 301 code.
Fixed: The Knowledge API endpoint GET /autocompleter/data
was returning the structure text/html
instead of application/json
. This is now fixed.
We improved the Knowledge API documentation by replacing old environment version names such as Edit and Live with the current names, which are Test, Preproduction and Production.
GET /user-types
endpoint that retrieves the user types available in each of the environments of the Knowledge API.
POST /search
endpoint and POST /tracking/events
endpoint in order to register contextual information to that event. This context will be displayed in the non-session reports of the Dashboard.
Feature: There are three new endpoints in the Knowledge API to handle Cross Selling: GET /contents/{contentId}/cross-selling
, GET /categories/{categoryId}/cross-selling
and GET /cross-selling
.
Feature: New endpoint in the Knowledge API in order to retrieve the related contents of a set of specified contents.
GET /contents/push
endpoint returned content id
as a string. It now returns it as integer.
/contents/push
endpoint was returning a 404 error when one of the ad-hoc push content IDs did not exist as a standard content. The API will no longer return this error.
/language-detector
endpoint.
/tracking/events endpoint
.
New: The KM API can now track information about the SDK version used as part of the User information.
/tracking/session
endpoint of the KM API now returns not only the sessionToken, but also the sessionId. This allows developers to retrieve and use sessionId to filter results in Dashboards.
/categories/slug/{slug}
endpoint so that you can retrieve not only the first level of categories but the whole category tree.
/contents/slug/{slug}
returned an error when a user sent booleans as "true" or "false", because it only accepted the values 0 or 1. This is now fixed and all API endpoints accepts both options: true/false or 0/1.
categoryId
parameter in the /contents
endpoint to define it is a string that contains category ids separated by comas.
Updated rate limits. The limits are now up to 5 times higher than before.
/cross-selling/{crossSellingId}
/cross-selling/search