> ## 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. # Count your verifications > Count how your verifications stand, in total and per workflow. Every verification in your API key's environment is counted, whichever of its workflows the verification runs, unless you narrow it to a period with `from` and `to`. Those are read against the day a verification was created, so a period counts the runs that began in it and reports where each of them stands now. These are counts of statuses and of nothing else. A run counted as `completed` is one that finished, not one that passed: a verification can complete with a step that failed. Read a verification, or list them, to see what a count is made of. ## OpenAPI ````yaml /verification/api-reference/openapi.json get /verifications/summary 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: /verifications/summary: get: tags: - Results summary: Count your verifications description: >- Count how your verifications stand, in total and per workflow. Every verification in your API key's environment is counted, whichever of its workflows the verification runs, unless you narrow it to a period with `from` and `to`. Those are read against the day a verification was created, so a period counts the runs that began in it and reports where each of them stands now. These are counts of statuses and of nothing else. A run counted as `completed` is one that finished, not one that passed: a verification can complete with a step that failed. Read a verification, or list them, to see what a count is made of. operationId: read_verification_summary_verifications_summary_get parameters: - name: from in: query required: false schema: anyOf: - type: string format: date - type: 'null' description: First day to include, in IST, inclusive. title: From description: First day to include, in IST, inclusive. - name: to in: query required: false schema: anyOf: - type: string format: date - type: 'null' description: Last day to include, in IST, inclusive. title: To description: Last day to include, in IST, inclusive. responses: '200': description: Your verifications counted by status, in total and per workflow. content: application/json: schema: $ref: '#/components/schemas/VerificationSummary' example: counts: total: 1292 open: 42 submitted: 3 completed: 1180 cancelled: 9 gated: 8 failed: 0 expired: 50 workflows: - workflow_key: merchant-onboarding counts: total: 1006 open: 30 submitted: 2 completed: 920 cancelled: 8 gated: 6 failed: 0 expired: 40 - workflow_key: vendor-verification counts: total: 286 open: 12 submitted: 1 completed: 260 cancelled: 1 gated: 2 failed: 0 expired: 10 '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 API key is valid but not enrolled for verifications, or is not set up for exactly one of `uat` and `production`. Ask us to reissue it. The code is `client-not-enrolled`. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' example: code: client-not-enrolled detail: >- no active verification client 4b8f21c6-59ad-4a70-9e11-7c3d0a52f8b4 '422': description: |- The period asked for runs backwards. The code is `window-invalid`. content: application/json: example: code: window-invalid detail: 'from: must not be after to' 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: VerificationSummary: properties: counts: $ref: '#/components/schemas/StatusCounts' description: Every verification counted, across all your workflows. workflows: items: $ref: '#/components/schemas/WorkflowCounts' type: array title: Workflows description: >- The same verifications counted per workflow, ordered by key. A workflow appears once it has one in what was counted, so a workflow nobody has been sent through is absent. type: object required: - counts - workflows title: VerificationSummary description: How your verifications stand, counted in total and per workflow. 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. StatusCounts: properties: total: type: integer title: Total description: How many verifications were counted. open: type: integer title: Open description: Runs that are live, where the user may still act. submitted: type: integer title: Submitted description: Runs the user has finished, whose result is final. completed: type: integer title: Completed description: Runs whose work after the submission is done, and safe to read. cancelled: type: integer title: Cancelled description: Runs you ended. gated: type: integer title: Gated description: Runs a check of yours stopped, which use no credit. failed: type: integer title: Failed description: Runs that reached an unrecoverable state. expired: type: integer title: Expired description: >- Runs whose retention window has run out, whatever they had ended as. Everything the user provided is deleted and the record is kept for your audit alone, so read `completed_at` on one of these rather than the count to tell how it had ended. type: object required: - total - open - submitted - completed - cancelled - gated - failed - expired title: StatusCounts description: >- Verifications counted by status; total equals the sum of the other fields. WorkflowCounts: properties: workflow_key: type: string title: Workflow Key description: The workflow the counts belong to. counts: $ref: '#/components/schemas/StatusCounts' description: Its verifications, counted by status. type: object required: - workflow_key - counts title: WorkflowCounts description: One workflow's verifications, counted by status. 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.