Skip to main content
Text to JSON extracts facts or maps Markdown sections into a JSON structure you define. Send plain text, a transcript, or an existing note with a JSON Schema to POST /v1/utils/text-to-json. The endpoint returns schema-validated data in one synchronous response. You choose the fields and sections. Extraction instructions restrict the output to information explicitly present in the source.

SDK

Use the SDK’s authenticated request method:

Extract structured data

A successful request returns 200 with extracted values, for example:
Persist data if you need it later; there is no resource to poll or retrieve.

Map Markdown sections to JSON

To return whole sections as strings, describe what to copy in each property’s description:
An example response is:
Mapping is model-based: requesting verbatim copying does not guarantee exact character preservation. Use a deterministic parser when that is required.

Combine section mapping and extraction

Use the same schema to copy section bodies and extract typed facts. This request keeps the HPI and Plan as strings while extracting pulse into a nested object:
An example response is:

Generate a note, then structure it

First call note generation, then pass the returned note string as text to Text to JSON. The inline template below requests HPI and Vitals sections; the extraction schema copies the HPI and extracts pulse. Using the client created in the SDK example above:
For a generated HPI of “The patient reports a dry cough for three days.” and pulse of 72 bpm, the second response would contain:
The HPI text depends on the generated note. The second call extracts from that note, rather than directly from the original transcript. Generation and extraction are separate requests and, for billing-enabled accounts, separately billable operations.

Define the output schema

JSON Schema supports nested objects, arrays, strings, numbers, integers, booleans, and nullable values. Use property description values for extraction guidance, section names, units, or copying requirements.
  • List fields that must appear in required.
  • Use additionalProperties: false to reject fields outside the schema.
  • Allow null for missing values, for example "type": ["integer", "null"]. Extraction instructions request null for missing optional fields.
  • Allow empty arrays to represent no supplied items.
Sully selects models and handles provider fallback; there are no model, provider, or separate custom-instructions parameters. Schema validation checks structure and types, not factual fidelity or clinical correctness.

Request fields

The schema document’s JSON nesting depth, including objects and arrays, must not exceed 10. This measures the schema document itself, not the requested result.

Errors and retries

Invalid schemas return error: "Provided schema is not a valid JSON Schema." with a details array. Extraction failures return {"error": "Extraction failed", "message": "..."}; billing errors use an error field containing the error name. For billing-enabled accounts, each successful extraction counts as one text_to_json_request at your account’s configured rate, regardless of internal retries or fallback. Validation and extraction failures do not count as successful usage. Billing completes before the success response is sent, so a lost response may still be billable. Each POST starts a new operation with no public idempotency key; retrying can incur another charge. The SDK examples disable automatic retries for this reason. Retain x-request-id for support.