Problem
There is no read API. Once attestations are being written there is no way to
retrieve them, so the dashboard, the exports, and any integrator verification
flow all have nothing to call.
What to do
GET /v1/attestations with filters: payer, model, policy, date range, status.
GET /v1/attestations/:id returning the record plus its verification
material — transaction hash, ledger sequence, contract address.
GET /v1/usage with the same filter vocabulary plus aggregation
(group_by=model|payer|day).
- Cursor pagination, not offset — offset pagination over a continuously
growing table skips and repeats rows as new data arrives.
- Authorization scoped to the caller: a payer sees only their own records.
- Cap page size and total result windows.
Acceptance criteria
Notes
Row-level authorization is the one to test hardest. A filter parameter that can
be widened to another tenant's data is the classic multi-tenant leak.
Problem
There is no read API. Once attestations are being written there is no way to
retrieve them, so the dashboard, the exports, and any integrator verification
flow all have nothing to call.
What to do
GET /v1/attestationswith filters: payer, model, policy, date range, status.GET /v1/attestations/:idreturning the record plus its verificationmaterial — transaction hash, ledger sequence, contract address.
GET /v1/usagewith the same filter vocabulary plus aggregation(
group_by=model|payer|day).growing table skips and repeats rows as new data arrives.
Acceptance criteria
Notes
Row-level authorization is the one to test hardest. A filter parameter that can
be widened to another tenant's data is the classic multi-tenant leak.