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

# List widget types for widget-data

> First step before calling `POST /applications/{applicationId}/widget-data`.

Returns widget type slugs you can pass in the request body field `types`. Each item includes:

- `id` — widget slug (use in the `types` array for widget-data)
- `category` — dashboard section this widget belongs to (for example `monitoring`, `guardrails`, `functional`, `security`, `rag`). Corresponds to `meta.source` in the widget-data response.
- `title` — human-readable label
- `description` — optional helper text



## OpenAPI

````yaml /openapi.json get /widgets
openapi: 3.0.0
info:
  title: Trusys API
  version: 1.0.0
  description: >-
    Programmatic access to Trusys for integrating AI quality monitoring,
    evaluation, and guardrails into your own systems — without using the Trusys
    UI.


    **Typical integration flow**


    1. `POST /applications` — register your application and get an id.

    2. `PUT /applications/{id}/monitoring` and/or `PUT
    /applications/{id}/guardrails` — configure which metrics, security plugins,
    and guardrails apply.

    3. `POST /applications/{id}/evaluations` — submit prompt/response traces to
    be scored as your application runs.

    4. `GET /applications/{id}/traces`, `GET /applications/{id}/evaluations`,
    and `POST /applications/{id}/widget-data` — pull results, trends, and
    dashboard-equivalent chart data back into your own tools.


    All requests require an `x-api-key` header (see Authentication). All
    timestamps are ISO 8601 UTC. Paginated endpoints default to 20 items per
    page (max 100).
servers:
  - url: https://app.trusys.ai/api/external
security:
  - ApiKeyAuth: []
paths:
  /widgets:
    get:
      tags:
        - Widgets
      summary: List widget types for widget-data
      description: >-
        First step before calling `POST
        /applications/{applicationId}/widget-data`.


        Returns widget type slugs you can pass in the request body field
        `types`. Each item includes:


        - `id` — widget slug (use in the `types` array for widget-data)

        - `category` — dashboard section this widget belongs to (for example
        `monitoring`, `guardrails`, `functional`, `security`, `rag`).
        Corresponds to `meta.source` in the widget-data response.

        - `title` — human-readable label

        - `description` — optional helper text
      operationId: listWidgets
      responses:
        '200':
          description: Widget catalog for widget-data requests.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/WidgetsCatalogResponse'
              example:
                success: true
                data:
                  - id: sessions-evaluated
                    category: monitoring
                    title: Sessions evaluated
                    description: Total sessions evaluated in the time range.
                  - id: guardrail-latency
                    category: guardrails
                    title: Guardrail latency
        '401':
          $ref: '#/components/responses/Unauthorized'
components:
  schemas:
    WidgetsCatalogResponse:
      type: object
      properties:
        success:
          type: boolean
        data:
          type: array
          items:
            $ref: '#/components/schemas/WidgetCatalogItem'
      required:
        - success
        - data
    WidgetCatalogItem:
      type: object
      required:
        - id
        - category
        - title
      properties:
        id:
          type: string
          description: Widget slug for `POST .../widget-data` body `types`.
        category:
          type: string
          description: 'Widget category: `monitoring` or `guardrails`.'
        title:
          type: string
        description:
          type: string
    ErrorResponse:
      type: object
      description: Standard error envelope for non-validation failures.
      properties:
        success:
          type: boolean
          example: false
          description: Always `false` for errors.
        message:
          type: string
          description: Human-readable explanation of the error.
      required:
        - success
        - message
  responses:
    Unauthorized:
      description: >-
        The API key is missing, invalid, or revoked. Verify the `x-api-key`
        header and that the key is active in Trusys settings.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/ErrorResponse'
          example:
            message: Error while verifying api key
  securitySchemes:
    ApiKeyAuth:
      type: apiKey
      in: header
      name: x-api-key
      description: >-
        Your Trusys API key. Create and manage keys in the Trusys UI under
        **Settings → API Keys**.


        Include the key on every request:


        ```

        x-api-key: <your-api-key>

        ```

````