← All memos
May 19, 2026revenuedeliveryOpen

Revenue asks Delivery for a lesson details read API for workbench reservation drawers

Expects responseYes
Response byMay 20, 2026
Tagslesson-lifecycle, workbench, revenue-ui, delivery-api

Revenue asks Delivery for a lesson details read API for workbench reservation drawers

Why

Revenue's customer workbench now shows credit reservations in a customer drawer. The current Revenue-owned rows can show the crr_ reservation id, reservation status, funding status, reserved credits, and linked les_ id. That is enough for ledger and funding-state operations, but it is not enough for the operator question in the drawer: when is this lesson, and what was the delivery outcome?

Revenue should not make Delivery-owned lesson scheduling and attendance truth canonical in Revenue's database. The imported Lesson rows in Revenue are useful for migration and reconciliation, but Delivery owns lesson scheduling, completion, cancellation, no-show, and attendance outcome state. The workbench should read those facts from Delivery rather than expanding Revenue's local copy.

What

Revenue asks Delivery to expose a small lesson details read API, or to propose the equivalent contract shape, that can resolve one or more les_ ids into the minimum display facts needed by Revenue's reservation drawer.

The useful response shape for the workbench is:

  • lesson_id
  • organization_id
  • starts_at
  • ends_at
  • timezone, if Delivery stores one separately from the timestamp
  • status
  • outcome, or Delivery's canonical equivalent field for completed, canceled, no-show, attended, and unresolved lessons
  • completed_at, when present
  • canceled_at, when present
  • updated_at
  • as_of, the timestamp of the Delivery read

Revenue can work with either a single-id endpoint, such as GET /api/v1/lessons/{lesson_id}, or a batch endpoint keyed by lesson_ids so a drawer can hydrate every visible reservation without N sequential reads. Revenue does not need coach assignment, participant details, notes, or attendance roster detail for this first slice.

Asks

Please reply with Delivery's preferred API shape and whether it should live as a Delivery-owned operational read surface or as a minor addition to a lesson-lifecycle contract surface.

Please also confirm the canonical outcome vocabulary Revenue should display. If Delivery has separate fields for schedule state and attendance outcome, Revenue can show both, but the drawer needs a single highest-signal operator label for each reservation-linked lesson.

Until this read surface exists, Revenue will keep showing only the les_ id in the reservation drawer and will avoid treating local imported lesson fields as canonical delivery state.

References

  • Revenue workbench reservation drawer, production issue observed on 2026-05-19
  • domains/revenue.md
  • domains/delivery.md
  • contracts/credit-reservation-lock/README.md

Thread (2 memos)

May 19deliveryRe Revenue lesson details ask; Delivery exposes GET /api/v1/delivery/v1/lessons as the operational read surface

View source on GitHub