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

# List a workflow's versions

> List every version a workflow has published, newest first.

A change to a workflow is published as its next version, and a verification runs the version it was created on until it is reset. Every verification names its version in `version`: read that version to see the journey the verification runs, and read two versions to see what changed between them.

A workflow taken out of use keeps its versions, so one you can no longer create a verification on still lists them for the verifications that ran it.



## OpenAPI

````yaml /verification/api-reference/openapi.json get /workflows/{workflow_key}/versions
openapi: 3.1.0
info:
  title: Verify with Privue
  description: >-
    Start identity-and-business verifications and read the results.


    There are three ways to run one, and a verification reads the same whichever
    it was. Every workflow declares which it is for as its `mode`, and a
    workflow is one of them and never more.


    **Hosted.** You create a verification with the user's mobile number and
    receive a journey URL to hand to them. They work through the steps your
    workflow configures, on our screens, and submit. Use this when the person
    being verified is reachable and holds their own documents.


    **Staged.** You create a verification, upload each document you hold against
    the step it answers, and ask for the checks to run. They take longer than a
    request should be held open, so you read the result from a callback or by
    polling. Use this when documents reach you over time, or when you want them
    kept on the record to download later.


    **Instant.** You send the whole submission in one request. The checks run
    before it answers, so the reply is the finished record. The documents are
    read as they arrive and stored nowhere. Use this when you hold everything
    already and want the answer in the call you made.


    Whichever it was, you read the whole record: every step, its state, what it
    collected, and why anything did not pass. An instant verification hands you
    that record in its reply; for the other two, poll the verification or
    register a callback endpoint and be told when it is submitted.


    Across your whole account you can list the workflows configured for you,
    count your verifications by status, and page through the records behind a
    count.


    Every error response has the shape `{"code": "...", "detail": "..."}`.
    Branch on `code`: several causes share a status, and `detail` is written for
    a person reading a log rather than for code. Treat a code you do not
    recognise as the status it arrived at.
  version: 0.1.0
servers:
  - url: https://api.verify.privue.ai
    description: Production
security: []
tags:
  - name: Workflows
    description: >-
      The workflows configured for your account. Read one to see its mode, the
      documents it asks for, and how each step is answered over the API: the
      slots its documents go in and the values it takes.
  - name: Verifications
    description: >-
      Starting a verification, ending one, clearing one to run the same subject
      again, and purging one. Shared by both modes. A start answers 201 when it
      created the verification and 200 when the subject already had one, so a
      duplicate is visible from the status code alone.
  - name: Hosted workflows
    description: >-
      For a workflow the person being verified walks themselves. Start a
      verification with their mobile number, hand them the journey URL on the
      record, or open it for them from inside your own app with a handoff.
  - name: Staged workflows
    description: >-
      For a workflow you build up from documents you already hold. Upload each
      file against the step and slot it answers, withdraw one you got wrong,
      then ask for the checks to run and read the result when they have. Nobody
      is sent anywhere.
  - name: Instant workflows
    description: >-
      For a workflow answered in the request that asks it. Send the whole
      submission at once and read the finished record in the reply. Nothing is
      kept of the documents and nothing is left open to come back to.
  - name: Results
    description: >-
      Reading what a verification came to: one record, a page of them, counts
      across your account, and links to the files it holds.
paths:
  /workflows/{workflow_key}/versions:
    get:
      tags:
        - Workflows
      summary: List a workflow's versions
      description: >-
        List every version a workflow has published, newest first.


        A change to a workflow is published as its next version, and a
        verification runs the version it was created on until it is reset. Every
        verification names its version in `version`: read that version to see
        the journey the verification runs, and read two versions to see what
        changed between them.


        A workflow taken out of use keeps its versions, so one you can no longer
        create a verification on still lists them for the verifications that ran
        it.
      operationId: read_workflow_versions_workflows__workflow_key__versions_get
      parameters:
        - name: workflow_key
          in: path
          required: true
          schema:
            type: string
            title: Workflow Key
      responses:
        '200':
          description: Every version the workflow has published, newest first.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/WorkflowVersionList'
              example:
                versions:
                  - version: 3
                    published_at: '2026-08-10T17:45:30'
                  - version: 2
                    published_at: '2026-08-04T11:20:05'
                  - version: 1
                    published_at: '2026-07-14T16:02:47'
        '400':
          description: >-
            No workflow of yours has ever carried that key, whether or not it is
            still in use.


            The code is `workflow-not-found`.
          content:
            application/json:
              example:
                code: workflow-not-found
                detail: client 'acme' has no workflow 'merchant-onboarding'
              schema:
                $ref: '#/components/schemas/ErrorResponse'
        '401':
          description: |-
            The API key is missing, malformed, or revoked.

            The code is `unauthenticated`.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorResponse'
              example:
                code: unauthenticated
                detail: Missing or malformed Authorization header
        '403':
          description: >-
            The workflow belongs to the other environment. An API key is for
            `uat` or for `production` and reaches only that environment's
            workflows. Or the key is valid but not enrolled for verifications,
            or not set up for exactly one of `uat` and `production`, in which
            case ask us to reissue it.


            The code is one of `environment-mismatch` or `client-not-enrolled`.
          content:
            application/json:
              example:
                code: environment-mismatch
                detail: >-
                  workflow 'merchant-onboarding' is production and this request
                  is for uat
              schema:
                $ref: '#/components/schemas/ErrorResponse'
        '422':
          description: |-
            An identifier in the path is not in the shape it takes.

            The code is `request-invalid`.
          content:
            application/json:
              example:
                code: request-invalid
                detail: >-
                  verification_id: Input should be a valid UUID, invalid
                  character: found `n` at 1
              schema:
                $ref: '#/components/schemas/ErrorResponse'
        '429':
          description: |-
            The API key is rate limited. Retry after a pause.

            The code is `rate-limited`.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorResponse'
              example:
                code: rate-limited
                detail: 'Unauthorized: RATE_LIMITED'
        '503':
          description: |-
            API keys could not be checked right now. Retry.

            The code is `auth-unavailable`.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorResponse'
              example:
                code: auth-unavailable
                detail: Auth provider unavailable
      security:
        - HTTPBearer: []
components:
  schemas:
    WorkflowVersionList:
      properties:
        versions:
          items:
            $ref: '#/components/schemas/WorkflowVersionEntry'
          type: array
          title: Versions
          description: Newest first, so the first entry is the latest version.
      type: object
      required:
        - versions
      title: WorkflowVersionList
      description: Every version a workflow has published.
    ErrorResponse:
      properties:
        code:
          $ref: '#/components/schemas/ErrorCode'
          description: >-
            What went wrong. Branch on this rather than on the status code,
            which several causes share, and never on `detail`.


            Treat a code you do not recognise as the status it arrived at: codes
            are added as new causes become reachable, and an existing one never
            changes meaning.
        detail:
          type: string
          title: Detail
          description: >-
            What went wrong, in words, naming the workflow, verification, step
            or field at fault where one is. Written for a person reading a log
            rather than for code to read, so it is not stable and nothing should
            be matched against it.
      type: object
      required:
        - code
        - detail
      title: ErrorResponse
      description: The envelope every failure is answered in.
    WorkflowVersionEntry:
      properties:
        version:
          type: integer
          minimum: 1
          title: Version
          description: >-
            The version's number. Versions are numbered from 1, and the highest
            is the latest: the one a verification created now runs.
        published_at:
          type: string
          format: date-time
          title: Published At
          description: When this version was published.
      type: object
      required:
        - version
        - published_at
      title: WorkflowVersionEntry
      description: One version of a workflow, as the list of its versions names it.
    ErrorCode:
      type: string
      enum:
        - unauthenticated
        - client-not-enrolled
        - rate-limited
        - auth-unavailable
        - environment-mismatch
        - request-invalid
        - body-unreadable
        - page-cursor-invalid
        - window-invalid
        - request-too-large
        - not-found
        - method-not-allowed
        - internal-error
        - workflow-not-found
        - workflow-version-not-found
        - workflow-not-runnable
        - workflow-not-walkable
        - workflow-misconfigured
        - context-incomplete
        - context-value-invalid
        - mobile-required
        - journey-fields-refused
        - return-url-not-allowed
        - reference-taken
        - verification-not-found
        - verification-not-open
        - verification-expired
        - run-in-progress
        - credits-exhausted
        - resets-exhausted
        - live-limit-reached
        - step-not-found
        - step-not-ready
        - step-invalid
        - document-not-found
        - document-not-stored
        - document-too-large
        - document-type-not-allowed
      title: ErrorCode
      description: >-
        What went wrong, as a value to branch on.


        Published vocabulary, stated here rather than shared with any other
        product of ours: these are read by integrations we do not control, so a
        name here means what it says for as long as the endpoint answering it
        exists.


        One code names one cause, so a status carrying several causes is told
        apart by the code and never by the message. Codes are added as new
        causes become reachable; an integration therefore treats an unrecognised
        code as the status it arrived at.
  securitySchemes:
    HTTPBearer:
      type: http
      scheme: bearer

````

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