Partner API information requests from the doctor

An information request is how the reviewing doctor asks for more information before deciding, for example a clearer photo or a measurement checked again. Requests are fully structured: you receive a reason code and the questions to ask again, never free text, and you answer with the same answer format you used at submission. A request has no deadline; it stays open until it is answered or withdrawn. Last reviewed: 2026-11-04 While a request is open the consultation is in the info_requested status described in Consultation lifecycle.

How do you learn about a request?

The consultation moves to info_requested and you receive consultation.info_requested.
open_info_request on the consultation names the request: id, reason_code, requested_at.
The patient also sees a message about it in their Hi Doctor account.

A consultation has at most one open request at a time. There is no deadline to answer it: the request stays open until you answer it or it is withdrawn, for example when the patient withdraws consent. The doctor decides once the information arrives.

Read the request

GET /v1/partner/consultations/{id}/info-requests lists the consultation’s requests. Scope: consultations:read. Each request looks like this (the label text is illustrative):

{
  "id": "a7c3e9f1-2b4d-4c6e-8f0a-1b3d5f7a9c2e",
  "object": "info_request",
  "consultation_id": "7f8b1c2e-4d5a-4e6f-9a0b-1c2d3e4f5a6b",
  "status": "open",
  "reason_code": "photo_quality",
  "reason_label": "The photo is not clear enough",
  "question_keys": ["body_photo"],
  "questions": [{ "key": "body_photo", "label": "Photo of your upper body", "type": "upload" }],
  "documents_requested": [],
  "requested_at": "2026-11-03T11:05:12Z",
  "answered_at": null,
  "withdrawn_at": null,
  "answered_question_keys": [],
  "answer_count": 0,
  "answer_document_count": 0
}

Field	Meaning
`consultation_id`	The consultation the request belongs to.
`status`	`open`, `answered` or `withdrawn`.
`reason_code`	Why the doctor asks. See Reason codes.
`reason_label`	A fixed, human-readable label for the reason code, suitable to show the patient.
`question_keys`	Questions from the submitted questionnaire the patient must answer again.
`questions`	Each re-asked question with its `key`, `label` and `type`, from the schema version you submitted.
`documents_requested`	Kinds of document the doctor asks for, if any. See Document kinds.
`answered_at`, `withdrawn_at`	When the request was answered or withdrawn; `null` until then.
`answered_question_keys`	The question keys your answer covered, in answer order; empty until answered.
`answer_count`	How many answer entries Hi Doctor accepted; `0` until answered.
`answer_document_count`	How many files the answer attached; `0` until answered.

A request never returns the answer values or the files themselves, in the API or in the Business portal. Keep your own record of what the patient answered.

Reason codes

Code	The doctor needs
`answer_unclear`	A clearer answer to one or more questions.
`answer_inconsistent`	Answers that do not contradict each other.
`photo_quality`	A better photo.
`photo_missing`	A photo that is missing.
`measurement_check`	A measurement checked again, such as height or weight.
`medication_history`	More detail on current or past medication.
`medical_history`	More detail on medical history.
`identity_check`	Confirmation of identity details.
`document_missing`	A document, listed in `documents_requested`.
`identity_document_required`	The patient’s identity document, needed to issue the prescription. See Identity document requests.
`other_clarification`	Another clarification on the listed questions.

Document kinds

Value	The doctor asks for
`prescription`	A prescription issued elsewhere.
`lab_result`	Lab or blood test results.
`photo`	A photo for the doctor.
`other`	Another health document.

Answer the request

Ask the patient the listed questions again, upload any new photos or documents with POST /v1/partner/files, then send: POST /v1/partner/consultations/{id}/info-requests/{request_id}/answer. Scope: consultations:write.

{
  "answers": [
    { "question_key": "body_photo", "value": "5c2e8a1f-3b7d-4e9a-a0c4-6d8f1b3e5a70" }
  ],
  "uploads": []
}

answers uses the same entries-v1 format as submission, for the re-asked keys only.
Each entry is located by question_key. When question_key is set, it is used and key is ignored. When question_key is left out, empty or null, the entry is located by its alias key, which must then be a non-empty string. An entry with neither, or whose locator was not re-asked, fails with 422 unexpected_question_key. Each question can be answered once; a repeated key fails with 422 invalid_answers.
A skipped entry (skip: true, for an optional question only) carries just its locator (question_key or key), skip and, optionally, the question’s own step_id. Any other member alongside it, such as value, values or option_inputs, fails with 422 invalid_answers.
Your answers are merged over the original answers and validated against the schema version you submitted, so the full set must still be valid.
A re-asked upload step, such as body_photo above, is answered in answers with the new upload_id as its value, exactly as at submission.
uploads is only for documents named in documents_requested, which are not questionnaire steps. List their upload_ids there: at most 10, each one once. More than 10 fails with 422 invalid_request. An upload_id listed twice, or used both in uploads and as an upload answer in answers, fails with 422 upload_unusable, as does an upload that does not exist, has expired or was already used.
Send at least one answer, one upload or, on an identity document request, the identity document. null counts as leaving a member out. A body with none of them fails with 422 invalid_request, before any other check of its contents (including identity_document_required).
Free text is not accepted.

The API checks an answer in this order, and returns the first failure:

The request must exist: otherwise 404.
The request must be open: otherwise 409 info_request_not_open. This includes a request withdrawn when the patient withdrew consent.
The patient must not have withdrawn consent: otherwise 409 consent_withdrawn. Withdrawal closes the request open at that moment (step 2), but in live mode the patient’s consultations are not frozen, so a doctor can still raise a request afterwards; an answer to it stops here.
The consultation must still await information: otherwise 409 case_closed.
The body must carry an answer, an upload or the identity document: otherwise 422 invalid_request.
Then its contents are validated.

A retry after a successful answer fails with 409 info_request_not_open.

Identity document requests

When electronic prescribing needs the patient’s identity document and Hi Doctor does not have it, the doctor opens a request with reason_code identity_document_required. It may list no question keys. Answer it with identity_document, in the same shape as patient.identity_document on submission:

{
  "identity_document": { "type": "passport", "number": "YA8204716", "issuing_state": "IT" }
}

identity_document is required on this request: an answer that carries answers or uploads but no document fails with 422 identity_document_required. A body with no answer, upload or document fails with 422 invalid_request first.
It is accepted only on this request. On any other request it fails with 422 invalid_request, with an error item whose field is identity_document and code is unexpected_field.
It is validated like patient.identity_document. A document that breaks the rules (an unknown issuing state, a wrong check letter, a bad number format), a value that is not an object, or unknown members fail with 422 invalid_request, field identity_document, code invalid_identity_document.
A structural error keeps its own nested field instead: an unsupported type is field identity_document.type with code invalid_choice, and a missing, blank or too long member is that member’s field, for example identity_document.number with code required, blank or max_length.
A document that differs from the one stored for the patient fails with 409 patient_conflict.
It is never echoed or returned. Live mode stores it on the patient’s account; test mode stores nothing.

A successful answer marks the request answered, the consultation returns to in_review and you receive consultation.in_review. The doctor sees the original answers and your correction side by side; the original record is never rewritten.

How do you test information requests?

Advance a test consultation to info_requested with a reason_code and question_keys to create a synthetic request, then answer it with the endpoint above. See Test mode. Answer errors are listed in Partner API errors.

Frequently asked questions

Is there a deadline to answer an information request?

No. The request stays open until you answer it or it is withdrawn, and the doctor decides once the information arrives.

Can the doctor send us a free-text message?

No. Requests are fully structured: a reason code, a fixed label, the questions to ask again and any document kinds. Free text is not accepted in answers either.

Can a consultation have several open requests?

No. A consultation has at most one open request at a time.

Which documents can the doctor ask for?

A prescription issued elsewhere, lab or blood test results, a photo, or another health document. Upload them as files first and list them in the answer’s uploads.

Can I read the patient’s answers back from the API?

No. A request never returns the answer values or the files, in the API or in the Business portal. Keep your own record of what the patient answered.

What happens after I answer?

The request is marked answered, the consultation returns to in review and you receive a consultation.in_review event. The doctor sees the original answers and your correction side by side.

Can I answer the same request twice?

No. A second answer is refused because the request is no longer open; see Partner API errors.

Next steps

Questionnaires and schema

The entries-v1 format used for answers.

Photos and files

Upload new photos and documents for the answer.

Webhooks

Receive consultation.info_requested as it happens.

Start

Build

Operate

Partner API reference

Partner API information requests from the doctor

How do you learn about a request?

Read the request

Reason codes

Document kinds

Answer the request

Identity document requests

How do you test information requests?

Frequently asked questions

Is there a deadline to answer an information request?

Can the doctor send us a free-text message?

Can a consultation have several open requests?

Which documents can the doctor ask for?

Can I read the patient’s answers back from the API?

What happens after I answer?

Can I answer the same request twice?

Next steps

Questionnaires and schema

Photos and files

Webhooks

​How do you learn about a request?

​Read the request

​Reason codes

​Document kinds

​Answer the request

​Identity document requests

​How do you test information requests?

​Frequently asked questions

​Is there a deadline to answer an information request?

​Can the doctor send us a free-text message?

​Can a consultation have several open requests?

​Which documents can the doctor ask for?

​Can I read the patient’s answers back from the API?

​What happens after I answer?

​Can I answer the same request twice?

​Next steps

Questionnaires and schema

Photos and files

Webhooks

How do you learn about a request?

Read the request

Reason codes

Document kinds

Answer the request

Identity document requests

How do you test information requests?

Frequently asked questions

Is there a deadline to answer an information request?

Can the doctor send us a free-text message?

Can a consultation have several open requests?

Which documents can the doctor ask for?

Can I read the patient’s answers back from the API?

What happens after I answer?

Can I answer the same request twice?

Next steps