> ## Documentation Index
> Fetch the complete documentation index at: https://docs.resolve.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Audit Logs

Audit Logs is a security feature in Resolve AI that provides a complete, auditable record of activity across the Resolve platform and its execution environment. Audit logs are designed to support **security monitoring**, **compliance and governance**, and **operational troubleshooting** by making it easy to answer questions like:

* Who did what, and when?
* Which external systems were accessed, and did those calls succeed?
* What integration APIs did Resolve use?

Resolve AI produces two kinds of audit logs:

1. **User Access Logs**: capture authentication, authorization and user API access requests. These are available through a stream exposed via the Audit Logs API.
2. **Integration Access Logs**: capture each API request made to configured integrations on the Resolve Satellite during both autonomous execution and human-in-the-loop investigations and actions.

***

## User Access Logs

User Access Logs capture user activities within the Resolve AI platform. They form part of the unified audit stream and represent the authoritative record of *who accessed Resolve and what actions they took*.

These logs include:

* User authentication and logout events
* Authorization, role, and group changes
* API requests made to Resolve AI
* Team configuration changes

User Access Logs are available via the **Audit Logs API** and are intended primarily for security monitoring and compliance review.

### Accessing the User Access Logs using Audit Logs API

***

**Endpoint**

```shell theme={null}
GET /audit_logs/:orgId
```

Base URL: `https://api.app0.resolve.ai/audit_logs/:orgId`

***

**Authentication**

To use the Audit Logs API, you must first create an API Token from the Resolve AI web application. This token is used to authenticate your requests.

1. Navigate to **API Tokens** in the sidebar: [https://app0.resolve.ai/admin/api-tokens](https://app0.resolve.ai/admin/api-tokens).
2. Click **Create API Token**.
3. Provide a name for your token.
4. Copy and store the token securely - this is the only time you will see it.
5. Click **“I copied the token!”** to save and exit.

You must include the token in the Authorization header of your API requests as a Bearer token.

```shell theme={null}
Authorization: Bearer <your_token_here>
```

***

**Path Parameters**

`orgId` (string, required): Your organization's unique identifier.

***

**Query Parameters**

| Name      | Type   | Required | Description                                                     |
| --------- | ------ | -------- | --------------------------------------------------------------- |
| **start** | string | Optional | ISO8601 date string for start time (e.g., 2025-07-01T00:00:00Z) |
| **end**   | string | Optional | ISO8601 date string for end time (e.g., 2025-07-07T23:59:59Z)   |
| **limit** | string | Optional | Max limit 1000                                                  |

Time Range Rules:

* If both start and end are omitted: Defaults to the last 24 hours.
* If only start is provided: end defaults to start +1 day.
* If only end is provided: start defaults to end -1 day.
* Maximum allowed range: 7 days.
* `start` must be before `end`.

If the request violates these rules, you will receive a `400` Bad Request with an error message.

***

**Error Responses**

| Status Code | Reason                                                                  |
| ----------- | ----------------------------------------------------------------------- |
| `400`       | Invalid or missing time range, malformed dates, or range exceeds 7 days |
| `401`       | Missing or invalid Bearer token                                         |
| `404`       | Organization not found                                                  |
| `500`       | Internal server error or downstream failure                             |

***

**Pagination**

The Audit Logs API supports pagination based on log timestamps. By default, the API returns up to 1000 records per request. If there are more logs available within the requested time range, an `end_before` token will be included in the response. You can use this token in a subsequent request to fetch the next page of results.

* **Default page size:** 1000 logs.
* **Custom limit:** You can pass a limit query parameter to request fewer logs (must be between 1 and 1000).
* **Pagination token:** If the result set is exactly equal to the page size, the response will include an end\_before timestamp (ISO 8601 string). This represents the timestamp of the last log in the current response minus 1 millisecond.
* To fetch the next page, re-issue the request with `end=<end_before_value>` to get logs *before* that point in time.

Example Request:

```shell theme={null}
GET /audit_logs/ORG_ABC123?start=2025-07-01T00:00:00Z&end=2025-07-07T00:00:00Z&limit=500
```

Example Paginated Response:

```json theme={null}
{
  "logs": [
    { "organization_id": "ORG_ABC123", ... },
    ...
  ],
  "end_before": "2025-07-06T23:59:59.999Z"
}
```

You can then request the next page:

```shell theme={null}
GET /audit_logs/ORG_ABC123?start=2025-07-01T00:00:00Z&end=2025-07-06T23:59:59.999Z&limit=500
```

<Info>
  **Note:** Pagination is based on descending timestamps (newest to oldest). The end parameter is treated as an exclusive upper bound.
</Info>

***

**Event Schemas**

Each log entry conforms to one of the following OCSF classes:

* Authentication
* Authorization
* API Activity

These schemas ensure consistent field naming and make downstream analysis easier.

***

## Integration Access Logs

Integration Access Logs capture outbound API requests made by the Resolve Satellite during investigations and actions, including both autonomous execution and human-in-the-loop workflows. This includes calls to monitoring tools, cloud providers, and custom integrations.

These logs capture execution-level details such as:

* Integration and endpoint accessed
* HTTP method and status code
* Request and response sizes
* Success or failure outcome
* Sanitized request and response metadata

Integration Access Logs can be accessed directly from the Resolve Satellite via stdout/stderr or OTLP for real-time, in-environment operational monitoring of integrations executed by the Satellite.

<Info>
  **Note:** Audit logs never capture authentication secrets or tokens used in request headers.
</Info>

### Accessing the Integration Access Logs from the Resolve Satellite

Use Satellite audit logs when you need to monitor or troubleshoot **integration HTTP activity**, including failures, request volume, and payload sizes.

***

**Collection Behavior**

* Logs are emitted as structured JSON
* Each Satellite audit log includes `audit: true` for easy filtering
* Logs include standard metadata fields (timestamp, level, message)
* Satellite logs can optionally be exported via OTLP for direct ingestion into observability backends

***

**Notable Fields**

* `integrationKey`: Integration name (e.g., prometheus, grafana)
* `method`: HTTP method
* `baseUrl`: Request URL without query parameters
* `statusCode`: HTTP status code
* `result`: success or error
* `requestBodyBytes`, `responseBodyBytes`: Payload sizes

***

**Filtering Examples**

You can filter Satellite audit logs using the `audit: true` field. The following are illustrative examples of how you can query audit logs emitted by the Resolve Satellite.

<Tabs>
  <Tab title="Loki / LogQL">
    ```
    {job="satellite-telemetry"} | json | audit="true"
    ```
  </Tab>

  <Tab title="Splunk">
    ```
    index=satellite-index audit=true
    ```
  </Tab>

  <Tab title="Datadog">
    ```
    audit:true source:satellite-telemetry
    ```
  </Tab>
</Tabs>

***

## Frequently Asked Questions (FAQs)

<Accordion title="1. How do I set up OTLP export for Integration Access Logs on the Resolve Satellite?">
  You can configure the Resolve Satellite to export Integration Access Logs using the OpenTelemetry Protocol (OTLP). This allows you to forward audit logs directly to an observability backend instead of relying on container log collection.

  **Requirements**

  To enable OTLP export, **both** of the following must be set:

  * An OTLP logging flag (`OTLP_LOGGING` or `OTLP_AND_CONSOLE_LOGGING`)
  * A receiver URL (`OTLP_LOGS_RECEIVER_URL`)

  If either value is missing, OTLP export will not work.

  **Configuration**

  Enable OTLP export only:

  ```yaml theme={null}
  env:
    - name: OTLP_LOGGING
      value: "true"
    - name: OTLP_LOGS_RECEIVER_URL
      value: "https://your-otlp-endpoint.com"
  ```

  Enable dual logging (OTLP + stdout/stderr):

  ```yaml theme={null}
  env:
    - name: OTLP_AND_CONSOLE_LOGGING
      value: "true"
    - name: OTLP_LOGS_RECEIVER_URL
      value: "https://your-otlp-endpoint.com"
  ```

  **OTLP Endpoint Details**

  * Logs endpoint: `{OTLP_LOGS_RECEIVER_URL}/v1/logs`
  * Protocol: `OTLP HTTP/JSON`
  * Fallback behavior:
    \-- If `OTLP_LOGS_RECEIVER_URL` is not set, the Satellite falls back to `OTLP_RECEIVER_URL`
    \-- If neither is set, OTLP export is disabled
</Accordion>

<Accordion title="2. How long are audit logs retained in Resolve AI?">
  User access logs available via the Audit Logs API are retained for **30 days**.
  Integration access logs are only available directly from the Resolve Satellite via stdout/stderr or OTLP for operational monitoring.
  For long-term retention, export audit logs to your own logging or SIEM system for storage and analysis.
</Accordion>

<Accordion title="3. What timestamp format should I expect?">
  All timestamps are returned in **ISO 8601 UTC** format.
</Accordion>

<Accordion title="4. Does the Audit Log API support token rotation?">
  Yes. API tokens are created and managed through the Resolve UI.

  * Tokens can be revoked at any time by an admin
  * New tokens can be created through the UI
  * Token rotation policies can be implemented according to your organization’s security requirements
</Accordion>

<Accordion title="5. What is the event schema I should expect for the audit logs?">
  The Audit Log API output follows the Open Cybersecurity Schema Framework (OCSF) version 1.5.0. Each log entry is structured in accordance with one of the following schema classes.

  **(i) Authentication** **Logs**
  **Class:** OCSF Authentication

  **Description:** Captures user login and logout events, including success/failure status, protocol used, and device/network metadata.

  **Common Fields:**

  * organization\_id: Organization where the event originated
  * activity\_id: Type of authentication action (e.g., logon, logoff)
  * auth\_protocol\_id: Auth protocol used (e.g., SAML, OAuth2)
  * category\_uid, class\_uid, type\_uid: OCSF taxonomy identifiers
  * status\_id: Outcome (success, failure)
  * user: \{ name, email }
  * time: ISO 8601 timestamp of event
  * service.name: e.g., "Resolve Web App"
  * http\_request: \{ user\_agent, url }
  * metadata: \{ product, version }
  * src\_endpoint: \{ ip, type\_id } — Source IP and endpoint type
  * dst\_endpoint: \{ hostname } — Target host accessed
  * is\_remote: Whether the session was remote

  **Sample Authentication Log**

  ```json theme={null}
  {
    "organization_id": "ORG_ABC123",
    "activity_id": 1,
    "auth_protocol_id": 3,
    "category_uid": 6,
    "class_uid": 6001,
    "type_uid": 600101,
    "status_id": 1,
    "is_remote": true,
    "time": "2025-07-09T14:22:30.135Z",
    "user": {
      "name": "Alex Morgan",
      "email": "alex@company.com"
    },
    "service": {
      "name": "Resolve Web App"
    },
    "http_request": {
      "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 13_5_2)",
      "url": "<https://app.resolve.ai/login>"
    },
    "metadata": {
      "product": "Resolve Web App",
      "version": "v2.3.1"
    },
    "src_endpoint": {
      "ip": "192.0.2.15",
      "type_id": 2
    },
    "dst_endpoint": {
      "hostname": "resolve.ai"
    }
  }
  ```

  **(ii) Authorization Logs**
  **Class:** OCSF Authorize Session
  **Description:** Logs session-level privilege or group assignment actions such as role changes, session establishment, or group binding events.

  **Common Fields:**

  * organization\_id: Org associated with the event
  * activity\_id: Authorization-related activity
  * category\_uid, class\_uid, type\_uid: OCSF classification
  * status\_id: Outcome status (e.g., success, failure)
  * severity\_id: Informational, warning, etc.
  * event\_time: ISO 8601 timestamp
  * user: \{ name, email }
  * groups: Array of assigned groups, if applicable
  * session.uid: Session identifier (optional)
  * http\_request: \{ user\_agent, url }
  * metadata: \{ product, version }
  * src\_endpoint: \{ ip, type\_id }
  * message: Human-readable explanation or annotation (optional)

  **Sample Authorization Log**

  ```json theme={null}
  {
    "auditable": true,
    "organization_id": "ORG_ABC123",
    "activity_id": 21,
    "category_uid": 6,
    "class_uid": 6002,
    "type_uid": 600202,
    "status_id": 1,
    "severity_id": 2,
    "event_time": "2025-07-09T15:03:50.541Z",
    "user": {
      "name": "Jordan Lee",
      "email": "jordan@company.com"
    },
    "groups": [
      {
        "name": "admin"
      },
      {
        "name": "editor"
      }
    ],
    "session": {
      "uid": "Ssn-9fa283ca-e441"
    },
    "http_request": {
      "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
      "url": "<https://app.resolve.ai/users/permissions>"
    },
    "metadata": {
      "product": "Resolve Web App",
      "version": "v2.3.1"
    },
    "message": "User added to admin and editor groups",
    "src_endpoint": {
      "ip": "203.0.113.48",
      "type_id": 1
    }
  }
  ```

  **(iii) API Activity Logs**
  **Class:** OCSF API Activity

  **Description:** Tracks API requests made by users, capturing request and response details, trace identifiers, endpoint activity, and session metadata.

  **Common Fields:**

  * organization\_id: Source organization
  * activity\_id: Activity type (e.g., create, read, update, delete)
  * category\_uid, class\_uid, type\_uid: OCSF identifiers
  * status\_id: Whether the request was successful
  * severity\_id: Severity of the request (typically informational)
  * time: ISO timestamp of request
  * message: Custom message (e.g., “User fetched timeline”)
  * method: HTTP method (GET, POST, etc.)
  * endpoint: API endpoint accessed
  * actor: \{ user, session\_uid }
  * http\_request: \{ url, http\_headers } (sensitive values redacted)
  * http\_response: \{ status\_code, http\_headers }
  * src\_endpoint: \{ ip }
  * dst\_endpoint: \{ hostname, port }
  * metadata: \{ product, environment }

  **Sample API Activity Log**

  ```json theme={null}
  {
    "organization_id": "ORG_ABC123",
    "activity_id": 2,
    "category_uid": 3,
    "class_uid": 6003,
    "type_uid": 600302,
    "status_id": 2,
    "severity_id": 1,
    "time": "2025-07-09T15:30:11.884Z",
    "message": "Timeline data retrieval",
    "method": "GET",
    "endpoint": "/timeline",
    "actor": {
      "user": "Nina Patel",
      "session_uid": "sess_12de98f3fa7"
    },
    "http_request": {
      "url": "/timeline",
      "http_headers": {
        "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 13_5_2)",
        "accept": "*/*",
        "authorization": "REDACTED",
        "x-generated-nonce": "REDACTED"
      }
    },
    "http_response": {
      "status_code": 200,
      "http_headers": {
        "content-type": "application/json",
        "x-remix-response": "yes",
        "set-cookie": "REDACTED"
      }
    },
    "src_endpoint": {
      "ip": "198.51.100.77"
    },
    "dst_endpoint": {
      "hostname": "api.resolve.ai",
      "port": 443
    },
    "metadata": {
      "product": "Resolve Web App",
      "environment": "production"
    }
  }
  ```
</Accordion>