---
title: "Accrual Detail"
method: GET
path: "/v2/pool/accrual/{pot_address}"
tags: ["v2 - Creator Pool"]
---

# Accrual Detail

`GET /v2/pool/accrual/{pot_address}`

## Request

- Base URL: `https://api.jubjubapp.com` (the document declares no server; this is the origin it was published from)
- URL: `https://api.jubjubapp.com/v2/pool/accrual/{pot_address}`
- Auth: HTTP bearer

Ledger-side money states for one catalogue pot.

AUTH: authenticated users only (this shipped without a dependency —
caught in audit; it was the only unauthenticated money read in the
codebase). The full authorisation rule this surface ultimately needs is
holder-or-owner-scoped and id-keyed: dashboard and MCP speak
content/team ids, pots are catalogue addresses, so the user-facing
reads belong on an id-keyed sibling endpoint that resolves the pot via
the entity doc and checks membership the way catalogue_get does. This
address-keyed read stays as the low-level tool: authenticated, and
exposing only aggregate, non-PII ledger positions.

States 1-3 of the five-state display ("earning now" is per-viewer and
summed here; "held for your catalogue" is pending_at_hub). Everything
here is NON-spendable by definition — states 4-5 (ready to claim / in
wallet) come from the catalogue contract via the existing claim surfaces
and are deliberately not blended in.

## Path parameters

- `pot_address` string, required

## Headers

- `Authorization` string
- `X-JubJub-Service-Key` string
- `X-JubJub-Agent-Key` string
- `X-JubJub-Platform-Key` string
- `Origin` string
- `Referer` string
- `X-JubJub-Trial-Token` string

## Response `200`

Successful Response

- unknown

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/jubjubapp/apis/jubjub-api.md) - [All operations](https://skmtc.dev/jubjubapp/apis/jubjub-api/llms.txt) - [OpenAPI document](https://skmtc.dev/jubjubapp/apis/jubjub-api/revisions/353157b296f2?raw)