/api/v2/users/{user_id}/logs
endpoint with the parameter include_totals=true
or the q
parameter.GET /api/v2/logs
or GET /api/v2/users/{user_id}/logs
endpoints of Management API at all.GET /api/v2/logs endpoint
with the by checkpoint method (using from
parameter).depnote
logs means the deprecated behavior has been removed from your code.
You can search your tenant logs with the following to look for queries that would throw errors after you migrate to v3:
type:depnote AND description:*logs*
These log entries include a description
field that specifies the deprecated behavior you’re using.
You can also check the details.request.path
and client_name
fields to see what application is calling either GET /api/v2/logs
or GET /api/v2/users/{user_id}/logs
.
total
field returned in the summary result when calling GET /api/v2/logs
or GET /api/v2/users/{user_id}/logs
is changing. When searching for logs using search engine v2, the totals field in your results tells you the number of logs that match the query you provided. However, in v3, the totals field tells you how many logs are returned in the page (similar to what the length field returns). To avoid any potential disruption, if your application relies on the total field for pagination purposes, you should update your logic to handle this change appropriately.q
parameter in the GET /api/v2/logs
has minor changes that need to be taken into account. When your tenant is migrated to logs v3 this validation will be enforced resulting in this query returning an error. To avoid any potential disruption, you should review your queries to make sure they comply with the supported query syntax.q
parameter includes an invalid field. When your tenant is migrated to logs v3 this validation will be enforced resulting in this call returning an error. To avoid any potential disruption, you should review your queries to make sure that only searchable fields are included.