The report

When the question loop returns a FUNCTION question with detailedType SYMPTOM_CHECK_REPORT or ILLNESS_CHECK_REPORT, the results are ready to fetch.

Fetching the report

Fetch the results with GET /v1/chatbot/report. The response shape depends on the check type:

• SymptomCheckReport — illness categories with scored illnesses, the added symptoms with their questions and answers, the suggested-but-not-added symptoms, general illness questions, warning signs, the patient's profile data, metadata, and legal information.
• IllnessCheckReport — everything in SymptomCheckReport plus checkedIllness, the illness the check was started for (its name may differ slightly from the illness originally selected).

A PDF version of the same report is available from GET /v1/chatbot/report/pdf. It responds with application/pdf and a Content-Disposition: attachment; filename=xund_report_<check-id>.pdf header, so browsers download it as a file.

Fetching the report ends the check

Retrieving the report — GET /v1/chatbot/report or GET /v1/chatbot/report/pdf, either format counts — automatically closes the check. There is no confirm step: the fetch itself is the terminal call of a check. Fetching the report again afterwards is safe — the closed check serves the same report.

Getting notified when the report is ready

Rather than polling, you can have XUND call your backend when a check finishes — including when it ends in an emergency termination with no report. See the Webhooks guide for the event types, payload, signature verification, and setup.

After the check

Once a check is finished, its check-id is rejected by the endpoints that would advance or modify the check — POST /v1/chatbot/answer and the overview endpoints fail with status code 403 and customType: "CHECK_IS_FINISHED" ("This check is finished, initialize a new one."). The read endpoints, however, still accept it: GET /v1/chatbot/report, GET /v1/chatbot/report/pdf, GET /v1/chatbot/question, and GET /v1/chatbot/status all keep working for a finished check. The id is also accepted by the history endpoints:

The history report types (HistorySymptomCheckReport / HistoryIllnessCheckReport) match the live report types minus deprecated properties. The metadata endpoint takes a checkIds query array and returns each check's creation date, available languages, symptoms, and main symptom or checked illness — all requested checks must belong to your credentials. If you want to offer patients a check history, store the checkId values yourself: XUND does not identify patients, so the ids are your only handle on past checks.