> For the complete documentation index, see [llms.txt](https://docs.datasentinel.io/manual/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.datasentinel.io/manual/guides/readme/automate-with-the-api.md).

# Automate with the API

<div data-with-frame="true"><figure><img src="/files/ebMoLMpZFyLqpzByuzrk" alt="Datasentinel API"><figcaption></figcaption></figure></div>

Almost everything you can do from the Datasentinel user interface can also be done through its REST API. The API is the foundation for **automation** — provisioning instances from your CI/CD pipelines, synchronizing users and roles with your identity processes, exporting metrics into your own data stores, scheduling reports, and integrating alerting with your incident-management tooling.

This guide walks you through the two API surfaces Datasentinel exposes, how to authenticate against each, and the most common automation recipes — end to end.

{% hint style="info" %}
A comprehensive toolkit, with ready-to-use examples, is published on [GitHub](https://github.com/datasentinel/datasentinel_toolkit) and ships pre-installed with the on-premises platform at `/datasentinel/soft/datasentinel_toolkit`.
{% endhint %}

## Two API surfaces

Datasentinel exposes **two distinct APIs**, each serving a different layer of the architecture. Choosing the right one is the first decision you make.

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><h4><i class="fa-server">:server:</i> Platform API</h4></td><td><strong>Centralized control</strong></td><td>Runs on the platform. Manage agentless connections, users, roles, alerting, and pull workload metrics and PDF reports across <em>all</em> monitored instances.</td><td><a href="/spaces/lcWi6G1jtNuyGT9C0pkc/pages/F90GnK6G5jxhj2tJ6ak8">/spaces/lcWi6G1jtNuyGT9C0pkc/pages/F90GnK6G5jxhj2tJ6ak8</a></td></tr><tr><td><h4><i class="fa-microchip">:microchip:</i> Agent API</h4></td><td><strong>Per-agent control</strong></td><td>Runs on each host where an agent is installed. Manage that agent's own connections, upload server, proxy, and per-connection collection settings.</td><td><a href="/spaces/lcWi6G1jtNuyGT9C0pkc/pages/J9dSGVENOsIzGxqxpoKG">/spaces/lcWi6G1jtNuyGT9C0pkc/pages/J9dSGVENOsIzGxqxpoKG</a></td></tr></tbody></table>

At a glance:

<table><thead><tr><th width="150"></th><th>Platform API</th><th>Agent API</th></tr></thead><tbody><tr><td><strong>Base URL</strong></td><td><code>https://&#x3C;&#x3C;platform-server>>/ds-api</code></td><td><code>https://&#x3C;&#x3C;agent-host>>:8282/api</code></td></tr><tr><td><strong>Auth header</strong></td><td><code>user-token</code> (generated, valid 24h)</td><td><code>api-token</code> (your Datasentinel license key)</td></tr><tr><td><strong>Scope</strong></td><td>The whole platform / all instances</td><td>A single agent and its connections</td></tr><tr><td><strong>Availability</strong></td><td>On-premises platform installations</td><td>Wherever an agent is installed</td></tr><tr><td><strong>Use it for</strong></td><td>Agentless provisioning, RBAC, reports, metric export, alerting</td><td>Agent lifecycle, agent-side connections, collection tuning</td></tr></tbody></table>

***

## Platform API

### Authenticate

Every Platform API call (except token creation itself) requires a short-lived **access token** passed in the `user-token` header. You obtain it by authenticating once with a valid platform username and password.

{% stepper %}
{% step %}

#### Generate an access token

Authenticate with your credentials to receive a token. Store it in an environment variable so the following calls can reuse it.

```bash
export ACCESS_TOKEN=$(curl -sk -u myUser:myPassword \
  -X POST https://$DATASENTINEL_HOST/ds-api/user-token \
  | sed -E 's/.*"user-token" *: *"([^"]+)".*/\1/')
```

The raw response is a single JSON field:

```json
{
  "user-token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1ODAyMTYyMjQ..."
}
```

{% endstep %}

{% step %}

#### Use the token in subsequent calls

Pass the token in the `user-token` header of every request:

```bash
curl -sk --header "user-token: $ACCESS_TOKEN" \
  https://$DATASENTINEL_HOST/ds-api/users
```

{% endstep %}

{% step %}

#### Check token validity (optional)

You can inspect a token's owner and expiry at any time:

```bash
curl -sk -u myUser:myPassword \
  "https://$DATASENTINEL_HOST/ds-api/user-token?token=$ACCESS_TOKEN"
```

```json
{
  "email": "contact@datasentinel.io",
  "expire_time": "2026-05-26 13:58:53",
  "organization_name": "ds-data",
  "user": "datasentinel"
}
```

{% endstep %}
{% endstepper %}

{% hint style="info" %}
Access tokens are valid for **24 hours**. For long-running automation, generate a fresh token at the start of each run rather than persisting one.
{% endhint %}

{% content-ref url="/spaces/lcWi6G1jtNuyGT9C0pkc/pages/pWMV9FXn2PVthWicFKyC" %}
[Access Token](/manual/implementation/platform-usage/api-reference/access-token.md)
{% endcontent-ref %}

### Register a monitored instance (agentless)

With the [**Agentless feature**](/manual/features/other-features/agentless-monitoring.md), you can declare a PostgreSQL instance directly on the platform or use the API.<br>

Tags drive dashboards, consolidation, and role-based access.

{% stepper %}
{% step %}

#### Build the connection payload

```bash
cat > /tmp/connection.json <<EOF
{
  "host": "pg-sales-1734",
  "port": 9342,
  "user": "datasentinel",
  "password": "sentinel",
  "tags": "application=sales,environment=production,provider=amazon,datacenter=lyon"
}
EOF
```

{% endstep %}

{% step %}

#### Create the connection

The connection name becomes its identifier on the platform.

```bash
curl -sk --header "user-token: $ACCESS_TOKEN" \
  --header "Content-Type: application/json" \
  -X POST https://$DATASENTINEL_HOST/ds-api/pool/pg-instances/sales-production \
  -d @/tmp/connection.json
```

```json
{ "status": "Connection created and connected!" }
```

{% endstep %}

{% step %}

#### Verify, then enable or disable as needed

```bash
# Read it back
curl -sk --header "user-token: $ACCESS_TOKEN" \
  https://$DATASENTINEL_HOST/ds-api/pool/pg-instances/sales-production

# Temporarily pause monitoring
curl -sk --header "user-token: $ACCESS_TOKEN" \
  -X PATCH https://$DATASENTINEL_HOST/ds-api/pool/pg-instances/sales-production/disable
```

{% endstep %}
{% endstepper %}

{% hint style="info" %}
Tags follow the format `key=value,key=value`. A consistent tagging strategy is the single most important input for filtering, consolidation, and RBAC. See [**Organize Content using Tags**](/manual/guides/readme/organize-content-using-tags.md).
{% endhint %}

{% content-ref url="/spaces/lcWi6G1jtNuyGT9C0pkc/pages/QzfvS4NlK6uuNUarhtfv" %}
[Connection](/manual/implementation/platform-usage/api-reference/connection.md)
{% endcontent-ref %}

### Provision users and roles

Roles are tag-based access rules; users are granted one or more roles. Together they implement [**role-based access control**](/manual/features/other-features/role-based-access.md).

The example below grants a user access to **production instances in the London datacenter** only.

{% stepper %}
{% step %}

#### Create a tag-based role

A role's `access` array holds one or more filter sets. Tags inside the same `filters` array are combined with **AND**; separate filter sets are combined with **OR**.

```bash
cat > /tmp/role.json <<EOF
{
  "access": [
    {
      "filters": [
        { "tag": "environment", "value": "production" },
        { "tag": "datacenter",  "value": "london" }
      ]
    }
  ]
}
EOF

curl -sk --header "user-token: $ACCESS_TOKEN" \
  --header "Content-Type: application/json" \
  -X POST https://$DATASENTINEL_HOST/ds-api/roles/london-prod \
  -d @/tmp/role.json
```

```json
{ "status": "Role name london-prod created successfully" }
```

{% hint style="info" %}
Every tag key/value pair referenced by a role must already exist on at least one monitored instance.\
New instances matching the rules are added to the role scope automatically.
{% endhint %}
{% endstep %}

{% step %}

#### Create a user

Provide a password for a regular user (or set `"ldap": true` for an LDAP-authenticated account).

Assign roles with the `roles` array.

```bash
cat > /tmp/user.json <<EOF
{
  "password": "myPassword",
  "privilege": "read",
  "profile": "data admin",
  "live_360": 1,
  "roles": ["london-prod"]
}
EOF

curl -sk --header "user-token: $ACCESS_TOKEN" \
  --header "Content-Type: application/json" \
  -X POST https://$DATASENTINEL_HOST/ds-api/users/jane.doe@company.com \
  -d @/tmp/user.json
```

```json
{ "status": "User with login jane.doe created successfully" }
```

{% endstep %}

{% step %}

#### Adjust role assignments later

Roles can be added to or removed from an existing user at any time:

```bash
# Grant another role
curl -sk --header "user-token: $ACCESS_TOKEN" \
  -X POST https://$DATASENTINEL_HOST/ds-api/users/jane.doe@company.com/role/sales-role

# Revoke a role
curl -sk --header "user-token: $ACCESS_TOKEN" \
  -X DELETE https://$DATASENTINEL_HOST/ds-api/users/jane.doe@company.com/role/london-prod
```

{% endstep %}
{% endstepper %}

{% hint style="info" %}
The `roles` array replaced the single `role` field in **version 2024.04**. The `role` field is deprecated (use `roles` for new automation).
{% endhint %}

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Role API</strong></td><td>Create, replace, list roles and their assigned users.</td><td><a href="/spaces/lcWi6G1jtNuyGT9C0pkc/pages/7OpT9RFUa8A64C7B8awR">/spaces/lcWi6G1jtNuyGT9C0pkc/pages/7OpT9RFUa8A64C7B8awR</a></td></tr><tr><td><strong>User API</strong></td><td>Create, update, delete users; assign and remove roles.</td><td><a href="/spaces/lcWi6G1jtNuyGT9C0pkc/pages/PEkFNsuq5YqVposp2CLG">/spaces/lcWi6G1jtNuyGT9C0pkc/pages/PEkFNsuq5YqVposp2CLG</a></td></tr></tbody></table>

### Export workload metrics

The Workload API returns raw metrics in **JSON or CSV**, ideal for feeding dashboards, capacity planning, or a data warehouse. All endpoints accept a time window (`from`/`to`) and a `filters` array of tags to scope the result.

{% tabs %}
{% tab title="JSON" %}

```bash
cat > /tmp/query.json <<EOF
{
  "from": "2026-05-01",
  "to": "2026-05-25",
  "filters": [ { "tag": "application", "value": "crm" } ],
  "output": "json"
}
EOF

curl -sk --header "user-token: $ACCESS_TOKEN" \
  --header "Content-Type: application/json" \
  -X POST https://$DATASENTINEL_HOST/ds-api/activity/top-queries \
  -d @/tmp/query.json
```

{% endtab %}

{% tab title="CSV" %}

```bash
cat > /tmp/query.json <<EOF
{
  "from": "2026-05-01",
  "to": "2026-05-25",
  "filters": [ { "tag": "application", "value": "crm" } ],
  "output": "csv"
}
EOF

curl -sk --header "user-token: $ACCESS_TOKEN" \
  --header "Content-Type: application/json" \
  -X POST https://$DATASENTINEL_HOST/ds-api/activity/top-queries \
  -d @/tmp/query.json > top-queries.csv
```

{% endtab %}
{% endtabs %}

Frequently used Workload endpoints (all under `/ds-api/activity/`):

<table><thead><tr><th width="260">Endpoint</th><th>Returns</th></tr></thead><tbody><tr><td><code>session-history</code></td><td>Active Session History samples</td></tr><tr><td><code>top-queries</code></td><td>Most resource-intensive queries</td></tr><tr><td><code>queries-summary</code></td><td>Aggregated query metrics per database</td></tr><tr><td><code>pg-instance-infos</code></td><td>Inventory: version, size, type (primary/replica), uptime</td></tr><tr><td><code>pg-instance</code> / <code>server</code></td><td>Cluster and host activity (summary or minute-by-minute)</td></tr><tr><td><code>tables</code> / <code>indexes</code></td><td>Table and index activity</td></tr><tr><td><code>top-consumers</code></td><td>Top consumers of a resource, grouped by any tag</td></tr></tbody></table>

{% content-ref url="/spaces/lcWi6G1jtNuyGT9C0pkc/pages/rRbgcGgDFLK6tQGcDYOL" %}
[Workload](/manual/implementation/platform-usage/api-reference/workload.md)
{% endcontent-ref %}

### Generate and email a PDF report

The Reporting API produces the same PDF reports available in the UI.

Add the email parameters to have the platform deliver the report directly to recipients.

```bash
cat > /tmp/report.json <<EOF
{
  "from": "2026-05-24",
  "to": "2026-05-25",
  "filters": [ { "tag": "environment", "value": "production" } ],
  "report_type": "email",
  "subject": "[Datasentinel] Daily production workload",
  "recipients": ["dba-team@company.com"]
}
EOF

curl -sk --header "user-token: $ACCESS_TOKEN" \
  --header "Content-Type: application/json" \
  -X POST https://$DATASENTINEL_HOST/ds-api/activity/full-report \
  -d @/tmp/report.json
```

Swap `full-report` for `session-history-report`, `top-queries-report`, `table-report`, `instance-report`, `server-report`, `query-report`, or `data-size-report` to generate a single section.

{% hint style="info" %}
Omit the `report_type`/`subject`/`recipients` fields to receive the PDF in the response body instead of by email.
{% endhint %}

{% content-ref url="/spaces/lcWi6G1jtNuyGT9C0pkc/pages/Ax2GR2jf0dLwU2cYguRk" %}
[Reporting](/manual/implementation/platform-usage/api-reference/reporting.md)
{% endcontent-ref %}

### Pause alerting during maintenance

Suppress noisy notifications while you perform planned maintenance, then re-enable them — scriptable around your change windows. The instance is identified by `<<server_name>>@<<pg_name>>`.

```bash
INSTANCE="pg-crm-2031@:9342"

# Before maintenance — silence the instance
curl -sk --header "user-token: $ACCESS_TOKEN" \
  -X PATCH "https://$DATASENTINEL_HOST/ds-api/alerting/$INSTANCE/disable"

# After maintenance — restore alerting
curl -sk --header "user-token: $ACCESS_TOKEN" \
  -X PATCH "https://$DATASENTINEL_HOST/ds-api/alerting/$INSTANCE/enable"
```

You can also read current alert status, list active problems, or raise a **custom alert** from your own checks (for example, a failed backup):

```bash
cat > /tmp/alert.json <<EOF
{ "message": "Daily backup failed : No disk space" }
EOF

curl -sk --header "user-token: $ACCESS_TOKEN" \
  --header "Content-Type: application/json" \
  -X POST "https://$DATASENTINEL_HOST/ds-api/alerting/$INSTANCE/problems" \
  -d @/tmp/alert.json
```

{% content-ref url="/spaces/lcWi6G1jtNuyGT9C0pkc/pages/lHR5nxUxOqS7JkbTcc00" %}
[Alerting](/manual/implementation/platform-usage/api-reference/alerting.md)
{% endcontent-ref %}

***

## Agent API

When you install a [**local agent**](/manual/getting-started/installation/agent.md) on a host, that agent exposes its own API for managing its lifecycle and the connections it monitors.

Use it for agent-based deployments where each agent owns its connections directly.

### Authenticate

The Agent API listens on **port 8282** by default and authenticates with the `api-token` header. This token is your **Datasentinel license key** — the same one the agent uses to communicate with the platform.

```bash
export TOKEN=<<datasentinel_token>>
export AGENT_HOST=localhost      # or the host where the agent runs
```

{% hint style="info" %}
Read-only calls such as `status` do not require the token; state-changing calls (stop, configuration, connection management) do.
{% endhint %}

### Inspect an agent

```bash
curl -sk https://$AGENT_HOST:8282/api/agent/status
```

```json
{
  "version": "3.4.1",
  "server": "pg-sales-3127",
  "port": 8282,
  "collection-rate": "low",
  "connections": { "connections": 1, "running": 1, "not running": 0 }
}
```

### Add and monitor a connection

{% stepper %}
{% step %}

#### Create the connection

```bash
cat > /tmp/connection.json <<EOF
{
  "host": "pg-sales-3127",
  "port": 9342,
  "user": "datasentinel",
  "password": "sentinel",
  "tags": "application=sales,environment=production"
}
EOF

curl -sk --header "api-token: $TOKEN" \
  --header "Content-Type: application/json" \
  -X POST https://$AGENT_HOST:8282/api/connections/sales_prod \
  -d @/tmp/connection.json
```

```json
{ "status": "Connection created and connected!" }
```

{% endstep %}

{% step %}

#### Toggle per-connection collection features

Each connection's collection level is tuned independently:

```bash
# Enable query sample collection
curl -sk --header "api-token: $TOKEN" \
  -X PATCH https://$AGENT_HOST:8282/api/connections/sales_prod/enable-samples

# Set the lock-monitoring delay to 90 seconds
curl -sk --header "api-token: $TOKEN" \
  -X PATCH https://$AGENT_HOST:8282/api/connections/sales_prod/lock-monitoring-delay/90

# Disable table monitoring
curl -sk --header "api-token: $TOKEN" \
  -X PATCH https://$AGENT_HOST:8282/api/connections/sales_prod/disable-table-monitoring
```

{% endstep %}

{% step %}

#### Enable or disable connections in bulk

```bash
curl -sk --header "api-token: $TOKEN" \
  -X PATCH https://$AGENT_HOST:8282/api/connections/enable
```

{% endstep %}
{% endstepper %}

### Collection settings reference

The toggles above map directly to the [Collection Level](/manual/implementation/agent-usage/collection-level.md) feature. Common per-connection switches (all `PATCH` under `/api/connections/{name}/`):

<table><thead><tr><th width="320">Path suffix</th><th>Effect</th></tr></thead><tbody><tr><td><code>enable-samples</code> / <code>disable-samples</code></td><td>Query sample collection</td></tr><tr><td><code>enable-lock-monitoring</code> / <code>disable-lock-monitoring</code></td><td>Lock monitoring</td></tr><tr><td><code>lock-monitoring-delay/{seconds}</code></td><td>Lock-monitoring delay</td></tr><tr><td><code>enable-table-monitoring</code> / <code>disable-table-monitoring</code></td><td>Table &#x26; index activity</td></tr><tr><td><code>enable-query-monitoring</code> / <code>disable-query-monitoring</code></td><td>Query monitoring</td></tr><tr><td><code>query-monitoring-min-calls/{n}</code> / <code>query-monitoring-min-time/{s}</code></td><td>Query monitoring filters</td></tr><tr><td><code>enable-query-monitoring-optimize</code> / <code>disable-query-monitoring-optimize</code></td><td>Query monitoring optimization</td></tr></tbody></table>

The Agent API also manages the agent lifecycle (`status`, `stop`, `port`), the **upload server** it sends metrics to (`/api/server`), and an optional outbound **proxy** (`/api/proxy`).

{% content-ref url="/spaces/lcWi6G1jtNuyGT9C0pkc/pages/J9dSGVENOsIzGxqxpoKG" %}
[API Reference](/manual/implementation/agent-usage/api-reference.md)
{% endcontent-ref %}

***

## Full API reference

This guide covers the most common automation patterns. For the complete list of endpoints, parameters, request bodies, and response shapes, see the reference pages:

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><h4><i class="fa-link">:link:</i></h4></td><td><strong>Access Token</strong></td><td><a href="/spaces/lcWi6G1jtNuyGT9C0pkc/pages/pWMV9FXn2PVthWicFKyC">/spaces/lcWi6G1jtNuyGT9C0pkc/pages/pWMV9FXn2PVthWicFKyC</a></td></tr><tr><td><h4><i class="fa-plug">:plug:</i></h4></td><td><strong>Connection</strong></td><td><a href="/spaces/lcWi6G1jtNuyGT9C0pkc/pages/QzfvS4NlK6uuNUarhtfv">/spaces/lcWi6G1jtNuyGT9C0pkc/pages/QzfvS4NlK6uuNUarhtfv</a></td></tr><tr><td><h4><i class="fa-user-shield">:user-shield:</i></h4></td><td><strong>Role</strong></td><td><a href="/spaces/lcWi6G1jtNuyGT9C0pkc/pages/7OpT9RFUa8A64C7B8awR">/spaces/lcWi6G1jtNuyGT9C0pkc/pages/7OpT9RFUa8A64C7B8awR</a></td></tr><tr><td><h4><i class="fa-user">:user:</i></h4></td><td><strong>User</strong></td><td><a href="/spaces/lcWi6G1jtNuyGT9C0pkc/pages/PEkFNsuq5YqVposp2CLG">/spaces/lcWi6G1jtNuyGT9C0pkc/pages/PEkFNsuq5YqVposp2CLG</a></td></tr><tr><td><h4><i class="fa-file-pdf">:file-pdf:</i></h4></td><td><strong>Reporting</strong></td><td><a href="/spaces/lcWi6G1jtNuyGT9C0pkc/pages/Ax2GR2jf0dLwU2cYguRk">/spaces/lcWi6G1jtNuyGT9C0pkc/pages/Ax2GR2jf0dLwU2cYguRk</a></td></tr><tr><td><h4><i class="fa-chart-line">:chart-line:</i></h4></td><td><strong>Workload</strong></td><td><a href="/spaces/lcWi6G1jtNuyGT9C0pkc/pages/rRbgcGgDFLK6tQGcDYOL">/spaces/lcWi6G1jtNuyGT9C0pkc/pages/rRbgcGgDFLK6tQGcDYOL</a></td></tr><tr><td><h4><i class="fa-bell">:bell:</i></h4></td><td><strong>Alerting</strong></td><td><a href="/spaces/lcWi6G1jtNuyGT9C0pkc/pages/lHR5nxUxOqS7JkbTcc00">/spaces/lcWi6G1jtNuyGT9C0pkc/pages/lHR5nxUxOqS7JkbTcc00</a></td></tr><tr><td><h4><i class="fa-microchip">:microchip:</i></h4></td><td><strong>Agent API</strong></td><td><a href="/spaces/lcWi6G1jtNuyGT9C0pkc/pages/J9dSGVENOsIzGxqxpoKG">/spaces/lcWi6G1jtNuyGT9C0pkc/pages/J9dSGVENOsIzGxqxpoKG</a></td></tr></tbody></table>

## Best practices

* **Generate a fresh access token per run.** Platform tokens expire after 24 hours; don't persist them in pipelines.
* **Tag at creation time.** Tags drive filtering, consolidation, and RBAC — apply them when you register an instance, not after. See [**Organize Content using Tags**](/manual/guides/readme/organize-content-using-tags.md).
* **Drive RBAC from tags, not per-instance rules.** Define roles against a consistent tagging strategy so new instances are scoped automatically. See [**Manage Users and Role-Based Access**](/manual/guides/readme/manage-users-and-role-based-access.md).
* **Start from the toolkit.** The [**datasentinel\_toolkit**](https://github.com/datasentinel/datasentinel_toolkit) provides working scripts for most of these recipes.

## Conclusion

The Platform and Agent APIs together let you operate Datasentinel entirely as code — from onboarding instances and users to exporting metrics, scheduling reports, and integrating alerting into your existing workflows. Pick the Platform API for centralized, cross-instance automation, and the Agent API for per-agent and collection-level control.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.datasentinel.io/manual/guides/readme/automate-with-the-api.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.