Integrations — truncated responses and the auto-conversion trap

The symptom

A large JSON payload comes back from an external API truncated, and parsing it throws "not valid JSON."

The cause is Appian, not the API

Appian's "Convert JSON to Appian value" step clips a long text value. It is a genuine Appian-side size cap, not a display artifact and not the provider cutting output short.

The fix

Return the RAW response and parse it manually in Appian. Do not have the integration build the Appian record type directly from the response.

Skipping the auto-conversion sidesteps the cap entirely.

The one-step diagnosis

Check the provider's own completion field first. For a Messages-style API, stop_reason: "end_turn" (rather than max_tokens) proves the provider sent complete output — which exonerates the API in a single step and points you at Appian.

Generalizable rule: when an Appian integration returns truncated content from any large-payload API, suspect Appian's response auto-conversion before suspecting the API.

Fixes that did NOT work — recorded so they aren't retried first

• Minifying the payload via prompt
• Adding structured outputs — worth having for validity, but it does not fix size; the content still returns as a string
• Chunking across multiple calls

A second cause that looks identical

The payload is a string inside content[1].text (1-indexed). If a "thinking" step is ever re-enabled, the thinking block takes index 1 and shifts the text block — producing the same "not valid JSON" error from an entirely different cause. See Schema-constrained API responses.