Integrations — schema-constrained API responses

Written against a structured-output-style API, but the transferable lesson is broader: a provider's supported JSON Schema subset is narrower than JSON Schema, and Appian will surface that as an opaque integration error.

The rules, each of which cost a failed test

Nullability must use anyOf, never a type array.

type: { "number", "null" }                          ❌ error
anyOf: { { type: "number" }, { type: "null" } }     ✅

This bites repeatedly because the type-array form is valid JSON Schema generally. It is simply outside the provider's subset.

No if / then / else. Conditionals are unsupported, so a schema cannot express "if type is RANGE then require range_min."

The pattern that works: declare every variant field as required-but-nullable, and let the system prompt decide which get populated. Schema guarantees valid JSON. Prompt guarantees correct field selection. Reach for this any time a shape varies by a discriminator field.

Also unsupported: recursive schemas · numeric constraints (minimum/maximum) · string constraints (minLength/maxLength) · complex array constraints. Required: additionalProperties: false on every object, and every property listed in required.

Appian expression-syntax traps

Trap	Note
{ } denotes both lists and dictionaries	required is { "a", "b" }, never ["a","b"]
Escaping quotes inside concat()	Double them: ""RANGE""
Trailing comma in { a, b, }	A real error — watch enum lists built dynamically
Lists are 1-indexed	Applies everywhere

Pin the model, disable "thinking"

If the provider supports an extended-reasoning mode, disable it for structured-output calls. Reasoning content emits before the final output, which shifts the response index and breaks code that assumes the answer is at a fixed position.

Model support for structured outputs is not uniform and changes — verify against current provider docs rather than assuming. A silently unsupported model id produces failures that look like schema bugs.