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

# Most recent chat

> Return the caller's most recent Extract chat.

The caller's latest Extract thread. **404** if they have none — create first.


## OpenAPI

````yaml GET /api/v2/chats/recent/
openapi: 3.1.0
info:
  title: Abacus Docs API
  version: 1.0.0
  description: |
    REST + SSE surface for Abacus Docs on the same host as the web app
    (`https://abacusdocs.com`). Paths are `/api/v2/…`.

    Authenticate with an organisation API key (`sk-abacus-*`) as a Bearer
    token, or an Auth0 access token. Cross-tenant reads return **404**, not
    403. Page-based lists use `?page=` and `?page_size=`.

    Extraction, reprocess, schema tests, and chat turns spend credits.
    See the help centre Credits pages for rates.
  contact:
    name: Abacus Docs
    url: https://abacusdocs.com/contact
servers:
  - url: https://abacusdocs.com
    description: Production (Extract)
security: []
paths:
  /api/v2/chats/recent/:
    get:
      tags:
        - v2/chats
      summary: List the caller's most recent Extract chats
      description: >-
        Returns the ``limit`` most-recently-updated Extract chats (default 10,
        max 50). Convenience endpoint for the SPA's 'recent chats' nav section —
        same row shape as the list endpoint, no pagination.
      operationId: v2_chats_recent_list
      parameters:
        - in: query
          name: limit
          schema:
            type: integer
          description: Number of recent chats (default 10, clamped to [1, 50]).
      responses:
        '200':
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/ChatSummary'
          description: ''
      security:
        - extractApiKey: []
        - bearerAuth: []
        - cookieAuth: []
components:
  schemas:
    ChatSummary:
      type: object
      description: |-
        Response shape for a single chat (list item AND detail).

        A plain ``Serializer`` (not ``ModelSerializer``) because the
        ``*_count`` fields are queryset annotations, not model fields — the
        view layers them on via
        :func:`deckmonkey.api_v2.chats.views._annotated_chat_qs` (one query,
        no per-row N+1). DRF reads each field as an attribute off the model
        instance, so the annotations surface transparently alongside the
        real columns.

        Fields:
            id / thread_id / title / workflow_type / created_at / updated_at /
            is_active: straight off the ``Chat`` row.
            message_count: ``ChatMessage`` rows in the thread.
            batch_count: attached batches (``ChatBatchAttachment`` join rows).
            attachment_count: documents uploaded directly into this chat
                (``ChatAttachment`` rows whose ``chat`` is this chat).
            linked_count: documents linked in from another chat
                (``ChatAttachmentLink`` rows) — Decision 8 LINK semantics.
      properties:
        id:
          type: integer
          readOnly: true
        thread_id:
          type: string
          readOnly: true
        title:
          type: string
          readOnly: true
        workflow_type:
          type:
            - string
            - 'null'
          readOnly: true
        created_at:
          type: string
          format: date-time
          readOnly: true
        updated_at:
          type: string
          format: date-time
          readOnly: true
        is_active:
          type: boolean
          readOnly: true
        message_count:
          type: integer
          readOnly: true
        batch_count:
          type: integer
          readOnly: true
        attachment_count:
          type: integer
          readOnly: true
        linked_count:
          type: integer
          readOnly: true
      required:
        - attachment_count
        - batch_count
        - created_at
        - id
        - is_active
        - linked_count
        - message_count
        - thread_id
        - title
        - updated_at
        - workflow_type
  securitySchemes:
    extractApiKey:
      type: http
      scheme: bearer
      bearerFormat: API Key
      description: |
        Organisation API key from Settings → API / `/api/keys/`. The secret is
        shown once. Send `Authorization: Bearer sk-abacus-…`. One active key
        per organisation. Ingest (`/api/v2/ingest/*`) refuses API keys — that
        surface is Auth0-only with `ingest:read` / `ingest:write` scopes.
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT
      description: >
        Auth0 access token for a signed-in user. Send `Authorization: Bearer
        <token>`.

        The SPA and desktop agent use this. Prefer an organisation API key for

        server-to-server integrations.
    cookieAuth:
      type: apiKey
      in: cookie
      name: sessionid
      description: |
        Django session cookie from a browser login. Present so the web app can
        call `/api/v2` without a header. Do not rely on this for integrations.

````