latestOpenAPI 3.1.02026-08-218667571.2 MB

a8ca30023371

Admin APIs
ledger

List S3 Grants

Every client's S3 awards, for Cole's oversight tab.

The same rows the client's own Vesting Schedule renders, from the same query — two implementations of "accrued" or "progress" would drift, and the figure quoted to a client has to be the one on their screen.

Bounded, not paginated. The cap is applied in SQL and everything downstream — the vesting rollup, the debit attribution, the next-vest lookup — keys off the rows it returns, so the database read is bounded and not merely the response. Ordering is deterministic (client, effective_at, id), which is what makes real pagination a later addition rather than a rewrite. has_more says outright whether anything was left behind — inferring it from total_grants == limit is wrong at the boundary, where a system holding exactly limit grants looks identical to one holding more.

get/api/v1/admin/ledger/s3-grants

Query parameters

client_idstring nullable

Narrow to one client; omit for every client.

Narrow to one client; omit for every client.

limitinteger

Maximum grants to return, ordered by client then effective date.

Maximum grants to return, ordered by client then effective date.

Response

Successful Response

total_grantsinteger required
has_moreboolean