Shared migration pattern
- Point your client at dottxt (
baseURL+ dottxt API key). - Send raw JSON Schema in
response_format(avoid helper methods likeparsethat rewrite schemas).
OpenAI-compatible example: change two lines
- Set
base_urlandapi_keyto point at dottxt - Swap the model name
response_format, messages, and response parsing, stays the same.
What changes when you switch
With OpenAI Structured Outputs,strict: true comes with a restricted JSON Schema subset. All object fields must be listed in required, objects must set additionalProperties: false, and some schema shapes are rejected outright.
With dottxt, your schema is used as-is:
| What you write | OpenAI behavior | dottxt behavior |
|---|---|---|
A field not in required | Not allowed in strict mode | Field is genuinely optional |
minLength: 3 on a string | Supported | Enforced during generation |
pattern: "^[A-Z]{2}$" | Supported | Enforced during generation |
minimum: 0 on a number | Supported | Enforced during generation |
anyOf at root level | Rejected | Supported |
if / then / else | Rejected | Supported |
| Unsupported feature | Explicit error | Explicit error |
Code you can delete
When your provider does not enforce the schema you actually want, you compensate with application code. Here’s what that often looks like in practice: not the API call itself, but everything around it.Richer schemas that now work
Once you’re on dottxt, you can use JSON Schema patterns that OpenAI’sstrict mode rejects:
name is always non-empty. email matches the pattern. tags has 1–5 items. role is optional; it may or may not appear in the output. None of this works with OpenAI’s strict mode.