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

# Look up whether turns were learned into memory

> Reports whether the turns of a request were learned into memory. With `request_id`, it lists every turn that request produced in this thread, each `learned`, `pending`, or `not_learned`. Without it, it returns a page of the turns in this thread that were not learned, newest first. The `learning` lists on `observe-and-respond`, `observe-and-enrich`, and `chat` responses come from the same record, and report each turn that was not learned at least once. Turns sent with `observe` or `observe-file` report on their observation status instead.




## OpenAPI

````yaml /openapi.yaml get /v1/agents/{agent_id}/threads/{thread_id}/learning
openapi: 3.0.3
info:
  title: Priors API
  description: >
    Priors gives you memory agents. An agent learns from the observations you
    send it and answers from what it learned.


    You call this API from your own backend with a partner API key. The key
    identifies your organization, which owns every agent, thread, observation,
    source, and memory it creates. Another organization receives 404 for those
    identifiers. Send `X-SP-End-User` alongside the key to act for one named
    person on your side.
  version: 0.1.0
servers:
  - url: https://app.sapientpriors.com/api
    description: Production
security:
  - partnerKey: []
tags:
  - name: Agents
    description: Create, read, update, and delete memory agents.
  - name: Threads
    description: 'Conversations under an agent: create them, teach them, and ask them.'
  - name: Sources
    description: Files an agent learned from, and the citations that point back to them.
  - name: Authentication
    description: What your key resolves to, and the limits that apply to it.
  - name: Billing
    description: Your organization's credits and charges.
paths:
  /v1/agents/{agent_id}/threads/{thread_id}/learning:
    get:
      tags:
        - Threads
      summary: Look up whether turns were learned into memory
      description: >
        Reports whether the turns of a request were learned into memory. With
        `request_id`, it lists every turn that request produced in this thread,
        each `learned`, `pending`, or `not_learned`. Without it, it returns a
        page of the turns in this thread that were not learned, newest first.
        The `learning` lists on `observe-and-respond`, `observe-and-enrich`, and
        `chat` responses come from the same record, and report each turn that
        was not learned at least once. Turns sent with `observe` or
        `observe-file` report on their observation status instead.
      operationId: get_thread_learning
      parameters:
        - $ref: '#/components/parameters/AgentId'
        - $ref: '#/components/parameters/ThreadId'
        - $ref: '#/components/parameters/EndUser'
        - name: request_id
          in: query
          description: >
            The `request_id` you sent to `observe-and-respond` or
            `observe-and-enrich` (or the `x-request-id` header of its response),
            or the `turn_id` of a `chat` message.
          schema:
            type: string
            minLength: 1
            maxLength: 200
        - name: before
          in: query
          description: The next_cursor of the previous page.
          schema:
            type: string
            pattern: ^[0-9]{1,10}$
        - name: limit
          in: query
          schema:
            type: integer
            minimum: 1
            maximum: 100
            default: 50
      responses:
        '200':
          description: Learning status of one request, or one page of not-learned turns
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/LearningStatusResponse'
        '400':
          $ref: '#/components/responses/BadRequest'
        '401':
          $ref: '#/components/responses/Unauthorized'
        '403':
          $ref: '#/components/responses/Forbidden'
        '404':
          $ref: '#/components/responses/NotFound'
components:
  parameters:
    AgentId:
      name: agent_id
      in: path
      required: true
      description: Unique managed memory-agent identifier.
      schema:
        type: string
        maxLength: 32
        pattern: ^agent_[0-9A-HJKMNP-TV-Z]{26}$
    ThreadId:
      name: thread_id
      in: path
      required: true
      description: Unique thread identifier scoped to the agent.
      schema:
        type: string
        maxLength: 33
        pattern: ^thread_[0-9A-HJKMNP-TV-Z]{26}$
    EndUser:
      name: X-SP-End-User
      in: header
      required: false
      description: >
        Your own identifier for the person this request acts for: an account
        number, a row id, anything stable on your side. It works only with a
        partner API key. The value is not stored. Priors hashes it together with
        your organization id, so two clients that send the same string are still
        two different people.


        With the header, you reach the threads that same person created and no
        others. A new thread is recorded against that person, and `GET
        /v1/agents/{agent_id}` returns that person's conversations only. Without
        the header, the key acts as the organization and reaches every thread on
        every agent it owns. Learned memory is shared across the agent either
        way. Only the thread list narrows.


        Sent with anything that is not a partner API key, the header returns 400
        instead of being ignored. Sent empty or as whitespace, it also returns
        400, and it is never read as absent: absent means the whole
        organization, which is wider access than you asked for. Surrounding
        whitespace is removed. The 255-character limit is measured on the value
        as sent.
      schema:
        type: string
        minLength: 1
        maxLength: 255
        pattern: \S
  schemas:
    LearningStatusResponse:
      type: object
      required:
        - agent_id
        - thread_id
        - items
      properties:
        agent_id:
          $ref: '#/components/schemas/AgentId'
        thread_id:
          $ref: '#/components/schemas/ThreadId'
        items:
          type: array
          items:
            $ref: '#/components/schemas/LearningItem'
        next_cursor:
          type: string
          nullable: true
          description: >
            Send it as `before` to read the next page of turns that were not
            learned. Null on the last page, and always null when you sent
            `request_id`.
      additionalProperties: false
    AgentId:
      type: string
      pattern: ^agent_[0-9A-HJKMNP-TV-Z]{26}$
      description: Server-generated agent identifier.
    ThreadId:
      type: string
      pattern: ^thread_[0-9A-HJKMNP-TV-Z]{26}$
      description: Server-generated thread identifier.
    LearningItem:
      type: object
      description: >
        Whether one turn of a request was learned into memory. A turn is not
        learned when writing its memory failed after the response was returned.
        It is never learned later: send it again to have it learned.
      required:
        - request_id
        - role
        - status
      properties:
        request_id:
          type: string
          description: >
            The id you know the request by: the `request_id` you sent to
            `observe-and-respond` or `observe-and-enrich` (or the `x-request-id`
            header of its response), or the `turn_id` of a `chat` message.
        role:
          type: string
          enum:
            - user
            - assistant
          description: >
            `user` is the turn you sent. `assistant` is the answer Priors wrote
            and learned (`chat`, and `observe-and-respond` with `learn_reply`).
        status:
          type: string
          enum:
            - learned
            - pending
            - not_learned
          description: >
            `learned`: in memory. `pending`: still being learned. `not_learned`:
            will never be learned; send it again. The `learning` lists on
            responses carry only `not_learned`.
        reason:
          type: string
          nullable: true
          description: >
            Stable machine code for why a turn was not learned, for example
            `generation_failed`, `model_unavailable`, `generation_timeout`,
            `generation_unparseable`, `memory_commit_shortfall`,
            `embedder_mismatch`, or `earlier_turn_failed` (dropped because a
            turn before it failed). Treat an unknown code like
            `generation_failed`. Null unless `not_learned`.
        message:
          type: string
          nullable: true
          description: A sentence to show a person. Null unless `not_learned`.
        refunded_credits:
          type: string
          nullable: true
          pattern: ^-?\d+(\.\d+)?$
          description: >
            Credits refunded for this turn, as a decimal string. Null when
            nothing was refunded for it: nothing was charged, or it is an answer
            Priors wrote, which was delivered and stays charged.
        action:
          type: string
          nullable: true
          enum:
            - resend
            - null
          description: '`resend` when `not_learned`, else null.'
      additionalProperties: false
    ErrorResponse:
      type: object
      required:
        - error
        - code
        - request_id
      properties:
        error:
          type: string
        code:
          type: string
          description: >
            Machine-readable condition. Branch on this rather than on the status
            where the two differ. All three of these can arrive as a 5xx and
            they want different handling: `service_unavailable` (503) is a
            dependency outage worth retrying, `service_not_configured` (503) is
            the same transport failure that retrying will NEVER clear because a
            feature is not switched on for your organization, and
            `internal_error` (500) is a defect that will fail the same way
            again. Known values: invalid_request, unauthorized, forbidden,
            payment_required, not_found, agent_not_found, thread_not_found,
            conflict, agent_quota_exceeded, duplicate_upload_in_progress,
            document_already_ingested, document_uploaded_elsewhere,
            agent_not_ready, payload_too_large, rate_limit_exceeded,
            service_unavailable, service_not_configured,
            answer_model_unavailable, internal_error, and the document codes an
            upload can return (unsupported_document, document_needs_ocr,
            encrypted_document, malformed_document, empty_document,
            document_too_large, document_too_complex, document_too_many_turns,
            document_too_many_pages, document_too_large_for_ocr,
            document_pages_unexpected, document_service_unavailable, ocr_busy,
            ocr_failed, ingestion_failed).


            answer_model_unavailable is a narrower `service_unavailable` (503):
            the model that writes the visible reply could not be reached after
            retries. It is worth its own code because it is the one dependency
            whose outage a caller may want to word differently -- the turn
            produced no answer at all, and retrying shortly is the right advice.


            agent_not_found and thread_not_found are narrower `not_found`s, sent
            so a client can tell WHICH resource vanished and recover accordingly
            without matching on the English message. Treat any unrecognised
            value as the status code's default meaning rather than rejecting the
            response.
        request_id:
          type: string
          description: >
            Server-issued identifier for this request. Include it when reporting
            a problem so the call can be correlated with server logs.
        details:
          type: string
          description: |
            Present on a 429. Names which control refused the request:
              `user`                    Your per-subject window, counted against `X-SP-End-User`.
              `organization`            Your organization's ceiling, across every key you hold.
              `capacity`                The service is at capacity. Retry.
              `ingestion-organization`  Too much of your own document work is already running.
              `ingestion-capacity`      As above, service-wide.
      additionalProperties: false
  responses:
    BadRequest:
      description: >
        The request is not one this route can act on, and sending it again
        unchanged does not help. Usually the payload: a field missing, or a
        value out of range.


        It is also the credential and the headers around it, and each of these
        is refused rather than ignored: `X-SP-End-User` sent empty, or longer
        than 255 characters; and a key on a request that carries
        `Sec-Fetch-Site`, which only a browser sets.


        `code` is `invalid_request` throughout. `error` says which of these it
        was.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/ErrorResponse'
    Unauthorized:
      description: Missing or invalid credentials
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/ErrorResponse'
    Forbidden:
      description: |
        The credential is valid but may not take this action.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/ErrorResponse'
    NotFound:
      description: >
        No such id, or it is not one this key reaches. It is never a 403, so a
        key cannot be used to learn which ids exist.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/ErrorResponse'
  securitySchemes:
    partnerKey:
      type: http
      scheme: bearer
      description: >
        Your API key, shaped `sp_<key_id>_<secret>`, sent as `Authorization:
        Bearer sp_...`. It identifies your organization, not a person. Your
        organization owns the agents, holds the credit, and is billed. Every key
        your organization holds reaches the same things, so you rotate a key by
        minting the new one, deploying it, and revoking the old one.


        Keep the key on your server. A request that carries a `Sec-Fetch-Site`
        header is refused with 400, because only a browser sets that header.
        Priors sends no CORS headers, so a browser blocks the call before it
        leaves the page. The secret is shown once when the key is minted and is
        stored only as a hash. A lost secret is replaced, never recovered.


        An administrator of your organization mints and revokes keys in the
        Priors application, under Settings. There is no endpoint for it: a key
        reaches your whole organization, so issuing one is an act of
        administration.

````

This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.