Bearer . If you do not have it yet, generate your Business Intelligence API Key in the app.bi_key query parameter; e.g. bi_key=DOZpz-h6xnOrKGIINlYvkd9hn41pRR3oG6cqH. In that case, the request could look as follows.bi_key query parameter is not set, the server will look for the authorization header as described above.page_size query parameter. For example, if you set page_size=100, the API will always return maximum 100 audits per request, no matter how many matching audits there are in the database. If not set, the page size defaults to 1.000.page parameter. For example, if you set page_size=100&page=2, you will get audits 101 - 200, while a request with page_size=100&page=3 yields audits 201 - 300. etc. If not set, page defaults to 1 so you get the first page.limit parameter. If set, the API will never fetch any further audits than that with index equal to the limit. For example, a request with page_size=100&page=2&limit=150 yields only the audits 101 - 150, while page_size=100&page=3&limit=150 returns just an empty array of audits because you have exceeded your limit. There is no limit by default.include_debug query parameter. If set to true via include_debug=true, this query parameter tells the server to include debug data in your audit logs, whenever applicable.correlation_ids parameter. It takes an array of correlation IDs separated by a comma, e.g. ., correlation_ids=af4012bd-d492-92ec-ffa4-31fd2b70b1bc,197d5d5a-f6f7-35de-1afb-dc26237ebfc9.rules parameter limits the audits to those produced by the specified rules. The individual rules are identified by ids separated by comma, i.e., rules=af4012bd-d492-92ec-ffa4-31fd2b70b1bc,197d5d5a-f6f7-35de-1afb-dc26237ebfc9. Moreover, one may further specify the allowed versions for each of the rules by including square brackets with the comma separated list of versions. For instance, rules=af4012bd-d492-92ec-ffa4-31fd2b70b1bc[1,2],197d5d5a-f6f7-35de-1afb-dc26237ebfc9 will return audits for rules with id af4012bd-d492-92ec-ffa4-31fd2b70b1bc whose version is either 1 or 2 and audits for rules with id 197d5d5a-f6f7-35de-1afb-dc26237ebfc9 of any version.rules=[1,2] will return audit logs for rules whose version is 1 or 2, no matter the rule ID.solver_keys parameter limits the audits to those produced by calling rules with the specified Solver API Key. The individual keys are separated by comma.tags query parameter allows you to filter the audits by tags present on the rules. For the audit to pass the filter, its rule needs to be decorated with all the tags specified in the query parameter. The tags are separated by comma. For example, a request with tags=Pricing,Test returns only audits from rules decorated by both the Pricing and the Test tag.date_gte and date_lte parameters allow to filter audit logs by date (and time). The former serves as a lower bound on the date of the solve, the latter serves as an upper bound. In other words, audits will match this filter only if they are older than date_gte and younger than date_lte. When specifying one or both of the parameters, you can choose from a number of supported formats, including ISO 8601 and RFC 2822 Date time. For example:order parameter can take two values, order=asc or order=desc. It specifies the chronological order of the audits returned. For order=asc, the audits are sorted chronologically, starting with the oldest. For order=desc, they are sorted chronologically, starting with the latest. By default, the audits are returned in ascending order.status_codes parameter limits the audit logs to those produced with the specified status code. The individual codes are separated by comma. For example, to get logs from rule solves that returned OK, use status_codes=200. To get audit logs from rule solves that returned some kind of rule error, use status_codes=400, 401, 404, 406, 426. Eventually, to get audit logs from rule solves that returned server error, use status_codes=500.Bearer . If you do not have it yet, generate your Business Intelligence API Key in the app.Bearer . If you do not have it yet, generate your Business Intelligence API Key in the app.correlation_ids parameter. It takes an array of correlation IDs separated by a comma, e.g. ., correlation_ids=af4012bd-d492-92ec-ffa4-31fd2b70b1bc,197d5d5a-f6f7-35de-1afb-dc26237ebfc9.rules parameter limits the audit logs to be deleted to those produced by the specified rules. The individual rules are identified by ids separated by comma, i.e., rules=af4012bd-d492-92ec-ffa4-31fd2b70b1bc,197d5d5a-f6f7-35de-1afb-dc26237ebfc9. Moreover, one may further specify the allowed versions for each of the rules by including square brackets with the comma separated list of versions. For instance, rules=af4012bd-d492-92ec-ffa4-31fd2b70b1bc[1,2],197d5d5a-f6f7-35de-1afb-dc26237ebfc9 will return audits for rules with id af4012bd-d492-92ec-ffa4-31fd2b70b1bc whose version is either 1 or 2 and audits for rules with id 197d5d5a-f6f7-35de-1afb-dc26237ebfc9 of any version.rules=[1,2] will return audit logs for rules whose version is 1 or 2, no matter the rule ID.date_gte and date_lte parameters allow to filter audit logs to be deleted by date (and time). The former serves as a lower bound on the date of the solve, the latter serves as an upper bound. In other words, audit logs will match this filter (and will be deleted) only if they are older than date_gte and younger than date_lte. When specifying one or both of the parameters, you can choose from a number of supported formats, including ISO 8601 and RFC 2822 Date time. (For some examples, see the preceding endpoint.)status_codes parameter limits the audit logs to those produced with the specified status code. The individual codes are separated by comma. For example, to delete logs from rule solves that returned OK, use status_codes=200. To delete audit logs from rule solves that returned some kind of rule error, use status_codes=400, 401, 404, 406, 426. Eventually, to delete audit logs from rule solves that returned server error, use status_codes=500.