# Get Subscriptions

> Overview Retrieves a paginated list of subscriptions from the NIZU Cloud API Client service. Although this request uses the GET method, it currently sends a small JSON payload in the raw bod (Subscri…

- Page: https://dashboard.nizu.io/knowledge_base/view/199-get-subscriptions
- Part of: [Knowledge base](https://dashboard.nizu.io/knowledge_base/llms.txt) on NIZU — https://dashboard.nizu.io/llms.txt
- Updated: 2026-10-25T11:50:03Z

Overview
 Retrieves a paginated list of subscriptions from the NIZU Cloud API Client service. Although this request uses the GET method, it currently sends a small JSON payload in the raw body to select the module ("subscriptions"). The endpoint is referenced via the [https://api.nizu.io/v2/](https://api.nizu.io/v2/) variable so it can point to different environments.

 Authentication

 - Type: Bearer token

 - Source: {{client_token}} (from the active environment)

 - How to use: Set the request auth to Bearer and reference the environment variable. If inherited from the folder/collection, ensure {{client_token}} is defined.

 Method and URL

 - Method: GET

 - URL: {{base_url}}

 Path and Query Parameters

 - Path params: None

 - Query params: None in the saved request. Pagination and filtering are not passed as query params in this request; the server returns a paginated response by default.

 Request Body
 Note: This request is a GET but carries a raw JSON body that selects the module.

 - Body (raw, JSON):

 ``` json
 {
 "module": "subscriptions",
 "data": {}
 }

 ```

 - Schema:

 - module: string (required) fixed value "subscriptions" for this request

 - data: object (optional) reserved for future parameters; currently empty

 Expected Responses

 - 200 OK Successful fetch of subscriptions list

 - 201 Created Some servers may return 201 in success scenarios (per test); functionally treated as success

 Response Body Shape (200 example observed)
 Top-level fields:

 - success: boolean indicates overall success

 - data: object

 - content: array list of subscription records

 - total: number total count of records available server-side (e.g., 705)

 Subscription object (representative keys from latest response):

 - id: string internal identifier

 - title: string product or plan label

 - client_id: string customer identifier

 - bill_date: string (YYYY-MM-DD) first billing date

 - end_date: string|null (YYYY-MM-DD) end/cancel date if cancelled

 - note: string free-form note

 - labels: string labels/tags (string-encoded)

 - status: string one of active|cancelled

 - payment_status: string e.g., success

 - tax_id, tax_id2: string tax references

 - repeat_every: string recurrence cadence value (e.g., "1")

 - repeat_type: string recurrence unit (e.g., months)

 - no_of_cycles: string configured number of cycles ("0" often means unlimited)

 - next_recurring_date: string|null (YYYY-MM-DD) next charge date if active

 - no_of_cycles_completed: string cycles completed

 - cancelled_at: string|null timestamp of cancellation

 - cancelled_by: string user id who cancelled

 - files: string serialized attachment info

 - company_id: string company/tenant id

 - deleted: string soft-delete flag ("0" or "1")

 - type: string provider (e.g., stripe)

 - stripe_subscription_id: string Stripe subscription id

 - stripe_product_id: string Stripe product id

 - stripe_product_price_id: string Stripe price id

 Usage Notes

 - Ensure {{client_token}} is valid and has permission to read subscriptions.

 - The server returns a paginated list inside data.content and a total count in data.total. If you need specific pagination controls, consult the API for supported parameters; this saved request does not send pagination inputs.

 - Some fields are strings even when numeric (e.g., ids, flags). Cast as needed in clients.

 - Status combinations:

 - status: active with next_recurring_date set → recurring subscription

 - status: cancelled with end_date set → ended subscription

 Variables Used

 - {{client_token}} bearer auth token

 Changelog for this request description

 - Added comprehensive docs: purpose, auth, parameters, request/response schema, and usage guidance based on the latest successful 200 response.