Users type addresses with inconsistent formatting, phone numbers with or without country codes, and shipping preferences in plain English. If you pass this text to your backend as-is, you need normalization logic, validation logic, and error handling for every possible format variation. Schema-constrained generation does this normalization at extraction time: the model reads the messy input and produces a clean, typed object that conforms to your backend’s expectations.Documentation Index
Fetch the complete documentation index at: https://docs.dottxt.ai/llms.txt
Use this file to discover all available pages before exploring further.
Goal
Convert mixed-quality user submissions into a normalized order payload with correct types, validated formats, and consistent structure, ready for your order creation API.Schema contract
Example input
Example output
Implementation tips
- Nullable for “asked but absent.” The user explicitly said “no phone,” so
phoneisnullrather than omitted. Your backend can distinguish “no phone provided” from “phone not asked,” which is useful for follow-up workflows. - Enums for controlled vocabulary.
methodis"standard"or"express", not"fast","next day", or"ASAP". The enum forces normalization so your shipping logic doesn’t need string matching. - Pattern for format enforcement. The
countryfield uses"^[A-Z]{2}$"so the model produces"US"instead of"United States","usa", or"U.S.A.". The same idea applies tophone: the E.164-like pattern ensures a format your telephony API accepts. additionalProperties: falseprevents the model from forwarding raw user text as extra fields, which could leak PII into systems that don’t expect it.
Related docs
- Optional vs Null: distinguish “not provided” from “explicitly absent”
- Optional fields: fields the model can omit entirely
- String bounds: control length, format, and regex on form fields
- Object reference | String reference