Skip to main content
After uploading a document, connect to GET /process/{documentId} to receive real-time progress over a Server-Sent Events (SSE) stream. The server emits one event per pipeline stage as it starts, completes, or fails. When the entire pipeline finishes, the server sends a final complete event containing the full recovery plan and closes the connection.

Path parameter

string (UUID)
required
The document identifier returned by POST /upload. The stream is scoped to this document and to the authenticated user who uploaded it.

Pipeline stages

AfterCare processes your document through eight sequential stages. You receive a started event at the beginning of each stage and either a completed or failed event when it finishes.
1

ocr

Extracts raw text from the uploaded PDF or image using optical character recognition.
2

extract

Parses the raw OCR text into structured sections (diagnoses, discharge instructions, follow-up notes).
3

meds

Identifies all medications, dosages, frequencies, and administration instructions.
4

appts

Locates follow-up appointment details including dates, specialists, and locations.
5

warnings

Extracts warning signs and the recommended action for each (call provider, go to emergency room, call 911).
6

timeline

Builds a day-by-day recovery timeline from the discharge instructions.
7

explain

Generates plain-language explanations for medical terms found in the document.
8

judge

Validates all extracted data for consistency and flags low-confidence items for review.

Event shape

Each SSE message carries a named event (the event: line) matching the pipeline stage, and a data: line containing a JSON payload with the following fields:
A failed status on a single stage means AfterCare could not populate that section of the recovery plan — the data for that stage will be empty. The pipeline continues running the remaining stages, and the final complete event is still emitted. A fully failed document (all stages failed or processing errored out) sends a top-level failed event instead of complete.

Terminal events

After all stages finish, the server emits one of two named terminal events and closes the stream:
  • event: complete — data contains the full RecoveryPlan object.
  • event: failed — data contains a StructuredAiError with code, message, and retryable.
The server also sends periodic : heartbeat comment lines to keep the connection alive through proxies and load balancers. Your parser should ignore lines that start with :.

Reconnection and event history

The server stores every event emitted for a document. If your connection drops, simply reconnect to the same URL — the server will replay all previously emitted events before resuming the live stream. If processing has already finished, the server replays the full history, sends the terminal event, and closes the connection immediately.
Do not use the browser’s native EventSource API to consume this stream. EventSource cannot attach an Authorization header, so the server will reject the connection with 401. Use fetch() with a streaming reader instead, as shown in the example below.

Code example

TypeScript (fetch streaming reader)

StructuredAiError shape

When a stage or the entire document fails, the error field (or the terminal failed event data) contains:
string
One of AI_PROVIDER_CONFIG_MISSING, AI_PROVIDER_OUTAGE, AI_PROVIDER_UNAVAILABLE, or AI_VALIDATION_FAILED.
string
A human-readable description of the failure.
boolean
When true, the failure is transient and re-uploading the document may succeed. When false, the error is a permanent validation failure and retrying will not help.

Error responses