children

List Pending Clinics

The children whose asserted clinic has not been connected yet.

Declared before the POST because it is the static path and that one is dynamic - the two could not collide (different methods, different segment counts) but the convention is worth keeping visible.

"Not connected yet" is an organisation_child_access row for the same pair. That is what Ashleigh's manual pairing writes, and a clinic that has reached the child has nothing left to ask for. Nothing clears pending_organisation_id - it is a billing signal and stays true - so resolution is read from the access table rather than from the absence of the stamp.

A TYPED clinic is a clinic_sales_leads row with no email, and it is listed only while there is nothing from that practice on the child's care team. There is no pairing to wait on - the practice is not on indi - so once the parent has added their contact there is nothing left to ask; the row stays, for the queue.

Either shape is listed only while nothing from that practice is on the child's care team - a member whose organisation is this practice, trimmed and case-insensitive, the same test the completing UPDATE's ILIKE applies, so a contact that answers the ask here is a contact that reached the lead there. It is the parent's own act that answers the ask, whichever way the clinic was named.

ONE per child. The finder lets a parent type a practice and then pick one from the search (the add sheet writes its lead on Save, not on Continue), and home has one activation row to ask from, so two asks for one child is one the parent can never clear. The stamp wins - it is the answer they continued with - and among typed leads the newest does, the same order complete_clinic_lead writes to, so the row this names is the row the address lands on. The other leads stay in the queue untouched.

get/children/pending-clinic

Request

  • Base URL
    https://api.projectindi.com (the document declares no server; this is the origin it was published from)
  • Auth
    none declared

Response

Successful Response

Changes

No recorded changes to this operation across all 2 revisions of this API.