Make your first request
Create a user, run a clinical consultation, and retrieve its consultation documents.
This walkthrough takes a user from account creation through consultation completion and
document retrieval. The API returns each consultation summary or SOAP note as an artifact.
Before you begin
You need an API Bearer token provisioned by Doctronic. Credential provisioning is currently manual. Contact your Doctronic business or implementation contact to request staging or production access. If you do not have a contact yet, email business@doctronic.ai. Do not send credentials or patient information by email.
Request credentials from Doctronic
There is no self-service token dashboard. Tell your Doctronic contact which environment you need and who should receive the credential through the agreed secure channel.
Store the token server-side and never expose it in browser code, mobile binaries, logs, or analytics events.
export DOCTRONIC_API_URL="https://staging-partners.doctronic.ai/api/v1"
export DOCTRONIC_API_TOKEN="replace-with-your-token"
export DOCTRONIC_CREATE_USER_KEY="replace-with-a-unique-key"1. Create a user
Create the Doctronic identity that corresponds to the patient in your system.
curl --request POST "$DOCTRONIC_API_URL/users/" \
--header "Authorization: Bearer $DOCTRONIC_API_TOKEN" \
--header "Idempotency-Key: $DOCTRONIC_CREATE_USER_KEY" \
--header "Content-Type: application/json" \
--data '{
"firstName": "Avery",
"lastName": "Chen",
"dateOfBirth": "1990-06-15",
"email": "avery@example.com",
"phoneNumber": "+15555550100",
"sex": "female"
}'Save the returned data.id. Pass it as X-Doctronic-User-ID for every user-scoped request.
2. Create a chat
export DOCTRONIC_USER_ID="user-id-from-step-one"
export DOCTRONIC_CREATE_CHAT_KEY="replace-with-a-different-unique-key"
curl --request POST "$DOCTRONIC_API_URL/chats/" \
--header "Authorization: Bearer $DOCTRONIC_API_TOKEN" \
--header "X-Doctronic-User-ID: $DOCTRONIC_USER_ID" \
--header "Idempotency-Key: $DOCTRONIC_CREATE_CHAT_KEY" \
--header "Content-Type: application/json" \
--data '{
"timezone": "America/New_York",
"conversationPromptContext": "The user entered from the primary-care intake flow."
}'Save the returned data.id for each streaming request.
The create-user and create-chat operations retain an Idempotency-Key result for 24 hours. If a
request times out before you receive a response, retry the same operation with the same body and
key. Use a different key for a different user or chat.
3. Stream a turn
export DOCTRONIC_CHAT_ID="chat-id-from-step-two"
curl --no-buffer --request POST \
"$DOCTRONIC_API_URL/chats/$DOCTRONIC_CHAT_ID/stream/" \
--header "Authorization: Bearer $DOCTRONIC_API_TOKEN" \
--header "X-Doctronic-User-ID: $DOCTRONIC_USER_ID" \
--header "Content-Type: application/json" \
--header "Accept: text/event-stream" \
--data '{
"userEvent": {
"type": "user_message",
"userInput": "I have had a sore throat and fever since yesterday."
},
"timezone": "America/New_York"
}'The response remains open for the assistant turn and emits Server-Sent Events such as
message.start, message.content, and message.stop.
Handle control events separately from message text
A stopped assistant message is not a completed consultation. Continue the consultation by
sending each new user turn to the same stream endpoint. Treat guardian,
conversation.end, skill_code.cta, error, and ai_consultation.complete as explicit
control events. Never infer their meaning from assistant text or from the connection closing.
If a guardian event arrives, route it through the safety behavior approved for your
integration. Pause any routine local flow that conflicts with that behavior, and keep the
event's stable guardianId in your integration logs. Your approved behavior determines how
and where the supplied message is presented.
4. Detect consultation completion
Continue sending user turns until the stream emits ai_consultation.complete. Its payload
contains stable IDs for the consultation artifacts:
event: ai_consultation.complete
data: {"type":"ai_consultation.complete","artifacts":{"longSummary":"art_01K6JGGM2G2DB4Y9KB9H9MJJ6Q","shortSummary":"art_01K6JGGP7Q4R8S2T5V7W9X1Y3","soapNote":"art_01K6JGGR9Z6B2C4D6F8H0J2K4M"}}
Persist the artifact IDs with your consultation record. The completion event does not guarantee that every artifact is ready to retrieve. The end of an HTTP response only marks the end of that transport stream. It does not mean the consultation is complete.
5. Retrieve a consultation document
Use an artifact ID from the completion event:
export DOCTRONIC_ARTIFACT_ID="artifact-id-from-completion-event"
curl --request GET \
"$DOCTRONIC_API_URL/artifacts/$DOCTRONIC_ARTIFACT_ID/" \
--header "Authorization: Bearer $DOCTRONIC_API_TOKEN" \
--header "X-Doctronic-User-ID: $DOCTRONIC_USER_ID"A 200 response identifies the artifact with data.artifactType and provides its Markdown
content in data.content.body. The type is long_summary, short_summary, or soap_note.
If the API returns 202, the artifact is still being generated. Wait before requesting it
again. Treat 404 as unavailable and 500 as a permanent generation failure.
Treat events as an additive contract
Ignore event types you do not recognize. New event names may be added without breaking existing consumers.