---
title: "Get Portal Claim Status"
method: GET
path: "/v1/portal/claims/{claim_id}/status"
tags: ["portal"]
---

# Get Portal Claim Status

`GET /v1/portal/claims/{claim_id}/status`

## Request

- Base URL: `https://api.claims.zicron.ai`
- URL: `https://api.claims.zicron.ai/v1/portal/claims/{claim_id}/status`
- Auth: none declared

The claimant's view of their own case: stage and progress (minimum necessary; see the model).

Before 2026-09-28 this answered ``current_stage`` from ``workflow_state``
(a ``{id, name, completeness}`` dict there, so validating the response
failed with a 500) plus ``stage_description``/``next_steps``/``documents_needed``,
keys ``workflow_state`` never had; the portal page read ``lifecycle_stage``
and ``document_count``, which it never returned. Both fixed, additively.

## Path parameters

- `claim_id` string, required

## Response `200`

Successful Response

- PortalStatusResponse: What a claimant sees about their own case (``GET /portal/claims/{id}/status``). Minimum necessary: where the case is and how far our work on it has got. No medical content, no score, no names, no document titles: the claimant portal page (``app/portal/[id]/page.tsx``) shows the stage, the progress timeline, a document count and whether something awaits their signature. The first fields are the route's original ones, now filled from data that exists: ``current_stage`` is the id of the workflow stage the documents put the case in (``workflow_state.current_stage`` is a ``{id, name, completeness}`` dict, which used to fail validation: every read was a 500); ``next_steps`` are the names of the stages after it and ``documents_needed`` the document types it still misses (``workflow_state`` never had those keys, so they were always empty); ``stage_description`` describes the lifecycle stage. Added 2026-09-28 (additive), what the page reads: - ``lifecycle_stage``: the case's stage id (``claims.lifecycle_stage``; in the database one of unfiled, intake, evaluation, filing, filed, hearing, appeal, closed), with ``stage_name`` and ``stage_type`` from the claim type's workflow definition (``domain/workflow.py``; null for an id it doesn't define, which is most of them: the page then shows the id in words); - ``disposition``: open, closed or delivered (our work on the case is done); - ``document_count``: files on the case (a split file once, deleted ones not at all) and ``documents_reviewed``, how many are fully processed; - ``pending_contracts``: contracts sent to be signed and not yet signed; - ``has_analysis``: the case has been scored (the score itself is not sent).
  - `claim_id` string, required
  - `claim_type` string, required
  - `status` string, required
  - `current_stage` string, nullable
  - `stage_description` string, nullable
  - `next_steps` string[]
  - `documents_needed` string[]
  - `last_updated` string, required
  - `lifecycle_stage` string
  - `disposition` string
  - `stage_name` string, nullable
  - `stage_type` string, nullable
  - `document_count` integer
  - `documents_reviewed` integer
  - `pending_contracts` integer
  - `has_analysis` boolean

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/zicron/apis/zicron-api.md) · [All operations](https://skmtc.dev/zicron/apis/zicron-api/llms.txt) · [OpenAPI document](https://skmtc.dev/zicron/apis/zicron-api/revisions/abe62e22aa46?raw)