Skip to content

API — Pools & lending

Purpose

Management of pools (groups of workers, default one per department) and the directional pool-lending rules that permit cross-pool borrowing at allocation time.

Auth & roles

  • Pools — base /api/pools · read pool.read, write pool.write (SYS_ADMIN + HR_ADMIN + MANAGER).
  • Pool-lending rules — base /api/pool-lending-rules · read pool_lending_rule.read, write pool_lending_rule.write (same holders).

See the RBAC matrix.

Endpoints

Pools — /api/pools

Method Path Purpose Gate
GET / POST /api/pools List / create pools read / write
GET / PATCH / DELETE /api/pools/{id} Read / update / delete a pool read / write

Pool-lending rules — /api/pool-lending-rules

Method Path Purpose Gate
GET / POST /api/pool-lending-rules List / create lending rules read / write
GET / PATCH / DELETE /api/pool-lending-rules/{id} Read / update / delete a rule read / write

Shapes & errors

A lending rule is directional (source pool → target pool). Cross-pool eligibility is enforced at allocation time by CrossPoolEligibilityRule (LIVE runtime behaviour, sheet 22), not merely as config. Standard ProblemDetails.

Gotchas

  • Cross-pool lending is enforced at runtime, not just stored — it shapes who is eligible during an allocation run (sheet 12 / 22).
  • MaxConcurrentBorrows cap, an approval workflow, and a lending ledger are PLANNED — the rule decides eligibility; there is no borrow-count cap or approval chain yet (sheet 22).
  • The reason a candidate was blocked by cross-pool rules is computed server-side but not surfaced in the UI (part of F8) — see Rosters & allocation runs for where the reason data lives.
  • Default-pool-per-department is an invariant — each department has a default pool.