---
title: Retrieve log entries using REST API
description: You can retrieve log events directly from the /monitoring/logs REST API endpoint. With this method, you access each of your tenant environments individually and use REST API filters to refine log results.
component: pingoneaic
page_id: pingoneaic:tenants:audit-debug-logs-pull
canonical_url: https://docs.pingidentity.com/pingoneaic/tenants/audit-debug-logs-pull.html
section_ids:
  retrieve-log-entries: Retrieve the log entries
  get-log-results-for-a-time-period: Get log results for a time period
  tail-logs: Tail logs
  view-logs-for-a-specific-request: View logs for a specific request
  filter-log-results: Filter log results
  filter_array_items_in_log_results: Filter array items in log results
  filter_log_results_between_two_dates: Filter log results between two dates
  add-response-fields: Add response fields
  authentication-events: Authentication events
  identity-object-events: Identity object events
  add_identity_object_event_fields_to_audit_logging: Add identity object event fields to audit logging
  configure-watched-fields: Configure watched fields
  rate-limiting: Rate limiting
  logs-endpoint: Logs endpoint
  logs-tail-endpoint: Logs tail endpoint
  troubleshooting-audit-logs: Troubleshooting
  update-audit-configuration: Update audit configuration
  include-large-log-entries-in-filter-log-results: Include large log entries in filter log results
  import-curl-commands-into-postman: Import cURL commands into Postman
---

# Retrieve log entries using REST API

|   |                                                                                                                                                                                                                                                                                   |
| - | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|   | This method retrieves logs directly by querying an API endpoint and polling Advanced Identity Cloud for new entries. Learn more about real-time log streaming to an external monitoring tool or SIEM in [stream logs to an external monitoring tool](audit-debug-logs-push.html). |

You can retrieve log events directly from the `/monitoring/logs` REST API endpoint. With this method, you access each of your tenant environments individually and use REST API filters to refine log results.

![log events pull](_images/log-events-pull.png)

## Retrieve the log entries

To retrieve the stored Advanced Identity Cloud log entries for a [source](audit-debug-log-sources.html), use the `/monitoring/logs` endpoint, specifying the source as a parameter.

Advanced Identity Cloud stores logs for 30 days.

|   |                                                                                                                                                               |
| - | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|   | You need to [get an API key and secret](../developer-docs/authenticate-to-rest-api-with-api-key-and-secret.html) before you can authenticate to the endpoint. |

Example request:

```bash
$ curl -G \
--request GET 'https://<tenant-env-fqdn>/monitoring/logs' \
--header 'x-api-key: <api-key>' \
--header 'x-api-secret: <api-secret>' \
--data 'source=am-authentication'
```

Example response:

```json
{
  "result": [{
    "payload": "<payload>",
    "timestamp": "<dateTime>",
    "type": "application/json",
    "source": "am-authentication"
  }, {
    "...": "..."
  }],
  "resultCount": "1000",
  "pagedResultsCookie": "<pagedResultsCookie>",
  "totalPagedResultsPolicy": "NONE",
  "totalPagedResults": -1,
  "remainingPagedResults": -1
}
```

Advanced Identity Cloud returns the available log entries in the `result` array. Results are in JSON format or plaintext, depending on the source you request.

To reduce the size of the output, log query results are by default restricted to the last 24 hours, unless you add `beginTime` and/or `endTime` query parameters. Learn more in [Get log results for a time period](#get-log-results-for-a-time-period).

### Get log results for a time period

Use the `beginTime` and `endTime` query parameters to return entries created between two ISO 8601 formatted times.

Example request:

```bash
$ curl -G \
--request GET 'https://<tenant-env-fqdn>/monitoring/logs' \
--header 'x-api-key: <api-key>' \
--header 'x-api-secret: <api-secret>' \
--data 'source=am-authentication' \
--data 'beginTime=2023-03-01T12:45:00Z' \
--data 'endTime=2023-03-01T12:50:00Z'
```

The `beginTime` and `endTime` query parameters are subject to these rules:

1. If `endTime` is not specified, it defaults to the current time.

2. If `beginTime` is not specified, it defaults to 24 hours before `endTime`.

3. If `beginTime` is specified, it must be 24 hours or less before `endTime`.

## Tail logs

To *tail*, or get the latest entries in the stored logs for a source, use the `/monitoring/logs/tail` endpoint with the source as a parameter.

The first call to the tail endpoint returns log entries from the last 15 seconds. Subsequent calls return log entries in a range that starts from the last returned log entry in the previous result (inclusive) and ends with the latest log entry but one. If calls to the tail endpoint are not frequent enough to match the rate at which the log entries are produced, the result may not include all available log entries.

The format of the log results depends on the source or sources specified in your request. Some sources return only JSON formatted log entries and some sources return only plaintext log entries. Some sources, such as `am-everything`, can return log entries in both formats.

Example request:

```bash
$ curl -G \
--request GET 'https://<tenant-env-fqdn>/monitoring/logs/tail' \
--header 'x-api-key: <api-key>' \
--header 'x-api-secret: <api-secret>' \
--data 'source=am-everything'
```

Example response:

```json
{
  "result": [{
    "payload": "<payload>",
    "timestamp": "<dateTime>",
    "type": "<type>",
    "source": "am-core"
  }, {
    "...": "..."
  }],
  "resultCount": "100",
  "pagedResultsCookie": "<pagedResultsCookie>",
  "totalPagedResultsPolicy": "NONE",
  "totalPagedResults": -1,
  "remainingPagedResults": -1
}
```

You can specify multiple sources in a single call. Example request:

```bash
$ curl -G \
--request GET 'https://<tenant-env-fqdn>/monitoring/logs/tail' \
--header 'x-api-key: <api-key>' \
--header 'x-api-secret: <api-secret>' \
--data 'source=am-access,idm-access,idm-sync,idm-activity'
```

|   |                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
| - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|   | To keep tailing, pass the `pagedResultsCookie` value from the previous response in your request. This retrieves new records since your request.Example request:```bash
$ curl -G \
--request GET 'https://<tenant-env-fqdn>/monitoring/logs/tail' \
--header 'x-api-key: <api-key>' \
--header 'x-api-secret: <api-secret>' \
--data 'source=am-access,idm-access,idm-sync,idm-activity' \
--data '_pagedResultsCookie=<pagedResultsCookie>'
``` |

## View logs for a specific request

All log events for an external request into Advanced Identity Cloud are assigned the same unique transaction ID. The `x-forgerock-transactionid` response header holds the transaction ID:

```bash
$ curl \
--request POST 'https://<tenant-env-fqdn>/am/json/realms/root/realms/alpha/authenticate' \
--include \
--header 'Content-Type: application/json' \
--header 'X-OpenAM-Username: bjensen' \
--header 'X-OpenAM-Password: Passw0rd!' \
--header 'Accept-API-Version: resource=2.0, protocol=1.0' \
...
x-forgerock-transactionid: <transaction-id>
...
```

To filter the logs for a specific transaction ID, add the `transactionId` parameter to your API request; for example:

```bash
$ curl -G \
--request GET 'https://<tenant-env-fqdn>/monitoring/logs' \
--header 'x-api-key: <api-key>' \
--header 'x-api-secret: <api-secret>' \
--data 'source=am-authentication' \
--data 'transactionId=<transaction-id>'
```

Example response:

```json
{
  "result": [{
    "payload": "<payload>",
    "timestamp": "<dateTime>",
    "type": "application/json",
    "source": "am-authentication"
  }, {
    "...": "..."
  }],
  "resultCount": "8",
  "pagedResultsCookie": null,
  "totalPagedResultsPolicy": "NONE",
  "totalPagedResults": -1,
  "remainingPagedResults": -1
}
```

## Filter log results

Use the `_queryFilter` parameter to filter log results on any field or combination of fields in a payload. You can add the parameter to the `/monitoring/logs` and `/monitoring/logs/tail` endpoints.

The benefits of the `_queryFilter` parameter are:

* Lets you iteratively refine queries to remove extraneous results and find the specific log entries you are interested in. This is useful when searching logs to debug a production issue.

  |   |                                                                                                                                                    |
  | - | -------------------------------------------------------------------------------------------------------------------------------------------------- |
  |   | Use the `/monitoring/logs` endpoint for iterative searching as the `/monitoring/logs/tail` endpoint only returns results from the last 15 seconds. |

* Lets you tune queries to reduce Advanced Identity Cloud log volume, making integration with external log tools such as [Splunk](https://www.splunk.com/) or [Elastic Stack](https://www.elastic.co/elastic-stack/) more efficient and potentially reducing storage costs.

The `_queryFilter` parameter takes a URL-encoded filter expression:

```bash
$ curl -G \
--request GET 'https://<tenant-env-fqdn>/monitoring/logs' \
--header 'x-api-key: <api-key>' \
--header 'x-api-secret: <api-secret>' \
--data 'source=<source>' \
--data-urlencode '_queryFilter=<filter-expression>'
```

Learn more about constructing a filter expression in the [filter expression rules for `_queryFilter`](../developer-docs/crest/query.html#crest-query-queryFilter). Here are some basic examples:

| Example filter expression                                          | Description                                                                                                   |
| ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------- |
| `/payload co "WARNING"`                                            | Search plaintext results for a particular string.                                                             |
| `/payload/client/ip co "10.104.1.5"`                               | Search for JSON results containing a particular client IP address.                                            |
| `/payload/level eq "DEBUG"`                                        | Search for JSON results with a particular log level.                                                          |
| `/payload/eventName eq "access"`                                   | Search for JSON results with a particular event name.                                                         |
| `/payload/eventName co "AM-ACCESS-ATTEMPT"`                        | Search for JSON results containing a particular event name.                                                   |
| `/payload/timestamp eq "2023-05-16T08:21:34.632Z"`                 | Search for JSON results with a particular timestamp.                                                          |
| `/payload/timestamp sw "2023-05-14T16:34:34"`                      | Search for JSON results with a timestamp that starts with a particular datetime.                              |
| `/payload/client/ip co "10.104.1.5" and /payload/level eq "ERROR"` | Search for JSON results containing a particular client IP address and also containing a particular log level. |
| `/payload/entries/info/nodeType pr`                                | Search for JSON results where an authentication node type is present.                                         |

### Filter array items in log results

To filter on array items, do not include an array index in your filter expression.

For example, to search for JSON results where the authentication node type is `ScriptedDecisionNode`:

* Wrong: `/payload/entries/0/info/nodeType eq "ScriptedDecisionNode"`

* Right: `/payload/entries/info/nodeType eq "ScriptedDecisionNode"`

where a log entry for an authentication node looks like this:

```json
    {
      "payload": {
        "_id": "7ae37a4b-f22b-4c5e-8621-2130d5bc603c-9310858",
        "component": "Authentication",
        "entries": [
          {
            "info": {
              "authLevel": "0",
              "displayName": "Using Invite?",
              "nodeId": "15edd2f7-22f1-4f32-bf0a-8ca3f98af850",
              "nodeOutcome": "False",
              "nodeType": "ScriptedDecisionNode",
              "treeName": "Login"
            }
          }
        ],
        "eventName": "AM-NODE-LOGIN-COMPLETED",
        ...
    }
```

### Filter log results between two dates

To filter log results between two dates, use the `beginTime` and `endTime` query parameters with ISO 8601 datetime values. The difference between the two datetimes must be 24 hours or less.

```bash
$ curl -G \
--request GET 'https://<tenant-env-fqdn>/monitoring/logs' \
--header 'x-api-key: <api-key>' \
--header 'x-api-secret: <api-secret>' \
--data 'source=<source>' \
--data 'beginTime=<begin-datetime>' \
--data 'endTime=<end-datetime>' \
--data-urlencode '_queryFilter=<filter-expression>'
```

For example, to filter log results between two specific dates for a specific user :

```bash
$ curl -G \
--request GET 'https://<tenant-env-fqdn>/monitoring/logs' \
--header 'x-api-key: <api-key>' \
--header 'x-api-secret: <api-secret>' \
--data 'source=am-authentication' \
--data 'beginTime=2023-05-24T12:40:00.00Z' \
--data 'endTime=2023-05-24T12:45:00.00Z' \
--data-urlencode '_queryFilter=/payload/principal eq "user.name@example.com"'
```

## Add response fields

### Authentication events

You can use a script to add extra information to log entries for authentication events. Learn more in [Add information to authentication audit log entries](../am-scripting/scripting-api-node.html#scripting-api-node-audit-logging).

### Identity object events

You can configure audit log results to include additional identity object events. For example, you may want to log the before and after values of specific activities, such as changes to a user's last name or email address.

To include additional identity object event fields, add them to the `includeIf` property in the audit configuration. Make these changes in your development environment and then promote them.

|   |                                                                                                                                                                                                                                                                                                         |
| - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|   | By default, Advanced Identity Cloud audits identity object event fields that are safe to log. When adding audit event fields, be mindful of the type of information that you intend to expose in the logs. For example, you may need to keep personally identifiable information (PII) out of the logs. |

#### Add identity object event fields to audit logging

1. Get the current audit configuration.

   Example request:

   ```bash
   $ curl \
   --request GET \
   --header 'Authorization: Bearer <access-token>' \
   --header 'Content-Type: application/json' \
   'https://<tenant-env-fqdn>/openidm/config/audit'
   ```

   Learn more in the [IDM REST API reference](../idm-rest-api/endpoints/rest-server-config.html).

   > **Collapse: Show response**
   >
   > ```json
   > {
   >   "_id": "audit",
   >   "auditServiceConfig": {
   >     "availableAuditEventHandlers": [
   >       "org.forgerock.audit.handlers.csv.CsvAuditEventHandler",
   >       "org.forgerock.audit.handlers.jms.JmsAuditEventHandler",
   >       "org.forgerock.audit.handlers.json.JsonAuditEventHandler",
   >       "org.forgerock.audit.handlers.json.stdout.JsonStdoutAuditEventHandler",
   >       "org.forgerock.openidm.audit.impl.RepositoryAuditEventHandler",
   >       "org.forgerock.openidm.audit.impl.RouterAuditEventHandler",
   >       "org.forgerock.audit.handlers.syslog.SyslogAuditEventHandler"
   >     ],
   >     "caseInsensitiveFields": [
   >       "/access/http/request/headers",
   >       "/access/http/response/headers"
   >     ],
   >     "filterPolicies": {
   >       "value": {
   >         "excludeIf": [
   >           "/access/http/request/cookies/&{com.iplanet.am.cookie.name}",
   >           "/access/http/request/cookies/session-jwt",
   >           "/access/http/request/headers/&{com.sun.identity.auth.cookieName}",
   >           "/access/http/request/headers/&{com.iplanet.am.cookie.name}",
   >           "/access/http/request/headers/accept-encoding",
   >           "/access/http/request/headers/accept-language",
   >           "/access/http/request/headers/Authorization",
   >           "/access/http/request/headers/cache-control",
   >           "/access/http/request/headers/connection",
   >           "/access/http/request/headers/content-length",
   >           "/access/http/request/headers/content-type",
   >           "/access/http/request/headers/proxy-authorization",
   >           "/access/http/request/headers/X-OpenAM-Password",
   >           "/access/http/request/headers/X-OpenIDM-Password",
   >           "/access/http/request/queryParameters/access_token",
   >           "/access/http/request/queryParameters/IDToken1",
   >           "/access/http/request/queryParameters/id_token_hint",
   >           "/access/http/request/queryParameters/Login.Token1",
   >           "/access/http/request/queryParameters/redirect_uri",
   >           "/access/http/request/queryParameters/requester",
   >           "/access/http/request/queryParameters/sessionUpgradeSSOTokenId",
   >           "/access/http/request/queryParameters/tokenId",
   >           "/access/http/response/headers/Authorization",
   >           "/access/http/response/headers/Set-Cookie",
   >           "/access/http/response/headers/X-OpenIDM-Password"
   >         ],
   >         "includeIf": []
   >       }
   >     },
   >     "handlerForQueries": "json"
   >   },
   >   "eventHandlers": [
   >     {
   >       "class": "org.forgerock.audit.handlers.json.stdout.JsonStdoutAuditEventHandler",
   >       "config": {
   >         "name": "json",
   >         "topics": [
   >           "access",
   >           "activity",
   >           "sync",
   >           "authentication",
   >           "config"
   >         ]
   >       }
   >     }
   >   ],
   >   "eventTopics": {
   >     "activity": {
   >       "filter": {
   >         "actions": [
   >           "create",
   >           "update",
   >           "delete",
   >           "patch",
   >           "action"
   >         ]
   >       },
   >       "passwordFields": [
   >         "password"
   >       ],
   >       "watchedFields": [
   >         "*"
   >       ]
   >     },
   >     "config": {
   >       "filter": {
   >         "actions": [
   >           "create",
   >           "update",
   >           "delete",
   >           "patch",
   >           "action"
   >         ]
   >       }
   >     }
   >   },
   >   "exceptionFormatter": {
   >     "file": "bin/defaults/script/audit/stacktraceFormatter.js",
   >     "type": "text/javascript"
   >   }
   > }
   > ```

2. Make a backup of the audit configuration.

3. Update the `includeIf` property (under `filterPolicies`) in the audit configuration to include the fields you want to add.

   The following example updates the audit configuration to include before and after values of a user's last name and email address:

   ```bash
   $ curl \
   --request PUT \
   --header 'Authorization: Bearer <access-token>' \
   --header 'Content-Type: application/json' \
   --data-raw '
   {
     "_id": "audit",
     ...
      "filterPolicies": {
        "value": {
          "excludeIf": [
             "/access/http/request/cookies/&{com.iplanet.am.cookie.name}",
             "/access/http/request/cookies/session-jwt",
           ...
           ],
           "includeIf": [
              "/activity/before/sn", (1)
              "/activity/after/sn", (2)
              "/activity/before/mail", (3)
              "/activity/after/mail" (4)
           ]
         }
      },
     ...
   }' \
   'https://<tenant-env-fqdn>/openidm/config/audit'
   ```

   Fields added:

   |       |                                              |
   | ----- | -------------------------------------------- |
   | **1** | Logs the user's last name before change.     |
   | **2** | Logs the user's last name after change.      |
   | **3** | Logs the user's email address before change. |
   | **4** | Logs user's email address after change.      |

Once updated, `idm-activity` and `idm-everything` audit logs will include the fields you have added.

For example, the following entry in a sample `idm-activity` log shows before and after values for changes to a user's last name and email address from "Brown" to "Granger":

```json
{
    "payload": {
        "message": "",
        "runAs": "bd220328-9762-458b-b05a-982ac3c7fc54",
        "transactionId": "1630683558570-abec9e9304c84ad368ba-28676/0",
        "before": {
            "sn": "Brown",
            "mail": "jbrown@example.com"
        },
        "operation": "PATCH",
        "passwordChanged": false,
        "_id": "52f7cea0-285d-4ef6-bda3-83256dda71c5-1300250",
        "revision": "00000000412cae36",
        "eventName": "activity",
        "userId": "bd220328-9762-458b-b05a-982ac3c7fc54",
        "status": "SUCCESS",
        "objectId": "managed/alpha_user/ce7492dc-8759-47b3-b4ee-eda8d4de4ab1",
        "timestamp": "2023-09-03T15:39:42.862Z",
        "changedFields": [],
        "after": {
            "sn": "Granger",
            "mail": "jgranger@example.com"
        }
    "type": "application/json",
    "timestamp": "<date-time>"
}
```

|   |                                                                                                                                                                                                                                                                                                                                                                                                                         |
| - | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|   | You can also exclude fields from audit logging by adding them to the `excludeIf` property in the audit configuration.For example, to prevent audit logs from showing target object attributes for synchronization and reconciliation events, add the following entries to the `excludeIf` property in the audit configuration:```json
"/sync/targetObject/<attribute-name>",
"/recon/targetObject/<attribute-name>"
``` |

#### Configure watched fields

You can configure the activity log to track changes to specific managed object fields, or use a wildcard (`*`) to track all fields. When a watched field changes, Advanced Identity Cloud records the field name in the `changedFields` array of the activity log entry as a JSON pointer (for example, `/mail`).

To configure watched fields:

1. Get the current audit configuration:

   ```bash
   curl \
   --header "Authorization: Bearer <access-token>" \
   --header "Accept-API-Version: resource=1.0" \
   --request GET \
   'https://<tenant-env-fqdn>/openidm/config/audit'
   ```

2. Update the `watchedFields` array under `eventTopics.activity` to include the fields you want to track. Use `["*"]` to track all fields, or list specific field names.

   The following example configures the activity log to only track changes to a user's email address and postal address:

   ```bash
   curl \
   --header "Authorization: Bearer <access-token>" \
   --header "Content-Type: application/json" \
   --header "Accept-API-Version: resource=1.0" \
   --request PUT \
   --data '{
     "_id": "audit",
     ...
     "eventTopics": {
       "activity": {
         "filter": {
           "actions": [
             "create",
             "update",
             "delete",
             "patch",
             "action"
           ]
         },
         "passwordFields": [
           "password"
         ],
         "watchedFields": [
           "mail",
           "postalAddress"
         ]
       }
     },
     ...
   }' \
   'https://<tenant-env-fqdn>/openidm/config/audit'
   ```

When a watched field changes, Advanced Identity Cloud adds its name to the `changedFields` array in the activity log entry. For example:

```json
{
  "payload": {
    "changedFields": ["/mail"],
    "operation": "PATCH",
    "objectId": "managed/realm-name_user/<user-id>",
    "passwordChanged": false,
    ...
  }
}
```

|   |                                                                                                                                                                                                                                                                           |
| - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|   | Advanced Identity Cloud doesn't log the before and after values of watched fields in `changedFields`, it only records that the field changed. To log before and after values, use the `includeIf` configuration described in [Add response fields](#add-response-fields). |

|   |                                                                                                                                                                                                                                                                                |
| - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|   | The `passwordFields` property works similarly. If a field listed in `passwordFields` changes, Advanced Identity Cloud sets `passwordChanged` to `true` in the activity log entry. When `watchedFields` is set to `["*"]`, password field names also appear in `changedFields`. |

## Rate limiting

### Logs endpoint

To reduce unwanted stresses on the system, Advanced Identity Cloud limits the number of requests you can make to the `/monitoring/logs` endpoint in a certain timeframe:

* The page-size limit is 1000 logs per request.

  |   |                                                                                                                                                                                                 |
  | - | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
  |   | Ping Identity recommends you do not override the page-size limit with a greater value as it could increase request throttling and reduce the overall number of logs you can request per minute. |

* The request limit is 60 requests per minute.

* The theoretical upper rate limit is therefore 60,000 logs per minute. This limit is imposed by the underlying cloud infrastructure and can't be changed.

These limits apply per environment, so your development, staging, and production environments each have their own quota.

The following rate limit notification response headers are sent for each request to the `/monitoring/logs` endpoint:

* X-RateLimit-Limit

  The maximum number of requests allowed in the current rate limit window.

* X-RateLimit-Remaining

  The number of requests remaining in the current rate limit window.

* X-RateLimit-Reset

  The time in seconds since Jan. 1, 1970, UTC when the rate limit window resets.

A `429` HTTP status code on the `/monitoring/logs` endpoint indicates that the rate limit has been exceeded, and no results are returned.

### Logs tail endpoint

The `/monitoring/logs/tail` endpoint has the same request limit (60 per minute) and response headers as the `/monitoring/logs` endpoint. However, the endpoint also has a limit of 15,000 lines per request, which supersedes the page-size limit of 1000 logs per request.

Because calls to the `/monitoring/logs/tail` endpoint do not always fetch all logs, use this endpoint for debugging only. Use the `/monitoring/logs` endpoint when you need to fetch all logs.

## Troubleshooting

### Update audit configuration

Sometimes a log source is shown in the available [sources](audit-debug-log-sources.html) in Advanced Identity Cloud but returns no results when you query the Advanced Identity Cloud logging endpoints. In this case, check the underlying IDM audit configuration to ensure that the corresponding audit topic for the source is enabled.

The following example shows how to enable the `recon` event handler so that reconciliation events appear in the audit logs:

1. Get the current audit configuration.

   Example request:

   ```bash
   $ curl \
   --request GET \
   --header 'Authorization: Bearer <access-token>' \
   --header 'Content-Type: application/json' \
   'https://<tenant-env-fqdn>/openidm/config/audit'
   ```

   Learn more in [IDM REST API reference](../idm-rest-api/endpoints/rest-server-config.html).

2. Update the audit configuration as needed. The following example enables the reconciliation audit event handler.

   Example update:

   ```bash
   $ curl \
   --request PUT 'https://<tenant-env-fqdn>/openidm/config/audit' \
   --header 'Authorization: Bearer <access-token>' \
   --header 'Content-Type: application/json' \
   --data-raw '
   {
     "_id": "audit",
     ...
     "eventHandlers": [
       {
         "class": "org.forgerock.audit.handlers.json.stdout.JsonStdoutAuditEventHandler",
         "config": {
           "elasticsearchCompatible": false,
           "enabled": true,
           "name": "json",
           "topics": [
             "access",
             "activity",
             "sync",
             "authentication",
             "config",
             "recon"
           ]
         }
       }
     ],
     ...
   }' \
   'https://<tenant-env-fqdn>/openidm/config/audit'
   ```

### Include large log entries in filter log results

Some Advanced Identity Cloud log output is too large to be stored as a single log entry, so is stored across two log entries instead. When this happens, any log output in JSON format is stored as two plaintext log entries rather than a single JSON log entry. Consequently, any filter expression that filters on a specific JSON field will not find any of these plaintext log entries.

To work around this, you can combine a specific field filter with a plaintext filter. For example, if you were searching for log results containing a particular transaction ID using the filter expression:

`/payload/transactionId co "<transaction-id>"`

you could add a plaintext filter as follows:

`/payload/transactionId co "<transaction-id>" or /payload co "<transaction-id>"`

to include both JSON and plaintext log entries in the log results.

### Import cURL commands into Postman

If you use [Postman's import cURL commands feature](https://learning.postman.com/docs/getting-started/importing-and-exporting/importing-curl-commands/) to convert cURL commands into Postman requests, you might have problems with the example commands on this page that use a GET request and include a `--data` parameter, such as this one:

```bash
$ curl -G \
--request GET 'https://<tenant-env-fqdn>/monitoring/logs'
--header 'x-api-key: <api-key>' \
--header 'x-api-secret: <api-secret>' \
--data 'source=am-authentication'
```

When you import the above command into Postman and run the request, it produces this error:

```bash
<html><head>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
<title>400 Bad Request</title>
</head>
<body text=#000000 bgcolor=#ffffff>
<h1>Error: Bad Request</h1>
<h2>Your client has issued a malformed or illegal request.</h2>
<h2></h2>
</body></html>
```

This occurs because Postman adds the value of `--data` parameter twice—as a query string but also incorrectly as a message body. The equivalent incorrect cURL query of the import would be:

```bash
curl \
--request GET 'https://<tenant-env-fqdn>/monitoring/logs?source=am-authentication' \
--header 'x-api-key: <api-key>' \
--header 'x-api-secret: <api-secret>' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'source=am-authentication'
```

To resolve, convert any `--data` parameters into a query string before importing into Postman:

```bash
$ curl \
--request 'https://<tenant-env-fqdn>/monitoring/logs?source=am-authentication'
--header 'x-api-key: <api-key>' \
--header 'x-api-secret: <api-secret>'
```