---
title: "List the views of the client portal"
method: POST
path: "/portal-views/list"
tags: ["Portal Views"]
---

# List the views of the client portal

`POST /portal-views/list`

## Request

- Base URL: `https://api.reportingninja.com/v1`
- URL: `https://api.reportingninja.com/v1/portal-views/list`
- Auth: HTTP bearer

Returns the views of the client portal: which reports which client users see, in the order the portal menu shows them, and with which brand and which choice of periods.

## Request body

- PortalViewsListRequest: No parameters.

## Response `200`

The call succeeded. This endpoint reports its errors with a real HTTP status, so a 200 always carries status=ok.

- PortalViewsListResponse
  - `status` 'ok', required
  - `data` PortalViewsListData, required: The views of the client portal, ordered by name.
    - `portal_views` PortalView[], required
      - `portal_view_key` string, nullable, required
      - `name` string, nullable, required
      - `internal_notes` string, nullable: A note for the account's own staff. It is never shown in the portal.
      - `brand_template_key` string, nullable: The brand the portal wears for these users, or null for the default brand of the account.
      - `send_notification` boolean, required: Whether the users are emailed that the view is available.
      - `allow_to_change_date_range` boolean, required: Whether the users may change the period of what they see.
      - `date_range_option` 'all' | 'last_monthly_periods', nullable: Which periods the portal offers: every period, or only whole past months. These are the two values this version names; a view configured with a period choice added later is published with the value it is stored under, outside this list.
      - `report_keys` string[], required: The reports of the view, in the order of the portal menu.
      - `user_keys` string[], required: The client users who see it.
    - `count` integer, required
  - `meta` Meta, required
    - `request_id` string, required: Id of this request, useful when reporting an incident.
    - `timestamp` string, date-time, required: When the answer was built, in UTC.

## Other responses

- `400`: The request was refused before anything was written. INVALID_REQUEST covers the framework refusals of every endpoint (the Content-Type is not application/json, the body could not be read, the body is not valid JSON). The report endpoints add their own: VALIDATION_FAILED with details.problems, UNKNOWN_PARAM with the path of the field the endpoint does not read, and the single-field refusals MISSING_REQUIRED_FIELD, INVALID_VALUE and APPEND_NOT_ALLOWED. The description of each operation lists the ones it emits. Everything else a body can get wrong arrives as an entry of details.problems rather than as the code of the envelope.
- `401`: Invalid or missing Bearer token.
- `413`: The request body is over 1 MB. The cap is applied before authentication, so this answer is refused without the key being read, and it carries the usual error envelope.
- `429`: A budget was spent. RATE_LIMITED is the per-key read budget (300/minute, 5000/day) or the per-account write budget (60/minute, 1000/day). EMAIL_QUOTA_REACHED is the separate budget of 50 calls per account per day that send email, and its Retry-After points at the next UTC midnight. The Retry-After header gives the seconds until the more restrictive window resets. The X-RateLimit-* headers report the read budget, except on the 429 of a write, where they report the write budget.
- `500`: Internal server error.

---

[API](https://skmtc.dev/reportingninja/apis/reporting-ninja-api.md) · [All operations](https://skmtc.dev/reportingninja/apis/reporting-ninja-api/llms.txt) · [OpenAPI document](https://skmtc.dev/reportingninja/apis/reporting-ninja-api/revisions/13876c71be34?raw)