Admin-only.
GET /benefit_entities requires an admin bearer token. There is
no write API — ledger rows are minted server-side, in the same database
transaction as the policy / consultation they describe, so a utilization can
never be recorded without its owning entity (or vice-versa).Row shape
| Field | Type | Notes |
|---|---|---|
entity_id | string (UUID) | The utilized entity’s id — the insurance_policies.id or consultations.id. This is the primary key. |
entity_type | enum | INSURANCE_POLICY or CONSULTATION. |
benefit_id | string (UUID) | The benefit that was utilized. |
user_id | string | The user (12-digit id) who utilized the benefit. |
created_at | string (ISO 8601) | When the utilization was recorded. |
entity_id is polymorphic (it points into two different tables) and so carries
no foreign key. Integrity is guaranteed at write time because the ledger row
is inserted in the same transaction as its owner.Immutable history
A utilization is a historical fact: rows are never updated or deleted, and the table has no status column. Consultations are recorded at initiation — a consultation that later fails upstream still has a ledger row, because the ledger records utilization attempts.Listing
GET /benefit_entities returns the standard paginated envelope
({ data, total, limit, offset }) and supports:
user_id— scope to a single user (omit to list across all users).entity_type—INSURANCE_POLICYorCONSULTATION.benefit_id— a specific benefit.start_time/end_time— bound results bycreated_at(ISO 8601).on/by— sort (on=created_at,by=asc|desc; defaults to newest first).limit/offset— pagination (limit capped at 100).