---
title: "List the published plan ladder"
method: GET
path: "/v2/plans"
---

# List the published plan ladder

`GET /v2/plans`

The plans a customer can buy, with prices, included credits and usage limits.

Anonymous: the pricing page renders before login. Identical for every caller, so nothing
here is account-scoped.

Prices come from the **active** published catalogue version — what a new signup would be
sold. An existing account keeps resolving against the version it was sold on, which is
reported by ``GET /v2/users/me/entitlements`` instead.

Enterprise is not listed: it is a custom contract rather than a self-serve rung.

**Feature availability is not published on this endpoint.** The catalogue grants every
feature to every tier, which contradicts the advertised per-plan feature matrix — and it is
not even accurate about the backend any more, since API access is gated by a tier floor in
``module.plans.api_access`` rather than through the catalogue. Publishing the catalogue's
view would put a wrong claim next to a correct price. The field is added when a version
publishes real floors.

## Response `200`

Successful Response

- PlansResponse — The published ladder a customer can buy from. ``plans`` is a **list ordered by tier**, not an object keyed by it: JSON object key order is not guaranteed by the format, and a pricing page needs a stable rung order. Enterprise (tier 9) is **absent**. It is a real rung and it resolves normally on :class:`EntitlementsResponse`, but the catalogue's entry for it is deliberately near-empty (price 0, grant 0) because a custom contract fully overrides it — so publishing it here would render a "$0 Enterprise, 0 credits" row on the price list. Enterprise is contact-sales, not a self-serve rung.
  - `catalog_version` integer, required — Published catalogue version these prices come from. An account keeps resolving against the version it was sold on, so this is the version a NEW signup would get.
  - `plans` PlanResponse[], required — Self-serve rungs, ascending by tier.
    - `tier` integer, required — Numeric rung: 0 Free, 1 Pro, 2 Max 5x, 3 Max 20x, 4 Max 50x.
    - `display_name` string, required — Customer-facing plan name, e.g. 'Max 5x'.
    - `price_usd_monthly` number, required — Monthly list price in USD.
    - `price_usd_annual` number, required — Annual list price in USD. Published for completeness; annual billing is not purchasable yet, so a client should not offer it on this field alone.
    - `credits_per_cycle` number, required — Credits granted at the start of each billing cycle. Unused amount is lost.
    - `limits` PlanLimitsResponse, required — Usage limits for one rung. ``null`` means *no limit of that kind*, not zero. Catalog **v1** set all three to ``null`` on every tier; **v2 publishes real numbers**. Either way nothing refuses on them yet — the window engine records spend and reports it, and no charge path applies a cap. So these are what a customer is told, not what they are currently held to. Free's shape is the one worth knowing: a monthly cap and no shorter ones, because its 1,800 credits are one-time and a Free account never holds more than the monthly limit.
      - `daily` number, nullable — Credit limit for the current UTC calendar day; null = unlimited. A calendar day, not a trailing 24 hours.
      - `weekly` number, nullable — Trailing-7d credit limit; null = unlimited.
      - `monthly` number, nullable — Credit limit for the billing cycle; null = unlimited. An account with no subscription has no cycle to anchor to, so this is measured over the trailing 30 days instead.

---

[API](https://skmtc.net/imentiv/apis/welcome-to-imentiv-ai.md) · [All operations](https://skmtc.net/imentiv/apis/welcome-to-imentiv-ai/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/imentiv/welcome-to-imentiv-ai/revisions/350e9cbcb623/schema)