---
title: "List Pending Clinics"
method: GET
path: "/children/pending-clinic"
tags: ["children"]
---

# List Pending Clinics

`GET /children/pending-clinic`

## Request

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

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.

## Response `200`

Successful Response

- PendingClinicsResponse
  - `pending` PendingClinicCard[], required
    - `child_id` string, required
    - `organisation_name` string, required
    - `clinician_first_name` string, nullable, required

---

[API](https://skmtc.dev/projectindi/apis/indi-agent-api-first-principles.md) - [All operations](https://skmtc.dev/projectindi/apis/indi-agent-api-first-principles/llms.txt) - [OpenAPI document](https://skmtc.dev/projectindi/apis/indi-agent-api-first-principles/revisions/25a7813e21fd?raw)